DNSSEC Guide : How To Test Recursive Server (So You Think You Are Validating)

How To Test Recursive Server (So You Think You Are Validating)
Prev	DNSSEC Guide : Chapter 3. Validation	Next

How To Test Recursive Server (So You Think You Are Validating)

Okay, so now that you have reconfigured your recursive server and restarted it, how do you know that your recursive name server is actually verifying each DNS query? There are several ways to check, and we've listed a few suggestions below, starting with the easiest.

Using Web-based Tools to Verify

For most people, the simplest way to check if the recursive name server is indeed validating DNS queries, is to use one of the many web-based tools.

Configure your client computer to use the newly reconfigured recursive server for DNS resolution, and then you can use any one of these web-based tests to see if it is in fact validating answers DNS responses.

Using dig to Verify

The web-based tools often employ JavaScript. If you don't trust the JavaScript magic that the web-based tools rely on, you can take matters into your own hands and use a command line DNS tool to check your validating resolver yourself.

While nslookup is popular, partly because it comes pre-installed on most systems, it is not DNSSEC-aware. The Domain Information Groper (dig), on the other hand, fully supports the DNSSEC standard, and comes as a part of BIND. If you do not have dig already installed on your system, install it by downloading it from ISC's web site. ISC provides pre-compiled Windows versions on its web site.

dig is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. Most seasoned DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use, and clarity of output.

The example below shows using dig to query the name server 192.168.1.7 for the A record for www.isc.org if DNSSEC is disabled. The address 192.168.1.7 is only used as an example, you should replace this address with the actual address or host name of your recursive name server. Notice although we specifically used the +dnssec command line option, we do not see the DNSSEC OK (do) bit in the response, nor do we see any DNSSEC resource records.

$ dig @192.168.1.7 www.isc.org. A +dnssec +multiline
; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20416
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

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

;; ANSWER SECTION:
www.isc.org.		60	IN	A	149.20.64.69

Below shows what the results look like querying the same server (192.168.1.7) after enabling DNSSEC validation. The exact same command is run, and this time notice three key differences:

The presence of the Authenticated Data (ad) flag in the header
The DNSSEC OK (do) flag indicating the recursive server is DNSSEC-aware
An additional resource record of type RRSIG, with the same name as the A record.

The DNSSEC OK (do) flag tells us that the recursive server we are querying (192.168.1.7 in this example) is DNSSEC-aware but not necessarily that it is configured to perform DNSSEC validation. The Authenticated Data (ad) flag tells us that the answer received has passed the validation process as described in the section called “How are Answers Verified?”. We can have confidence in the authenticity and integrity of the answer that www.isc.org really points to the IP address 149.20.64.69, and it was not a spoofed answer from a clever attacker.

$ dig @192.168.1.7 www.isc.org. A +dnssec +multiline

; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32472
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.isc.org.		IN A

;; ANSWER SECTION:
www.isc.org.		4 IN A	149.20.64.69
www.isc.org.		4 IN RRSIG A 5 3 60 (
				20141029233238 20140929233238 4521 isc.org.
				DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
				5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
				E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
				jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

;; Query time: 3 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 03 16:40:04 CST 2014
;; MSG SIZE  rcvd: 223

Using delv to Verify

If you have BIND 9.10 or later, you can use Domain Entity Lookup & Validation (delv) to validate your setup. This program is similar to dig, but is specifically tailored for DNSSEC.

Without DNSSEC:

$ delv @192.168.1.7 www.isc.org. A
;; no valid RRSIG resolving 'org/DS/IN': 192.168.1.7#53
;; no valid DS resolving 'www.isc.org/A/IN': 192.168.1.7#53
;; resolution failed: no valid DS

delv also comes with a handy +rtrace (trace resolver fetches) switch that shows a little more information on what was fetched:

$  delv @192.168.1.7 www.isc.org. A +rtrace
;; fetch: www.isc.org/A
;; fetch: org/DS
;; no valid RRSIG resolving 'org/DS/IN': 192.168.1.7#53
;; no valid DS resolving 'www.isc.org/A/IN': 192.168.1.7#53
;; resolution failed: no valid DS

After enabling DNSSEC validation, re-running the exact same codes show us the following results:

$ delv @192.168.1.7 www.isc.org. A +multiline
; fully validated
www.isc.org.		60 IN A	149.20.64.69
www.isc.org.		60 IN RRSIG A 5 3 60 (
				20141029233238 20140929233238 4521 isc.org.
				DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
				5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
				E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
				jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

And +rtrace shows all the glory of what records were fetched to validate this answer:

$ delv @192.168.1.7 www.isc.org +rtrace +multiline
;; fetch: www.isc.org/A
;; fetch: isc.org/DNSKEY
;; fetch: isc.org/DS
;; fetch: org/DNSKEY
;; fetch: org/DS
;; fetch: ./DNSKEY
; fully validated
www.isc.org.		19 IN A	149.20.64.69
www.isc.org.		19 IN RRSIG A 5 3 60 (
				20141029233238 20140929233238 4521 isc.org.
				DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
				5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
				E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
				jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

Verifying Protection from Bad Domain Names

It is also important to make sure that DNSSEC is protecting you from domain names that fail to validate; such failures could be caused by attacks on your system, attempting to get it to accept false DNS information. Validation could fail for a number of reasons, maybe the answer doesn't verify because it's a spoofed response; maybe the signature was a replayed network attack that has expired; or maybe the child zone has been compromised along with its keys, and the parent zone's information is telling us that things don't add up. There is a domain name specifically setup to purposely fail DNSSEC validation, www.dnssec-failed.org. Prior to enabling DNSSEC validation, you should have no trouble visiting the URL http://www.dnssec-failed.org/ in your web browser:

And no problem resolving the domain name as shown below using dig:

$ dig @192.168.1.7 www.dnssec-failed.org. A

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28878
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org.		IN	A

;; ANSWER SECTION:
www.dnssec-failed.org.	7200	IN	A	68.87.109.242
www.dnssec-failed.org.	7200	IN	A	69.252.193.191

;; Query time: 955 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 17 07:42:50 CST 2014
;; MSG SIZE  rcvd: 82

After DNSSEC validation is enabled, any attempt to loading the URL should result in some kind of "Sorry, this page cannot be displayed" error message from your web browser. And looking up this domain name using dig should result in SERVFAIL, as shown below:

$ dig @192.168.1.7 www.dnssec-failed.org. A

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46592
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org.		IN	A

;; Query time: 2435 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 17 07:44:56 CST 2014
;; MSG SIZE  rcvd: 50

How Do I know I Have a Validation Problem?

Since all DNSSEC validation failures result in a general SERVFAIL message, how do we know that it was related to validation in the first place? Fortunately, there is a flag in dig, (+cd, checking disabled) which tells the server to disable DNSSEC validation. When you've received a SERVFAIL message, re-run the query one more time, and throw in the +cd flag. If the query succeeds with +cd, but ends in SERVFAIL without it, then you know you are dealing with a validation problem.

$ dig @192.168.1.7 www.isc.org. A +cd

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.isc.org. A +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33590
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
www.isc.org.		30	IN	A	149.20.64.69

For more information on troubleshooting, please see Chapter 5, Basic Troubleshooting.

Prev	Up	Next
Chapter 3. Validation	DNSSEC Guide Table of Contents (License)	Validation Easy Start Explained