Skip to main content
Skip table of contents

3613 - Troubleshooting Authoritative DNSSEC in NIOS


You are a DNS administrator at a coffee company. The internal name space includes an authoritative zone coffee.corp on the server NS1 ( and a delegated zone zone on server NS2 (

Some of your organization’s employees are reporting there inability to access the domain, you know that one of your colleagues have done some DNSSEC changes and you suspect that this might be the issue.

Estimate Completion Time

  • 30 to 45 minutes






Grid Manager UI



Course References

  • 3021: Troubleshooting DNSSEC


  • Administrative access to the Grid

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: Confirm the cause of the problem

  • Task 2: Trace the root cause of the problem

  • Task 3: Apply a solution

  • Task 4: Verify the problem is now resolved

Task 1: Confirm the cause of the problem

  • Use the terminal window on your Jump-Desktop with the credentials (training/infoblox) to confirm that is inaccessible.

  • Test if DNSSEC is involved with the reported problem.

Task2: Trace the root cause of the problem

  • Trace down the root cause of the problem

Task3: Apply a solution

  • Log into NS1 ( the parent server for coffee.corp and NS2 ( the child server for and implement a solution for the problem you discovered.

Task 4: Verify the problem is now resolved

  • Use the terminal window on your Jump-Desktop to confirm that your solution works and is now accessible.


Task 1 solution: Confirm the cause of the problem

  1. login to Jump-Desktop using the credentials (training/infoblox)

  2. Use the terminal window to dig the domain, you can dig using one if the following commands: dig @ A or dig @ A

  3. Now we need to either eliminate or confirm that DNSSEC is a factor, we can do that by using the +cd flag if we get a hot then we know that DNSSEC is the reason and if not then we know its a core DNS issue.

    We now know for sure that DNSSEC is the problem, and our next logical step is to start troubleshoot what exactly went wrong during the last update.

Task2 solution: Trace the root cause of the problem

  1. Our first step should be us verifying that is signed.

    1. we can do that using NS2 ( web UI, navigate to Data Managment → DNS → Zones, select the zone should have the DNSSEC shield icon and DNSSEC records records present.

    2. Or we can use dig with the +dnssec flag to see if the record is signed.

  2. Now we know the zone is signed, our next step should be to trace the chain of trust to see exactly where it broke.

    1. From our previous dig output we can see the ZSK ID used to sign the A record for

    2. We can use the command dig @ DNSKEY +cd +dnssec +multi +nocrypto to track down the ZSK with the ID of 50709.

      from the command output we can track the ZSK with the ID 50709 which we know signed our A record, we can also track down the KSK which signed the RRSIG record for this ZSK, it is the KSK with the ID 53172.
      A very important note to keep here is that the KSK is using a different algirthm SHA512(10)

    3. The next step now should be to trace the KSK to the parent zone coffee.corp, the key should be exported out to the parent zone for the chain to be complete. we can use the command dig @ DS +cd +dnssec +nocrypto +multi.

      the output helps us identify the problem, the key that was exported to the parent zone doesn’t match the KSK the child zone is using, this means that during the last key rollover which happened due to change of algorithm, someone forgot to export new key into the parent zone leading to the chain of trust breaking and validation to fail.

Task3 solution: Apply a solution

  • The solution in this case, is to export the new DS records from the child zone and import them into the parent zone coffee.corp

    1. Login to NS2(, navigate to Data Management → DNS → Zones, click on In the Toolbar, select DNSSEC → Export Trust Anchor

    2. Export Trust Anchors dialog appears, select DS records and the zone click Export.

    3. Save the exported trust anchor to local file. It doesn't matter what you save the file name as. For our example, the file name is ds_records.txt.

    4. Open the file in editor and leave the editor open. We will need this information for the next step.

    5. Login to NS1 (, navigate to Data Management → DNS → Zones, click on coffee.corp. In the Toolbar, select DNSSEC → Import Keyset

    6. The Import Keyset dialog appears. Copy and paste the DS record text from text editor (ds_records.txt in our example) and click Import

    7. There are now four DS records in the zone coffee.corp, where there are previously two. the two old DS records we can identify them by the number 8 for the SHA256 and he two new keys identifiable by the number 10 for SHA512

Task 4 solution: Verify the problem is now resolved

  1. Use the terminal window to dig the domain again, this time it should work, the domain should be accessible and validated.

JavaScript errors detected

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

If this problem persists, please contact our support.