DNS responses are also important for security; consider the network shown in Figure 16-9.
Figure 16-9 DNS Man-in-the-Middle Attacks
1. Host A sends a query to the recursive server.
2. The recursive server sends a query to the authoritative server.
3. The authoritative server responds with the correct answer, pointing the user to server B.
4. An attacker, observing this transaction, sends a response to the recursive server just a few moments later. This response points the user to the attacker’s server, D, rather than the correct server. The recursive server’s cache is now poisoned; it will give incorrect answers to other hosts asking how to reach this domain name.
5. The recursive server sends the misdirected response, pointing at server D rather than B, to host A.
6. Host A connects to the IP address supplied by the recursive server; there is no way for host A to know this is not the correct server.
7. The attacker’s server, D, connects to the correct server, B, so it passes the user’s transactions back to the correct server. The user believes their transactions are processing normally.
The attacker can now see the transactions between the user and the server. Session encryption cannot solve this problem because host A will build an encrypted session with D just as easily as with B.
One way to solve this problem is for the host to find another source for the server’s encryption certificate than the server itself. CAA DNS records provide an independent source of certificates for a given server. If the attacker is astute, however, they can also poison the cached version of the CAA records.
Another option is to sign DNS records using a set of extensions to DNS called DNSSEC.
A signature is created using cryptographic algorithms. Each DNS owner can sign their DNS records using a private key, and hosts can check the signature using a public key. There is no way an attacker can re-create the signature on the DNS response they send to poison the recursive server’s cache.
Diagnosing DNS
As with all services on a network, DNS does not always work correctly. If you cannot reach a website—or some other service —because the name does not resolve, how can you track down and correct the problem? You can use several tools and techniques, including nslookup, dig, and web-based tools.
Name Server Lookup
Name Server Lookup (nslookup ) is available on Windows, Apple macOS, and Linux. This ubiquitous tool can be used to manually resolve a domain name.
While these examples use nslookup in interactive mode, you can also enter these same commands on the command line.
Let’s begin by entering interactive mode and setting the recursive name server to 9.9.9.9:
PS C:\Windows\System32> nslookup
Default Server: rns01.charter.com
Address: 71.10.216.1
> server 9.9.9.9
Default Server: dns9.quad9.net
Address: 9.9.9.9
DNS queries will now be sent to 9.9.9.9. Now let’s do a simple lookup:
> rule11.tech
Server: dns9.quad9.net
Address: 9.9.9.9
Non-authoritative answer:
Name: rule11.tech
Addresses: 192.0.2.1
192.0.2.2
There are two addresses because the server, in this case, has two different public-facing interfaces. The service rule11.tech can be reached using either of these addresses.
The response shown for rule11.tech is a non-authoritative answer because the DNS server responded using cached information; it did not ask the authoritative server for this information. A non-authoritative response is not incorrect, invalid, or “stale.”
The nslookup utility can do much more than resolve domain names, such as resolving DNS aliases or CNAMEs:
> set type=CNAME
> www.rule11.tech
Server: dns9.quad9.net
Address: 9.9.9.9
Non-authoritative answer:
www.rule11.tech canonical name = rule11.tech
To query for a CNAME, use set type=CNAME. The response is again non-authoritative; www.rule11.tech points to rule11.tech.
Whenever someone tries to reach www.rule11.tech, the DNS server will answer with rule11.tech’s IP address instead.
If a mail server needs to know the IP address of rule11.tech’s email service, it would look up the MX record for this domain:
> set type=MX
> www.rule11.tech
Server: dns9.quad9.net
Address: 9.9.9.9
Non-authoritative answer:
www.rule11.tech canonical name = rule11.tech rule11.tech MX preference = 10, mail exchanger = rule11.tech MX preference = 20, mail exchanger =
The answer indicates the mail server needs to send any mail to a server in messagingengine.com, an email hosting service. The mail server needs to look up the MX record for one of these servers to find their IP address. nslookup can also tell you the domain name of the authoritative server for a domain name:
> www.rule11.tech
Server: dns9.quad9.net
Address: 9.9.9.9
Non-authoritative answer:
www.rule11.tech canonical name = rule11.tech rule11.tech nameserver = pdns1.registrar-serv rule11.tech nameserver = pdns2.registrar-serv
TLD servers will answer with this information when telling a recursive server where to ask about rule11.tech. You can also use nslookup to discover the TTL for a domain name:
> set type=SOA
> www.rule11.tech
Server: dns9.quad9.net
Address: 9.9.9.9
Non-authoritative answer:
www.rule11.tech canonical name = rule11.tech rule11.tech primary name server = pdns1.registrar-se responsible mail addr = hostmaster.regist serial = 1613507444 refresh = 43200 (12 hours) retry
3600 (1 hour)
expire = 604800 (7 days)
default TTL = 3601 (1 hour 1 sec)
The DNS start of authority (SOA) record contains information like the domain administrator’s email address and the TTL.
Finally, you can also discover what domain name an IP address is associated with by using nslookup:
> set type=PTR
> 192.0.2.1
Server: dns9.quad9.net
Address: 9.9.9.9
Non-authoritative answer:
1.2.0.192.in-addr.arpa name = wpx.net
Mail servers use this kind of reverse lookup to verify a sender’s domain is the same as their mail server’s domain.