3604 - Troubleshooting DNSSEC in NIOS

Scenario

A packet capture was provided to you alongside syslog messages. the behavior was captured as a way to troubleshoot an ongoing DNSSEC issue in your organization, Please Investigate the packet capture and the syslog message to figure out the issue.

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: Analyze the traffic capture

• In this task we will use a previously taken packet capture file 3604-task1-ada.pcap and some syslog messages to determine what the issue was.

  1. Execute the following command on the Jump-Desktop (10.35.22.10):

     ^{dig @10.100.0.105 broken.training.infoblox.com. A}

  2. On the Grid Master IBNS1 (10.100.0.100), navigate to Administration → Logs → syslog

     1. What log messages were generated from resolving this bogus domain name?

     2. Look into the capture file, was there any packet that shows the answer is bogus?

Solutions

Task 1 solution: Analyze the traffic capture

• Root cause

  1. The output of the command does show a SERVFAIL response code and this is because the domain name is bogus as reported due to DS record and DNSKEY mismatch, syslog shows it more clearly than packet capture.

     

• Detailed Analysis

  Keep in mind that bogus domains are really signed domains that has an error that caused validation. Thus, it usually has all of the same information as a secure domain, just the information doesn't match up.
  In that case,reading the packet capture is a difficult way to determine that the validation failed, requiring us to read each packet detail, noting down the key ID, and tracing it manually.
  In the provided packet capture file lab4-task6-ada.pcap, we need to look at the RRSIG in packet #325 to find the ZSK key tag, then check packet #327 to find corresponding KSK key tags in the DNSKEY RRSIG, and again in packet # 329 look for the key tag in the DS record response.
  There is no clear missing packet that tells us what the problem is, and that's the point of this task: it's hard to determine that the domain name is bogus from reading packet captures, the better and easier way is to look at syslog.
  As shown below, syslog shows all of the validation checks that failed while resolving this name.

  

  
  We can also use DNSSEC analyzer to summarize this quicker for us, a shown below

  

  For even more clear visual representation, use DNSViz to show the missing link as shown below