Tuesday, May 24, 2016

DNS AAAA Query Response Decode

DNS Query

This is the Wireshark display of the IP packet containing a DNS query. The tenth byte, (often called byte 9 from offset zero by geeks), contains the embedded protocol.







It is a hex 11 or 0x11 which is 17 decimal. Three common embedded protocols are:
0x01 = ICMP
0x06 = TCP
0x11 = 17 decimal = UDP. This packet is UDP.

This diagram shows the fields in the IP Header. The protocol field is highlighted.




The next highlight is the UDP layer. It starts immediately after the IP layer ends.







The first two fields are the source and destination port, they are 16 bit fields. Source is 0xccc4 and Destination is 0x0035. 35 hex is 53 decimal, this packet is destined to go to a DNS server.


The next highlight is the DNS query. It starts immediately after the UDP header ends and is decoded from the beginning to the end.










Below we have a DNS Packet Header diagram. You can get the SANS TCP Cheat sheet here, it will be much easier for you to download, print it and use it as a reference.






































The first field is the Query ID sometimes called the Transaction ID. This 16 bit field uniquely identifies this query. When the response comes back we expect it to have the same Query ID. In this case it is 0x9332, which again, means nothing except that it is assigned to this query. The next query from this host will be a different value. On this Macintosh client it will be a very different value.







The next field is also 16 bits and it is called the flags. There are ten different flags as you can see from the header diagram. The value of the field is 0x100 and as Wireshark says, it is a standard query.

















This is followed by four 16 bit fields. Query count, Answer count, Authority record count and additional records count. The highlight below shows 0x0001 which is the question count, the sets of three 0x0000 cover Answer, Authority and Record.







The name of the system the query wants to look up is log.dropbox.com. The query name or QNAME begins with 0x03 and ends with 0x00. The 0x03 says there are three labels:

  • log
  • dropbox
  • com

0x00 is always the end of the QNAME.

We can use an ASCII table to convert the letters from hex to ASCII. The first byte in the QNAME is 0x6c which is an ASCII "l" and the last, (just before the 0x00), is 6d which is "m".








Two remaining fields to go, they are TYPE, (or QTYPE), 0x001c or 28 decimal, the client wants an IPv6, or AAAA, or "QuadA" name. This is becoming more common as the use of IPv6 is increasing. One other very common QTYPE is 0x0001, which is the A record, or IPv4 record name.

The very last field in this packet is CLASS, (or QCLASS) 0x0001. This is very standard, I have never seen a DNS query with anything else. It means this is an Internet query.

DNS Response

Here is the response. We are going to ignore the IP and UDP headers and jump right into the DNS response.









Responses, while quite similar to Queries are a bit more complex, but let's start with the easy parts. The first 16 bits 0x9e32 is the Query ID sometimes called the Transaction ID. This 16 bit field uniquely identifies this query. When the response comes back we expect it to have the same Query ID. In this case it is 0x9332 which it does.

The second 16 bit field is the flags, 0x8180, which in binary is:
10011000. The first 1, (on the left), indicates this is a response, the second, recursion is desired, the third is recursion is available.

Flags in a standard response















The next four fields: 0x01, 0x01, 0x01, 0x00, 1 query, 1 response, 1 authority, 0 additional records.

This takes us to the query. This is the same string as the query. Note that like the query it begins with 0x03, (there are three labels), log, getdropbox, com and then it ends with 0x00 end of labels, 0x001c, this is a TYPE, (or QTYPE), IPv6, or AAAA, or QuadA query. Finally the last field in the query is 0x01, CLASS, (or QCLASS) is Internet.
Query section of response mirrors original query












Easy, so far. Now the response resource record. There are six fields:
NAME: 0xcooc converted to binary 1100 0000 0000 1100. When the first two bits of the NAME are 11 it means we  have a pointer with a value of 12 decimal, (0x0c)
TYPE: 0x0005 It will be a Canonical name
CLASS: 0x0001 Internet or IN
TTL in seconds: 0x0000 09c0 2496 seconds, 41 minutes
RLENGTH: 0x0017, (23 decimal)
RDATA: This is where we find the canonical name 12 bytes into the answer section: getdropbox.v.dropbox.com  The ASCII representation for hex 62 6f 78 is box. We do not need the domain since we already have it: com. We can terminate a name with a pointer and that will lead us to the authority record.




Authority Resource Record

We start with the pointer c0 in binary 1100, the two high order 1s mean the name will be treated as a pointer. The pointer offset is 0x1b = 27 decimal. 
NAME:
TYPE: 0x0006 Start Of Authority. (SOA)
CLASS: 0x0001 Internet or IN
TTL in seconds: 0x0000 0044 = 68 seconds
RLENGTH: 0x0045, (69 decimal)
RDATA: SOA has a defined format:
Primary NS Name of the Primary Master for the domain.
Admin MB The administrator's mailbox.
These are followed by 5 32 bit fields

  • Serial Number
  • Refresh interval  
  • Retry Interval
  • Expiration Limit
  • Minimum TTL













Primary NS Name of the Primary Master for the domain (MNAME):
ns-773.awsdns-32.net, since we are switching from .com to .net we need to spell it out.
6e 65 74 = net and followed by 0x00 to terminate the label.











Admin MB  The administrator's mailbox.
Note: 0xc0 1b we terminate with a pointer to get the com.










These are followed by 5 32 bit fields. These are guides for other nameservers and since the SOA lists the primary name server this data is used by the secondary servers.




  • Serial Number 0x00 00 00 01 = 1
  • Refresh interval 0x00 00 1c 20 = 7200 seconds or 120 minutes for the secondaries to update the zone maps. 
  • Retry Interval  0x00 00 03 84 = 900 seconds - 15 minutes, (time interval that should elapse before a failed refresh should be retried.)
  • Expiration Limit  0x00 12 75 00 1209600 seconds (which is within the range recommended by RFC 1912 14 - 28 days) If this upper limit elapses, the zone is no longer considered authortative.
  • Minimum TTL 0x00 00 01 2c = 300 seconds 5 minutes

No comments:

Post a Comment