3602 - Troubleshooting DNSSEC in NIOS

Scenario

You are a DNS administrator for a company,  part of your responsibilities is to resolve user submitted tickets.

Users have reported their inability to resolve some domains, In the ticket the user reported www.example.com to be one of the problematic domains. You were informed that some changes were made recently to the validating resolver IBNS1 (10.100.0.105) that might have caused the issue.

Please use your DNS knowledge to troubleshoot, locate the root cause(s), and make suggestions to the users.

Estimate Completion Time

• 30 to 45 minutes

Credentials

Course References

• 1204: DNSSEC Fundamentals

• 3011: DNS Troubleshooting Methodology

• 2204: Describing 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: First Ticket

• Some changes are made on the validating resolver IBNS1 (10.100.0.100) might have caused this issue. Troubleshoot the root cause.

  1. To verify the existence of the reported problem, execute the following command on the Jump-Desktop (10.35.22.10):

     dig @10.100.0.105 www.example.com. A

  2. Why did it fail?

Solutions

Task 1 solution: First Ticket

• The changes made to the validating resolver IBNS1 (10.100.0.105) were indeed the reason why this problem happened.

• Root Cause:

  1. You Verified that the problem does exist, and that is affected DNSSEC enabled domains.
     

     

  2. Why did the fail? The wrong trust anchor algorithm is selected on IBNS1 (10.100.0.105)

• Detailed Analysis:

We first verify this is indeed a DNSSEC issue by running the same command twice, first time without +cd, the second time with +cd, as shown below

We can see that this indeed is a DNSSEC validation problem, because when DNSSEC checking is disabled by the +cd switch, name resolves fine.
We can then check the configuration done on IBNS1 (10.100.0.105) by logging on to the Grid's UI (10.100.0.100) and navigating to Data Management → DNS, Toolbar → Grid DNS Properties → DNSSEC.
We see that almost all the configuration is set to the defaults but there is a trust anchor installed for root (.) under TRUST ANCHORS section.

We are not sure if this is a valid root anchor so we validate it using dig against a trusted public validating resolver, as shown below dig @8.8.8.8 . DNSKEY +multi

The output we generate notifies us that the two keys do in fact match but the key algorithms are different the one we have installed on our grid is RSA/SHA1(5) while the actual key(s) are RSA/SHA256(8) and no RSA/SHA1(5) keys are used.
This is proof that the key algorithm mismatch is the reason why the validation fails.