Question

I've been using RFC 1035.4.1.3 as a reference for DNS RR format: http://www.freesoft.org/CIE/RFC/1035/42.htm

The RFC says that RDLENGTH is "an unsigned 16 bit integer that specifies the length in octets of the RDATA field" but in the datagrams I'm getting RDLENGTH is sometimes 2 less than it should be. I've checked with wireshark to ensure that I'm getting the datagram correctly. Here's a CNAME record I got while looking up google:

C0 0C 00 05 00 01 00 03  95 FC 00 10 03 77 77 77
01 6C 06 67 6F 6F 67 6C  65 03 63 6F 6D 00

So that's the name: C0 0C (a pointer to www.google.com earlier in the dgram)
Then the type: 00 05 (CNAME)
Then the class: 00 01 (IN)
Then the TTL: 00 03 95 FC (whatever)

Then RDLENGTH: 00 10 (that's 16 bytes, yes?)

Then RDATA:
03 77 77 77 01 6C 06 67 6F 6F 67 6C 65 03 63 6F 6D 00 (www.l.google.com - format is correct)

As you can see, the RDATA is 18 bytes in length. 18 bytes is 0x12, not 0x10.

The type A records that come after that correctly report RDLENGTH 4 for the address data. Am I missing something here? I'd dismiss it as an error, but I get this for every DNS servers and every domain.

I guess really what I'm asking is why the RDATA is longer than RDLENGTH and what rules should I follow to adapt to it so I can parse any type of record. (Specifically, can I expect this kind of thing from other RR types?)

Thank you in advance to anyone who gives advice. :)

Was it helpful?

Solution

The response data appears to be messed up - either RDLENGTH should be 18 (0x00 0x12), or RDATA should be different.

I just ran a few google lookups from here, and I do not see that problem. I get RDLENGHT of 7 and RDATA to match (a compressed name).

Is something messing with your packet data?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top