How DNS works?

In our previous articles on DNS we gave an overview of the recursion process, but before we can go further on how DNS impacts performance, we need to understand how it the DNS protocol works.

In the TCP/IP Protocol suite, DNS is an application layer protocol. DNS protocol relies on User Datagram Protocol (UDP) by default, but can also work over Transmission Control Protocol (TCP) as a fallback when firewalls block UDP.

Both UDP and TCP are transport layer protocols. UDP is lightweight protocol which does not require a handshake to establish connection, or confirmation of delivery, thereby reducing the number of packets required, time elapsed, and round trips. The biggest con of the UDP is that there is no assurances the packet was received by the other party, hence the application has to handle cases where no response is received.

On the other side, TCP requires establishing a connection via a three-step handshake and has delivery error checking, but requires more roundtrips and therefore more time.

Since we are covering TCP/IP protocols, we will go down to the bit-level in certain areas. But don’t get scared – you do not have to learn how to deal with “bit flags” to understand DNS. At Catchpoint we use – and heavily recommend using – a packet capture program such as Wireshark to make packets human readable and debugging easier.

Protocol

DNS protocol is composed of three types of messages: queries, responses, and updates. We will not be covering “updates” in our series since it does not impact end-user experience. The DNS message can have five sections: the DNS Header, Question, Answer Resource Records, the Authority Resource Records, and the Additional Resource Records.

Header

The header of the packet contains identifying information, along with hints (summaries) about what the rest of the message contains. The header is made up of six fields, sixteen bits each, for a total of twelve bytes. The first sixteen bits are for the Transaction ID, used to match the response to the query, and is created by the client on the query message and returned by the server in the response.

The next field is for flags. This is probably the most important part of the DNS packet, as these flags distinguish response from query, and iterative from recursive query. They are listed, in order:

• Bit 1: QR, query/response flag. When 0, message is a query. When 1, message is response.
• Bits 2-5: Opcode, operation code. Tells receiving machine the intent of the message. Generally 0 meaning normal query, however there are other valid options such as 1 for reverse query and 2 for server status.
• Bit 6: AA, authoritative answer. Set only when the responding machine is the authoritative name server of the queried domain.
• Bit 7: TC, truncated. Set if packet is larger than the UDP maximum size of 512 bytes.
• Bit 8: RD, recursion desired. If 0, the query is an iterative query. If 1, the query is recursive. See our recursion post for more information.
• Bit 9: RA, recursion available. Set on response if the server supports recursion.
• Bit 10: Z. Reserved for future use, must be set to 0 on all queries and responses.
• Bit 11: AD, authentic data. Used in DNSSEC. Considered part of Z in older machines.
• Bit 12: CD, checking disabled. Used in DNSSEC. Considered part of Z in older machines.
• Bit 13-16: Rcode, return code. It will generally be 0 for no error, or 3 if the name does not exist.

The remaining four header fields are number of questions, answer resource records, authority resource records, and additional resource records. These numbers vary depending on whether it is a query or response, and what kind of response. In general, however, there will always be at least one question.

Question

The question is present in both the query and the response, and should be identical. Some tools, like Wireshark, call it “Query” (see image above).

In general there will only be one question, or query, per packet. The question is made up of three parts: the query name, which would be a host name such as www.google.com, a question type, and a question class, which is almost always 1 or IN for internet. The question type is the type of resource record. There are several major types listed below, and a full list can be found here.

• A, IPv4 address: to which the domain name maps. Every website domain must have at least either 1 A record, otherwise your end users won’t be able to access your website.
• AAAA, Quad-A, IPv6 address record: The IPv6 address is the type to which the domain name maps. As IPv4 addresses are not available any longer, there is a big movement to support IPv6 – however not every ISP and website supports it yet.
• MX, Mail eXchange record: Specifies which mail server accepts email messages on behalf of the recipient of the domain.
• NS, Name Server record: Maps a domain to its authoritative name server. Every domain must have more than 1 NS record.

Answer Resource Records

The answer consists of the resource records that answer the question. The “Answer” section is present on the response from recursive resolver to an end user’s computer, or in the response from the authoritative name server of the domain to the recursive resolver. It depends on the type of question, but for DNS resolution of web domains it will be A, AAAA, or CNAME. CNAME stands for Canonical Name, it means that the domain in the query is an alias for another domain.

The first three fields in the resource record are identical to the question format, and are RR name, RR type, and RR class. However, RRs contain three additional fields, a two-byte time-to-live value, a one byte data length field, and a data field. The data field contents vary depending on the type of record, but here are the major ones:

• A: One data field storing a four-byte IPv4 address
• AAAA: One data field storing a sixteen-byte IPv6 address
• MX: Two data fields, one storing a priority value and one storing an IP address
• NS: One data field storing the domain name of the authoritative name server
• CNAME: One data field storing the domain name to which the question domain is alias

Authority Resource Records

When a name server like TLDs does not have the answer to the query (as is not authoritative), it will not send answer records. Instead it will populate the authority section with all of the name servers that it knows as authoritative to the domain or part of the domain tree (like .com), if it has them. These NS records are different from A records as they have a domain name in both the RR name and RR data fields. Unlike the answer section, the authority section can only have NS records. Note that NS records can be sent in other sections.

Additional Records

Additional or “glue” records help avoid additional recursion by providing the IP addresses (A or AAAA records) of the NS records sent in the authoritative or answer section, so that those domains do not need to be resolved. These RRs are usually the A and/or AAAA records for the NS records in the authority section, although they can be any record.

Be sure to check out next week’s post as well, when we’ll be continuing our exploration of DNS by covering the caching process.