Skip to main content
Skip table of contents

3613 - Troubleshooting Authoritative DNSSEC in NIOS


Scenario

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

Some of your organization’s employees are reporting there inability to access the kona.coffee.corp 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

Credentials

Description

Username

Password

URL or IP

Grid Manager UI

admin

infoblox

https://10.100.0.100/

Course References

  • 3021: Troubleshooting DNSSEC

Prerequisites

  • 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

Tasks

  • 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


Note: The ZSK and KSK ID values referenced in this lab guide are provided as examples for reference purposes. Please verify the actual ZSK and KSK IDs in your lab environment to ensure accuracy during troubleshooting and configuration steps.

Task 1: Confirm the cause of the problem

  • Use the terminal window on your Jump-Desktop with the credentials (training/infoblox) to confirm that kona.coffee.corp 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 (10.100.0.111) the parent server for coffee.corp and NS2 (10.100.0.222) the child server for kona.coffee.corp 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 kona.coffee.corp is now accessible.


Solutions

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 kona.coffee.corp, you can dig using one if the following commands: dig @10.100.0.100 kona.coffee.corp. A or dig @10.100.0.100 sweet.kona.coffee.corp. 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 kona.coffee.corp is signed.

    1. we can do that using NS2 (10.100.0.222) web UI, navigate to Data Managment → DNS → Zones, select kona.coffee.corp 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 sweet.kona.coffee.corp.

    2. We can use the command dig @10.100.0.100 kona.coffee.corp 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 @10.100.0.100 kona.coffee.corp 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 kona.coffee.corp and import them into the parent zone coffee.corp

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

    2. Export Trust Anchors dialog appears, select DS records and the zone kona.coffee.corp 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 (10.100.0.111), 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 DS records in the zone coffee.corp that use two different algorithms. The previous keys using SHA-256, indicated by the number 8, and the new keys using SHA-512, indicated by the number 10.

Task 4 solution: Verify the problem is now resolved

  1. Use the terminal window to dig the domain kona.coffee.corp 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.