Sockets programming: DIG DNS Query Messages: Incorrect header length?

Question

RFC Reference

I am working on a project which involves sockets programming and interpreting the output from DIG DNS queries.

I'm using RFC 1035 as my reference. Although this is quite old now (1987) as far as I can tell from later RFCs (for example 8490) the DNS headers are still the same.

https://www.rfc-editor.org/rfc/rfc1035

Code Overview: IPv6 TCP query

I have written a short program in C which reads from a IPv6 TCP socket. I send data to this socket using DIG. (My program simply reads all data it sees on a socket, and prints it to stdout.)

Note that there are two unusual things here:

• Firstly the use of IPv6
• Secondly the use of TCP (DNS messages are often UDP)

Here is the command used:

dig @::1 -p 8053 duckduckgo.com +tcp

I am running dig version DiG 9.16.13-Debian, on Debian Testing. (cera 2021-May)

Output, Discussion and Question

Here is the hexadecimal and printable character output which is read from the socket:

Hex:
00 37 61 78 01 20 00 01 00 00 00 00 00 01 0A 64 75 63 6B 64 75 63 6B 67 6F 03 63 6F 6D 00 00 01 00 01 00 00 29 10 00 00 00 00 00 00 0C 00 0A 00 08 00 7A 4* 48 2C 16 0* 33 
Char:
00  7 61  x 01 20 00 01 00 00 00 00 00 01 0A  d  u  c  k  d  u  c  k  g  o 03  c  o  m 00 00 01 00 01 00 00  ) 10 00 00 00 00 00 00 0C 00 0A 00 08 00  z 4*  H  , 16 0* 33 

If non-printable characters are encountered, the hex value is printed instead.

Although this is a fairly long stream of data, the question relates to the length of the header.

---

According to RFC 1035, the length of the header should be 12 bytes.

4.1.1. Header section format

The header contains the following fields:

                                    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    |   RCODE   |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    QDCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ANCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    NSCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ARCOUNT                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The header is followed by a QUESTION SECTION. The question section begins with a single byte which specifies the length.

---

Inspecting the data stream above, we see that the byte at offset 12 has a value of 0. I repeat it below with offset numbers to make it clear. The data is in the middle row, the row above and below are byte offsets.

 0  1  2  3  4  5  6  7  8  9 10 11 <- byte 12
00 37 61 78 01 20 00 01 00 00 00 00 00 01 0A 64 75 63 6B ...
 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 <- byte 15

This clearly doesn't make any sense.

Looking again at the stream, we can see that "duckduckgo" is preceeded by the byte 0A. This is 10 in decimal and corresponds to the 10 characters of "duckduckgo". This string is followed by a byte 03 which corresponds to the 3 bytes of "com".

The offset of the byte 0A is 15. Not 12.

I must have misunderstood the RFC specification. But what have I misunderstood? Does the header itself start at a different offset to what I think it is? (Byte zero.) Or is there perhaps some padding between the end of the header and the beginning of the first question section?

Existing Question on this site:

Comments: The below link states that there is no padding. This is the only answer on this question. The question is about DNS responses rather than queries, and does not ask about the header section of a query. (Although information from one should presumably apply to the other, but possibly does not.)

Do DNS messages pad names to an even number of bytes?

Comments: The below link asks about the best way to build a data structure to handle DNS data. Additionally, the answer notes that one has to be careful about network byte order and machine byte order. I am already aware of this and I use ntohs() to convert from network byte order to x86_64 byte order before printing information to stdout. This is not the problem and does not explain why I see information about the dns query starting at byte 15 instead of 12, when the header should be a fixed size of 12 bytes.

Implementing a DNS Query in c++ according to RFC 1035

Answer 1

Thanks to @SteffenUllrich who prompted the solution for this in the comments.

RFC 1035 4.2.2 states

4.2.2. TCP usage

Messages sent over TCP connections use server port 53 (decimal).  The
message is prefixed with a two byte length field which gives the message



Mockapetris                                                    [Page 32]
 
RFC 1035        Domain Implementation and Specification    November 1987


length, excluding the two byte length field.  This length field allows
the low-level processing to assemble a complete message before beginning
to parse it.

I had removed the 2-byte field at the start of my struct at some point.

This is what the structure looks like with the 2 byte length field re-enabled.

struct __attribute__((__packed__)) dns_header
{

    unsigned short ID;
    union
    {
        unsigned short FLAGS;

        struct
        {
            unsigned short QR : 1;
            unsigned short OPCODE : 4;
            unsigned short AA : 1;
            unsigned short TC : 1;
            unsigned short RD : 1;
            unsigned short RA : 1;
            unsigned short Z : 3;
            unsigned short RCODE : 4;
        };
    };
    unsigned short QDCOUNT;
    unsigned short ANCOUNT;
    unsigned short NSCOUNT;
    unsigned short ARCOUNT;

};


struct __attribute__((__packed__)) dns_struct_tcp
{

    unsigned short length; // length excluding 2 bytes for length field

    struct dns_header header;

};

For example: I recieved a TCP packet of length 53 bytes. The value of length is set to 51.

To read data into this struct:

memcpy(&dnsdata, buf, sizeof(struct dns_struct_tcp));

To interpret this data (since it is stored in network byte order):

void dns_header_print(FILE *file, const struct dns_header *header)
{

    fprintf(file, "ID: %u\n", ntohs(header->ID));
    char str_FLAGS[8 * sizeof(unsigned short) + 1];
    str_FLAGS[8 * sizeof(unsigned short)] = '\0';
    print_binary_16_fixed_width(str_FLAGS, header->FLAGS);
    fprintf(file, "FLAGS: %s\n", str_FLAGS);
    fprintf(file, "FLAGS: QOP  ATRRZZZR   \n");
    fprintf(file, "       RCODEACDA   CODE\n");
    fprintf(file, "QDCOUNT: %u\n", ntohs(header->QDCOUNT));
    fprintf(file, "ANCOUNT: %u\n", ntohs(header->ANCOUNT));
    fprintf(file, "NSCOUNT: %u\n", ntohs(header->NSCOUNT));
    fprintf(file, "ARCOUNT: %u\n", ntohs(header->ARCOUNT));
    
}

Note that the flags are unchanged, since each field of flags is less than 8 bits in length. However on x86_64 systems, unsigned short is stored in little-endian format, hence ntohs() is use to convert data which is in big-endian (network) byte order to little-endian (host) byte order.