2602 - Signing an authoritative zone with DNSSEC in NIOS
Scenario
You are a DNS administrator for a coffee company. The main zone, coffee.corp, is maintained by a team based in the headquarter, on the server NS1 (10.100.0.111). The zone kona.coffee.corp, is maintained by your team, on the server NS2 (10.100.0.222), in the branch office in Kona, Hawaii. The zone kona.coffee.corp is delegated from NS1 to NS2.
You are tasked with enabling authoritative DNSSEC for this domain, also known as zone signing. The goal is to sign the zone kona.coffee.corp so all users resolving this domain through the validating resolver ADA (10.100.0.100) can enjoy the benefits of DNSSEC.
To help you visualize the setup, please refer to the diagram below.
Estimate Completion Time
45 to 60 Minutes
Credentials
Description | Username | Password | URL or IP |
|---|---|---|---|
Grid Manager UI | admin | infoblox |
Requirements
2204: Explaining 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: Signing the zone kona.coffee.corp
Task 2: Adding the missing pieces
Task 1: Signing the zone kona.coffee.corp
We start by deploying DNSSEC to the zone kona.coffee.corp. We do this by signing the authoritative zone on NS2 (10.100.0.222):
Log in to NS2 (10.100.0.222) web interface, sign the zone kona.coffee.corp.
On the Jump-Desktop (10.35.22.10), query the recursive name server ADA (10.100.0.100) for the A record sweet.kona.coffee.corp.
Does the name resolve? Does it have the AD (Authenticate Data) flag? Why or why not?
Query the parent name server NS1 (10.100.0.111) directly and see if it has all of the records we expect. There is a traffic capture file 2602-task1-ada.pcap on the desktop. It was taken earlier on the server ADA (10.100.0.100) while the client initiated the query.
Task 2: Adding the missing pieces
After performing the first task, you realized that there are some missing actions. Since DNSSEC is a new deployment at your organization, you need to not only perform the step on your own name server NS2 (10.100.0.222), but also help the team at the headquarter to perform their tasks on the server NS1 (10.100.0.111). After both of these missing pieces have been put in place, the zone kona.coffee.corp should become fully validated.
Login to NS2 (10.100.0.222) and export trust anchor for kona.coffee.corp. This is the task that your team (delegated child zone) needs to perform.
Login to NS1 (10.100.0.111) and import trust anchor for kona.coffee.corp. This is the task that the headquarter team (parent zone) needs to perform.
Test DNS resolution again for the A record sweet.kona.coffee.corp. Does the AD flag appear now? Why or why not? If not, what steps can be taken to make it appear?
This task simulates when a child zone operator has signed the zone, but failed to upload the DS records to the parent zone. In the first step, we play the part of the child zone operator who signed the zone; in the second step, we play the role of the parent zone operator who has to install the DS records.
Solutions
Task 1 solution: Signing the zone kona.coffee.corp
Deploy DNSSEC to the authoritative zone kona.coffee.corp, by signing the zone on NS2 (10.100.0.222)
Log in to NS2 (10.100.0.222) web interface using the credentials (admin/infoblox), sign the zone kona.coffee.corp
Navigate to Data Management → DNS → Zones, click on kona.coffee.corp.
Navigate to the Toolbar, click the drop down menu DNSSEC, select Sign Zones as shown in the following figure. Restart services when prompted.
On the Jump-Desktop (10.35.22.10), query the recursive name server ADA (10.100.0.100) for the A record sweet.kona.coffee.corp.
Does the name resolve? YES Does it have the AD (Authenticate Data) flag? NO
Root Cause: The child zone kona.coffee.corp did not export and upload DS record to parent zone coffee.corp, thus the domain is still treated as insecure. Export DS record from NS2, and import into NS1 to fix.
Detailed Analysis: First of all, there is no need to read the packet capture, everything can be figured out from performing DNS queries against different name servers.
When we query ADA (10.100.0.100), there is no error, we see a response like in the figure below.
There is no error, but we also do not see the AD flag. This indicates this domain name is insecure (not signed).Since the domain is not signed, the next logical step is to see if there is a DS record for kona.coffee.corp. The query and response are shown in the following figure.
Notice this is not a NXDOMAIN return code. A normal insecure response would have return NXDOMAIN.
We retry this query again, this time with the +dnssec switch. the next figure shows the query and response.
This more complete response shows that the parent domain coffee.corp name server responded, indicating there is no DS record for the domain kona.coffee.corp (NSEC3 is one of the two ways DNSSEC says NXDOMAIN). That is our root cause: because there is no DS record on the parent, the zone kona.coffee.corp is still being treated as insecure, as if the domain was not signed at all.
If you chose to read the packet capture file 2602-task1-ada.pcap, packet #230 shows ADA querying for the DS record of kona.coffee.corp, and packet #231
shows NS1 responding to ADA with NSEC3, indicating the DS record does not exist, and kona.coffee.corp is insecure. The following figure shows the highlights of thepackets in the packet capture file.
Task 2 solution: Adding the missing pieces
After the first task of signing the authoritative zone, you realized that you did not complete the entire setup because the DS record is missing on the parent zone (coffee.corp). To finish the setup, you need to export the DS record or the trust anchor from the delegated child zone (kona.coffee.corp), send the file to the team maintaining the parent zone (coffee.corp), and help them import the information into their name server NS1 (10.100.0.111).
Export the trust anchor from the delegated child zone.
Login to NS2, navigate to Data Management → DNS → Zones, click on kona.coffee.corp. In the Toolbar, select DNSSEC → Export Trust Anchors
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.
Import the exported trust anchor into the parent zone.
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, where there are previously none.
Test DNS resolution again for the A record sweet.kona.coffee.corp. Does the AD flag appear now? Why or why not? If not, what steps can be taken to make it appear?
Root Cause: It is possible to get cached insecure response, clear cache on ADA (10.100.0.100).
Detailed Analysis: Depending on when you last performed a DNS lookup for the name sweet.kona.coffee.corp on the validating resolver ADA (10.100.0.100), there might be a cached entry. In other words, the insecure response may still be in the cache. The screenshot below show an example of the cached insecure response. Notice that there is no AD flag (thus the response is insecure), and the TTL for this entry has 79 more seconds before it expires.
To clear cache, login to ADA (10.100.0.100), navigate to Data Management → DNS → Members, select the member ada.example.local, navigate to Toolbar → Clear → Clear DNS Cache, as shown here.
Execute the DNS query again, this time, we can expect the validated response from ADA (10.100.0.100), note the AD flag.
