3608 - Unsigning a DNSSEC zone 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).
A decision is made to un-sign kona.coffee.corp a zone managed by your team, you're tasked to implement this task while maintaining resolution for this zone.
Estimate Completion Time
30 to 45 minutes
Credentials
Description | Username | Password | URL or IP |
|---|---|---|---|
Grid Manager UI | admin | infoblox |
Course References
1204: DNSSEC Fundamentals
3011: DNS Troubleshooting Methodology
2204: Describing DNSSEC
2026: Configuring Authoritative DNSSEC in NIOS
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
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: Un-sign kona.coffee.corp
In this task we simulate us backing out of DNSSEC deployment for the zone kona.coffee.corp.
Login to NS2 (10.100.0.222):
navigate to Data Managment → DNS → Zones
select kona.coffee.corp.
on the Toolbar, click DNSSEC → Unsign Zones
Restart Services when prompted.
Execute the following command on Jump-Desktop (10.35.22.10) and note down the results:
dig @10.100.0.100 sweet.kona.coffee.corp. AIf the answer was cached, either wait for the cache to expire or manually clear the cache on the validating resolver ADA (10.100.0.100), by navigating to Data Managment → DNS → Members, On the Toolbar click on Clear → Clear DNS Cache.
What response code did we receive? why?
Login to NS1 (10.100.0.111):
navigate to Data Managment → DNS → Zones
select kona.coffee.corp.
delete all DS records for kona.coffee.corp
Execute the same dig command again:
dig @10.100.0.100 sweet.kona.coffee.corp. AWhat is the response after cache has expired or manually clearing the cache?
Solutions
Task 1 solution: Un-sign kona.coffee.corp
Solution:
After unsigning the child zone, if the DS records still remain on the parent zone, it results in validating resolver streating the zone as bogus until the DS records are removed.Detailed Analysis:
After logging into NS2 and unsign the authoritative zone kona.coffee.corp, and waiting sufficient time (199seconds) for cached answers to expire, we use dig to look up sweet.kona.coffee.corp, and the response is shown below:
This is due to the fact that the DS records on NS1 have not yet been removed, and validating resolver assumes the zone kona.coffee.corp is still signed, and failed validation. The following figure shows the log messages generated by the dig command, as seen on the validating resolver ADA (10.100.0.100).
Login to NS1 (10.100.0.111), navigate to Data Management → DNS → Zones, select the authoritative zone coffee.corp, delete all DS records for kona.coffee.corp, as shown below:
Wait for the DS records to expire from ADA's cache (199 seconds), and the query for sweet.kona.coffee.corp should work as an insecure resolution with no AD flag present, as shown below:
