0

When I was scrutinizing the DNS query sent by the dig, I found something odd from what RFC's state. I don't know the different variants of DNS protocols out there, but from RFC 1035

Z : Reserved for future use. Must be zero in all queries and responses.

This is the memory snapshot of the received DNS query, exported from the eclipse IDE in the debugging mode.

00000000   F5 F4 01 20  00 01 00 00  00 00 00 01  03 77 77 77  06 67 6F 6F  67 6C 65 03  63 6F 6D 00  00 01 00 01  00 00 29 10  00 00 00 00  ... .........www.google.com.......).....
00000028   00 00 0C 00  0A 00 08 1F  0A 12 91 67  67 B0 B9                                                                                   ...........gg..

Mapping the corresponding bits to DNS fields (From the RFC 1035)

F5F4 -> DNS Transaction ID.

01 -> QR, Opcode, AA, TC, RD

20 -> 00100000 => RA -> 0 , Z -> 010

Z is non zero! Does dig use some other variant of DNS, if at all the DNS variants exists? Or should it be considered as an issue in the dig?

1

There are no multiple variants of DNS, but RFC 1035 on this subject was amended by RFC2535 "DNS Security Extensions".

Its section 6.1 shows the message format:


                                           1  1  1  1  1  1
             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                      ID                       |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    QDCOUNT                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    ANCOUNT                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    NSCOUNT                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    ARCOUNT                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

As you can see, the 3 bits previous Z field is now split between Z, AD and CD.

Hence, your 0x20 = 0b00100000 is to be split as follows:

  • RA = 0 : recursion NOT available from the server replying this message
  • Z = 0 : as expected, should be 0
  • AD = 1 : "all the data included in the answer and authority portion of the response has been authenticated by the server according to the policies of that server."
  • CD = 0 : checking not disabled (makes sense in query, not in a response, it is defined as "Pending (non-authenticated) data is acceptable to the resolver sending the query.")
  • RCODE = 0 : No error

DNS specifications are complicated, often ambiguous, split in many documents, etc. This recent effort can help finding its way: https://powerdns.org/hello-dns/

2
  • Well then the future referred by the RFC 1035 already came. Thanks for the answer and resources. Jun 7 '20 at 1:54
  • 2
    RFC 1035 was written in November 1987... Jun 7 '20 at 2:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.