DNSSEC Guide : Chapter 5. Basic Troubleshooting

In this chapter, we are going to cover some basic troubleshooting techniques, common DNSSEC symptoms, and their causes and solutions. This is not a comprehensive "how to troubleshoot any DNS or DNSSEC problem" guide, because that in and of itself could easily be an entire book.

Query Path

The first step to your DNS or DNSSEC troubleshooting should be to determine the query path. This is not a DNSSEC-specific troubleshooting technique. Whenever you are working with a DNS-related issue, it is always a good idea to determine the exact query path to identify the origin of the problem.

End clients, such as laptop computers or mobile phones, are configured to talk to a recursive name server, and the recursive name server may in turn forward on to more recursive name servers, before arriving at the authoritative name server. The giveaway is the presence of the Authoritative Answer (aa) flag: when present, we know we are talking to the authoritative server; when missing, we are talking to the recursive server. The example below shows an answer without the Authoritative Answer flag:

$ dig www.example.com. A

; <<>> DiG 9.10.1 <<>> www.example.com. A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41006
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.		IN	A

;; ANSWER SECTION:
www.example.com.	600	IN	A	192.168.1.100

;; Query time: 21 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Mon Nov 03 19:54:37 CST 2014
;; MSG SIZE  rcvd: 60

Not only do we not see the aa flag, we see the presence of an ra flag, which represents Recursion Available. This indicates that the server we are talking to (192.168.1.7 in this example) is a recursive name server. And although we were able to get an answer for www.example.com, the answer came from somewhere else.

The example below shows when we query the authoritative server directly and see the presence of the aa flag:

$ dig @192.168.1.13 www.example.com. A

; <<>> DiG 9.10.1 <<>> @192.168.1.13 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35962
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
...

The presence of the aa flag tells us that we are now talking to the authoritative name server for example.com, and this is not a cached answer it obtained from some other name server, it served this answer to us right from its own database. In fact, if you look closely, the ra flag is not present, which means this name server is not configured to perform recursion (at least not for this client), so it could not have queried another name server to get cached results anyway.