3612 - 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 DNS servers 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
45 to 60 minutes
Credentials
Description | Username | Password | URL or IP |
|---|---|---|---|
Grid Manager UI | admin | infoblox |
Course References
2009: Configuring NIOS DNS Services
2023: Configuring NIOS DNS Zones
3011: DNS Troubleshooting Methodology
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.
Launch Lab
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
User reports unable to resolve the name www.example.com. Please investigate root cause.
To verify the existence of the reported problem, execute the following command on the Jump-Desktop (10.35.22.10):
dig @10.100.0.100 www.example.com. AWhy did it fail?
For your convenience a packet captures are provided (3612-task1-ada.pcap and 3612-task1-bob.pcap)
Solutions
Task 1 solution: First Ticket
Root Cause:
ADA (10.100.0.100) forwards to BOB (10.200.0.253), which has EDNS0 disabled.
Detailed Analysis:
In the packet capture 3612-task1-ada.pcap we see ADA (10.100.0.100) sends the query for www.example.com to BOB (10.200.0.253), in packets #581 (query) and #582 (response), the DO bit is present.However, in the response packet #582, we do not see RRSIG
Since there are no RRSIG associated with www.example.com, the validating resolver ADA considers the domain name to be insecure, thus it checks the parent domain com to verify that it is indeed insecure, by asking for the DS record. This should have two possible normal outcomes:
example.com is insecure (not signed): we expect to receive NXDOMAIN response along with either NSEC or NSEC3 records
example.com is secure (signed): we expect to receive DS records and associated RRSIG
However, as seen below packet #584, there we receive just the DS records with no signatures. This causes the validating resolver ADA to return SERVFAIL to the client, and further research is required on theremote name server BOB (10.200.0.253), who accepts DO bit, but is has not returned the correct DNSSEC data.
We can also perform dig directly against BOB (10.200.0.253) to see that it does not return any RRSIG when we query for DS of com, a domain we know is signed. This is an indication something is wrong on the recursive name server BOB. The figure below shows the query and result.
The packet capture (3612-task1-bob.pcap) was taken at the same time as the previous capture (3612-task1-ada.pcap) one on ADA (10.100.0.100), except this one was performed on BOB (10.200.0.253). Notice the packet #265 that is highlighted below. This packet is BOB reaching out to the Internet querying for the DS record, however, there was no additional options field in the packet. This indicates a misconfiguration on BOB (10.200.0.253), that EDNS0 is disabled.
