There are 5 chapters left, including this one, and I would like to finish my chapter by chapter review before next year, so I’ll have to do more than one of these per month, at least one month. I’ll probably do two a month to accelerate the process. I apologize for the interruption to the current series, but we’ll return to it next week.
Chapter 8 is about DNS, or the Domain Name System. As Michael W. Lucas states, there are books much larger than this one that cover this single topic alone, so this chapter is a very brief overview into the fundamentals of viewing it from a troubleshooting perspective.
The service runs on port 53, both UDP and TCP. Many organizations only allow port 53 UDP traffic, but TCP is required for larger requests. The chapter discusses how DNS servers keep a mapping of name and IP address relationships for translating requests between the two.
The name mappings are defined within zones. Each layer of an address (read right to left) represents another zone. For example, the “.net,” “.com,” and “.org” endings we often use are top level zones. The book’s examples include “google.com” and “michaelwlucas.com” as child zones of the top level “.com” zone. Any zone inside another zone is a child zone. This could mean a1.www.mysite.noip makes www.mysite.noip a child zone of mysite.noip, which is in turn a child zone of .noip, in this scenario.
DNS servers are either authoritative, or recursive. Authoritative nameservers contain the information for specific domains. Recursive nameservers provide DNS lookups for clients. These servers find the authoritative servers, then query it, then returns the result to the client.
Ideally, authoritative and recursive nameservers should be on separate machines. This is for security reasons, as well as simplification of configuration.
Next, the author covers the DNS hierarchy, explaining how DNS is a distributed database, and how the queries work their way up the chain until a server is capable of providing an authoritative response. Then, he goes into forward and reverse lookups. A forward lookup is the response given when querying what IP(s) belong to a name. A reverse lookup is the response when querying what name belongs to an IP, also known as an PTR record. The protocol allows for multiple PTR records for the same name, but in practice, this can break things.
The next section covers the different types of records that are relevant to most situations, such as A (name to IPv4,) AAAA (name to IPv6,) SOA (start of authority,) PTR, CNAME (canonical name… name to name alias mapping,) and MX (mail exchange) records.
A brief discussion of caching follows, which explains that changes can take time to propagate. Then he covers why checking DNS is important. If a server is responding with incorrect or even inconsistent information, it will likely cause issues with other troubleshooting steps.
He suggests using “nslookup” on Windows and “host” on Unix systems, but the “host” command may not be available. He covers both of these tools in detail before briefly introducing the more advanced “dig” and “unbound-host” commands. Finally he explains the “hosts” file for local name to IP mappings that may override responses from DNS, depending on how a system is configured.
And I’ll wrap this review with a sentence that leads to a footnote, then the footnote attached.
“A few failed DNS requests can drag some server software to a crawl or make it entirely fail.”
Footnote:
“Should software be written such that it handles DNS failures gracefully? Of course. And in that world, I have a pony. No, wait — a unicorn. No, better still — a ponycorn!”