Im making a small DNS client for a project for school. So far Im pretty sure I've crafted the query properly as I do get a response, and it contains the question name the same as my query, and the RCODE section is well thats another question I have. When I made the query improperly Id get 0x01 as the RCODE on the response, now when I use printf("%x") I get ffffff80. I don't quite get why its printing out all the extra F's but if I look at the last 2 digits it seems correct.
I printed the hex for the packet and started looking through it to figure everything out. Past the question portion I figured the compression, points back to the NAME in the question. I figure the next 6 octets are TYPE, CLASS and TTL. From there I get confused. The 2 octets that should be RDATA are printed in hex as 0x45 and 0xffffffb3. From there Im completely clueless on the makeup of the rest of RDATA.
Ive included a small set of my data
spot 32: ffffffc0
spot 33: c (these 2 octets point back to question for NAME)
spot 34: 0
spot 35: 5 (these 2 octets are TYPE should be CNAME)
spot 36: 0
spot 37: 1 (THese 2 should be CLASS for IN)
spot 38: 0
spot 39: 3 (These 2 octets 38+39 are the TTL)
spot 40: 45
spot 41: ffffffb3 (These 2 octets should be the RDLENGTH)
spot 42: 0
spot 43: 8
spot 44: 3
spot 45: 77
spot 46: 77
spot 47: 77
spot 48: 1
spot 49: 6c
spot 50: ffffffc0
spot 51: 10
spot 52: ffffffc0
I just need to figure out how all this fits together before I can start parsing it.
Alright I think I figured it out, but Im missing one little thing. If looking in my samples above everything works fine if I completely ignore lines 40 and 41. Im guessing those are the actual TTL since they are kinda big? I was running it for a few other URLS and it looks like theres always 2 octets inbetween the CLASS and TTL fields whereas in the RFC they are right after each other, anybody know what they are or what they do? I can follow everything according to the RFCs if I just kinda ignore those 2 octets whenever they appear.