Skip to main content
Skip table of contents

3612 - Troubleshooting DNSSEC in NIOS


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 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






Grid Manager UI



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

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.

Screenshot 2024-05-06 at 3.16.57 PM.png


Task 1: First Ticket

  • User reports unable to resolve the name Please investigate root cause.

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

      dig @ A

    2. Why did it fail?

      For your convenience a packet captures are provided (3612-task1-ada.pcap and 3612-task1-bob.pcap)


Task 1 solution: First Ticket

  • Root Cause:

    ADA ( forwards to BOB (, which has EDNS0 disabled.

  • Detailed Analysis:

    In the packet capture 3612-task1-ada.pcap we see ADA ( sends the query for to BOB (, 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, 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: is insecure (not signed): we expect to receive NXDOMAIN response along with either NSEC or NSEC3 records 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 (, who accepts DO bit, but is has not returned the correct DNSSEC data.

    We can also perform dig directly against BOB ( 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 (, except this one was performed on BOB ( 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 (, that EDNS0 is disabled.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.