Handmade DNS root NS query fails to 1.1.1.1 but succeeds to 8.8.8.8

Elia

7/30/24, 1:47 PM

For educational purposes I'm sending handmade packets to query root NS using python. The expectation is to get similar results as dig NS . @1.1.1.1.

The following is relevant only to NS . as any other NS <domain> works as expected.

Given the following packet structure:

(Pdb) req
                     1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             0x28c2            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|  0x0  |0|0|1|0|  0  |  0x0  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             0x0001            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             0x0000            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             0x0000            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             0x0000            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--
/                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             0x0002            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             0x0001            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<--

(Pdb) bytes(req)
b'(\xc2\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x01'

Then sending it to cloudflare 1.1.1.1 and google 8.8.8.8

(Pdb) len(req.send(("8.8.8.8", 53)).records)
13

(Pdb) len(req.send(("1.1.1.1", 53)).records)
0

Inspecting the query sent via dig in Wireshark shows the exact same fields as in the python query above, except that dig sends an additional edns record.

I'm trying to find out why is the above query working with 8.8.8.8 but failing 1.1.1.1

1 + 0

domain-name-system

Score:4

Server

Håkan Lindqvist

7/30/24, 2:25 PM

If you adapt your dig command line to send an equally minimal version of this query, you get:

$ dig . NS +noedns +ignore @1.1.1.1

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> . NS +noedns +ignore @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42553
;; flags: qr tc rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.                              IN      NS

;; Query time: 3 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Sun Jul 30 16:11:19 CEST 2023
;; MSG SIZE  rcvd: 17

$

Ie, with 1.1.1.1 you get an (empty) truncated response (note the TC flag).
I'm not sure why they do not simply serve the NS rrset alone in this case as that would fit, but that is the behavior of 1.1.1.1 that leads up to your question.

Without EDNS0 the answer size is limited to 512 bytes, with EDNS0 the client can indicate a larger message size they can accept (1232 bytes is typical these days).

(+noedns being the actual change to the query, +ignore only to show the truncation message itself rather than trying to get the full answer via TCP instead)

+ 2

Elia

7/30/24, 4:58 PM

Thank you, this is exactly what I was missing. Running `dig . NS +noedns @1.1.1.1` returns `MSG SIZE rcvd: 800`, on the other hand `dig . NS +noedns @8.8.8.8` returns `MSG SIZE rcvd: 228`.

Elia

7/30/24, 5:02 PM

If I'm not mistaken, in additional sections of `1.1.1.1` they return A and AAAA records for each of the 13 NS

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Handmade DNS root NS query fails to 1.1.1.1 but succeeds to 8.8.8.8

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.