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 |
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.
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: 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
login to Jump-Desktop using the credentials (training/infoblox)
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
ordig @10.100.0.100 sweet.kona.coffee.corp. A
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
Our first step should be us verifying that kona.coffee.corp is signed.
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.
Or we can use dig with the
+dnssec
flag to see if the record is signed.
Now we know the zone is signed, our next step should be to trace the chain of trust to see exactly where it broke.
From our previous dig output we can see the ZSK ID used to sign the A record for sweet.kona.coffee.corp.
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)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
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
Export Trust Anchors dialog appears, select DS records and the zone kona.coffee.corp click Export.
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.
Open the file in editor and leave the editor open. We will need this information for the next step.
Login to NS1 (10.100.0.111), navigate to Data Management → DNS → Zones, click on coffee.corp. In the Toolbar, select DNSSEC → Import Keyset.
The Import Keyset dialog appears. Copy and paste the DS record text from text editor (ds_records.txt in our example) and click Import.
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
Use the terminal window to dig the domain kona.coffee.corp again, this time it should work, the domain should be accessible and validated.