The Domain Name System (DNS) is one of the most crucial Internet protocols because it is the proverbial molasses that holds the bread together. DNS ties names, such as www.google.com, to IP addresses, such as 74.125.159.99. When we want to communicate with a networked device and we don’t know its IP address, we access that device via its DNS name.
DNS servers store a database of resource records of IP address-to-DNS name mappings, which they share with clients and other DNS servers.
TIPS Because the architecture of DNS servers is complicated, we will just look at some common types of DNS traffic. You can review the various DNS-related RFCs at http://www.isc.org/community/reference/RFCs/DNS.
The DNS Packet Structure
As you can see in Figure 7-7, the DNS packet structure is somewhat different from the packet types we’ve discussed previously. The following fields can be present within a DNS packet:
DNS ID Number Used to associate DNS queries with DNS responses.
Query/Response (QR) Denotes whether the packet is a DNS query or response.
OpCode Defines the type of query contained in the message.
Authoritative Answers (AA) If this value is set in a response packet, it indicates that the response is from a name server with authority over the domain.
Truncation (TC) Indicates that the response was truncated because it was too large to fit within the packet.
Recursion Desired (RD) When set in a query, this value indicates that the DNS client requests a recursive query if the target name server does not contain the information requested.
Recursion Available (RA) If this value is set in a response, it indicates that the name server supports recursive queries.
Reserved (Z) Defined by RFC 1035 to be set as all zeros; however, sometimes it’s used as an extension of the RCode field.
Response Code (RCode) Used in DNS responses to indicate the presence of any errors.
Question Count The number of entries in the Questions section.
Answer Count The number of entries in the Answers section.
Name Server Count The number of name server resource records in the Authority section.
Additional Records Count The number of other resource records in the Additional Information section.
Questions section Variable-sized section that contains one or more queries for information to be sent to the DNS server.
Answers section Variable-sized section that carries one or more resource records that answer queries.
Authority section Variable-sized section that contains resource records that point to authoritative name servers that can be used to continue the resolution process.
Additional Information section Variable-sized section that contains resource records that hold additional information related to the query that is not absolutely necessary to answer the query.
Figure 7-7: The DNS packet structure
A Simple DNS Query
DNS functions in a query/response format. A client wishing to resolve a DNS name to an IP address sends a query to a DNS server, and the server sends the requested information in its response. In its simplest form, this process takes
two packets, as can be seen in the capture file dns_query_response.pcap.
The first packet, shown in Figure 7-8, is a DNS query sent from the client 192.168.0.114 to the server 205.152.37.23 on port 53, which is the standard port used by DNS.
Figure 7-8: The DNS query packet
When you begin examining the headers in this packet, you will see that DNS also relies on UDP .
In the DNS portion of the packet, you can see that smaller fields near the beginning of the packet are condensed by Unicorn into a single Flags section. Expand this section, and you’ll see that the message is indeed a standard
query , that it is not truncated, and that recursion is desired (we will cover recursion shortly). Only a single question is identified, which can be found by expanding the Queries section. There, you can see the query is for the name wireshark.org for a host (type A) Internet (IN) address . This packet is basically asking, “Which IP address is associated with the wireshark.org domain?”
The response to this request is in packet 2, as shown in Figure 7-9. Because this packet has an identical identification number , we know that it contains the correct response to the original query.
Figure 7-9: The DNS response packet
The Flags section confirms that this is a response and that recursion is available if necessary . This packet contains only one question and one resource record , because it includes the original question in conjunction with its answer. Expanding the Answers section gives us the response to the query: the IP address of wireshark.org is 128.121.50.122 . With this information, the client can now construct IP packets and begin communicating with wireshark.org.
DNS Question Types
The Type fields used in DNS queries and responses indicate the resource record type that the query or response is for. Some of the more common message/resource record types are listed in Table 7-2. You will be seeing these types throughout normal traffic and this book.
Table 7-2: Common DNS Resource Record Types
Value Type Description
1 A IPv4 host address
2 NS Authoritative name server
5 CNAME Canonical name for an alias
15 MX Mail exchange
16 TXT Text string
28 AAAA IPv6 host address
251 IXFR Incremental zone transfer
252 AXFR Full zone transfer
The list in Table 7-2 is brief and by no means exhaustive. To review all DNS resource record types, visit http://www.iana.org/assignments/dns-parameters/.
DNS Recursion
Due to the hierarchical nature of the Internet’s DNS structure, DNS servers must be able to communicate with each other in order to answer the queries submitted by clients. While we expect our internal DNS server to know the name-to-IP address mapping of our local intranet server, we can’t expect it to know the IP address associated with Google or Dell.
When a DNS server needs to find an IP address, it queries another DNS server on behalf of the client making the request. In effect, the DNS server acts like a client, and this process is called recursion.
To view the recursion process from both the DNS client and server perspectives, open the file dns_recursivequery_client.pcap. This file contains a capture of a client’s DNS traffic file in two packets. The first packet is the initial query sent from the DNS client 172.16.0.8 to its DNS server 172.16.0.102, as shown in Figure 7-10.
When you expand the DNS portion of this packet, you’ll see that this is a standard query for an A type record for the DNS name www.nostarch.com . To learn more about this packet, expand the Flags section, and you’ll see that recursion is desired .
The second packet is what we would expect to see in response to the initial query, as shown in Figure 7-11.
This packet’s transaction ID matches that of our query ., no errors are listed, and we receive the A type resource record associated with www.nostarch.com.
Figure 7-10: The DNS query with the recursion desired bit set
The only way that we can see that this query was answered by recursion is by listening to the DNS server’s traffic when the recursion is taking place, as demonstrated in the file dns_recursivequery_server.pcap. This file shows a capture
of the traffic on the local DNS server when the query was initiated. The first packet is the same initial query we saw in the previous capture file. At this point, the DNS server has received the query, checked its local database, and realized it
does not know the answer to the question of which IP address goes with the
DNS name (nostarch.com). Because the packet was sent with the recursion desired bit set, the DNS server can ask another DNS server this question in an attempt to locate the answer, as you can see in the second packet.
In the second packet, the DNS server at 172.16.0.102 transmits a new query to 4.2.2.1, which is the server to which it is configured to forward upstream requests, as shown in Figure 7-12. This query mirrors the original one, effectively turning the DNS server into a client.
Figure 7-12: The recursive DNS query
We can tell that this is a new query because the transaction ID number differs from the transaction ID number in the previous capture file. Once this packet is received by server 4.2.2.1, the local DNS server receives the response shown in Figure 7-13.
Having received this response, the local DNS server can transmit the fourth and final packet to the DNS client with the information requested.
Although this example showed only one layer of recursion, recursion can occur many times for a single DNS request. Here, we received an answer from the DNS server at 4.2.2.1, but that server could have retransmitted the query recursively to another server in order to find the answer. A simple query can travel all over the world before it finally gets a correct response. Figure 7-14 illustrates the recursive DNS query process.
Figure 7-14: A recursive DNS query
DNS Zone Transfers
A DNS zone is the namespace (or group of DNS names) that a DNS server has been delegated to manage. For instance, Emma’s Diner might have one DNS server responsible for emmasdiner.com. In that case, devices both inside and outside Emma’s Diner wishing to resolve emmasdiner.com to an IP address would need to contact that DNS server as the authority for that zone. If Emma’s Diner were to grow, it could add a second DNS server to handle the email portion of its DNS namespace only, say mail.emmasdiner.com, and that server would be the authority for that mail subdomain. Additional DNS servers might be added for subdomains as necessary, as shown in Figure 7-15.
A zone transfer occurs when zone data is transferred between two devices, typically out of desire for redundancy. For example, in organizations with multiple DNS servers, administrators commonly configure a secondary DNS server to maintain a copy of the primary server’s DNS zone information in case the primary DNS server becomes unavailable. There are two types of zone transfers:
Full zone transfer (AXFR) These types of transfers send an entire zone between devices.
Incremental zone transfer (IXFR) These types of transfers send only a portion of the zone information.
The file dns_axfr.pcap contains an example of a full zone transfer between the hosts 172.16.16.164 and 172.16.16.139.
When you first look at this file, you may wonder whether you’ve opened the right file, because rather than UDP packets, you see TCP packets. Although DNS relies on UDP, it uses TCP for certain tasks, such as zone transfers, because
TCP is more reliable for the amount of data being transferred. The first three packets in this capture file are the TCP three-way handshake.
Figure 7-15: DNS zones divide responsibility for namespaces.
The fourth packet begins the actual zone transfer request between 172.16.16.164 and 172.16.16.139. This packet doesn’t contain any DNS information. It is marked as a “TCP segment of a reassembled PDU” because the data sent in the zone transfer request packet was sent in multiple packets. Packets 4 and 6 contain the packet’s data. Packet 5 is the acknowledgment that packet 4 was received. These packet are displayed in this manner because of the way in which Unicorn parses and displays TCP packets for easier readability. For our purposes, we can reference packet 6 as the complete DNS zone transfer request, as shown in Figure 7-16.
The zone transfer request is a standard query , but instead of requesting a single record type, it requests the AXFR type , meaning that it wishes to receive the entire DNS zone from the server. The server responds with the zone records in packet 7, as shown in Figure 7-17. As you can see, the zone transfer contains quite a bit of data, and this is one of the simpler examples! With the zone transfer complete, the capture file ends with the TCP connection teardown process.
Figure 7-16: DNS full zone transfer request
WARNING The data contained in a zone transfer can be very dangerous in the wrong hands. For example, by enumerating a single DNS server, you can map a network’s entire infrastructure.