3603 - Analyzing DNSSEC packet capture

Scenario

DNSSEC has been recently enabled across your organization. Someone from a different team encountered a domain name that appears to be insecure. They cannot figure out if this is normal behavior or a misconfiguration, and have provided a traffic capture to you, the DNSSEC guru, to tell them what is really going on. 

Estimate Completion Time

• 25 to 35 minutes

Credentials

Course References

• 1204: DNSSEC Fundamentals

• 3011: DNS Troubleshooting Methodology

• 2204: Explaining DNSSEC

• 2025: Configuring Recursive DNSSEC in NIOS
  

Lab Initiation

Access jump-desktop

Once the lab is deployed, you can access the virtual machines required to complete this lab activity. To initiate the lab, click on the jump-desktop tile and login to the Linux UI:

Username: training

Password: infoblox

Initiate lab

To initiate the lab, double-click the Launch Lab icon on the Desktop.

Choose the lab number from the list and click OK.

After clicking OK, you will see a pop-up message with a brief description of the lab task. If the description looks correct, click Yes to continue lab initiation.

Lab initiation will take a couple of minutes to finish.

Once complete, you will see another pop-up message with the login credentials and the URL for the Grid Manager’s User Interface. Note that the credentials may differ from those from prior labs.

Tasks

Task 1: Analyzing the traffic capture

Since DNSSEC has been enabled, some administrators expect every domain name will now be fully validated. One of such domain name is insecure.training.infoblox.com. However, this name does not come with the AD flag. A traffic capture has been taken at a different environment where this happened, it is now available to you: 3603-task1.pcap. Please analyze and provide an explanation to the other DNS administrators why the name insecure.training.infoblox.com. does not come with the AD flag.

To help you orient yourself quicker when analyzing the packet capture: the client IP address is 10.35.22.10, the validating resolver is 10.100.0.100, which is forwarding all DNS queries to a forwarder, 10.100.0.198. The forwarder 10.100.0.198 is the one that can access the Internet.
Since the domain name insecure.training.infoblox.com is available on the Internet, feel free to use the online graphical analysis tools to aid your troubleshooting.

Solutions

Task 1 solution: Analyzing the traffic capture

Root Cause

This domain name, insecure.training.infoblox.com, is insecure. Thus there is no AD flag in the response to the clients. The easiest way to verify this is to use an online analyzer such as DNSViz to clearly see that this domain name is not signed. 

Detailed Analysis

The easiest way to verify this, is to use an online analyzer such as DNSSEC analyzer (https://dnssec-analyzer.verisignlabs.com). This is a sample output when we used the online tool to analyze this domain name:

While the parent domains from root, com, infoblox.com, and training.infoblox.com are all signed, the domain insecure.training.infoblox.com is not signed. Another way we can verify this, is by querying for the DS record of this delegated name, insecure.training.infoblox.com:

1. The name insecure.training.infoblox.com is a delegated name, separate from the signed parent zones

2. The delegated domain is not signed by DNSSEC

We can also break down the packet capture itself, and explain each relevant entry. For this analysis, we will focus on packets from #219 to #235.

In packets #219 and #220, the recursive server queried for the A record, and received just the A record with no RRSIG. This put the validating resolver on a path to start from the top, as shown in the following figure then summarized by the table below it:

The validating stops at packet #235, when the response from the authoritative server for training.infoblox.com include an NSEC record, denying the existence of DS record for insecure.training.infoblox.com. By definition, if there is no DS record for the zone, the zone is insecure.