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.

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

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 or dig @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.
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.
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 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

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