Skip to main content
Skip table of contents

2602 - Signing an authoritative zone with DNSSEC in NIOS


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 ( The zone, is maintained by your team, on the server NS2 (, in the branch office in Kona, Hawaii. The zone 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 so all users resolving this domain through the validating resolver ADA ( 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






Grid Manager UI




  • 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

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


  • Task 1: Signing the zone

  • Task 2: Adding the missing pieces

Task 1: Signing the zone

We start by deploying DNSSEC to the zone We do this by signing the authoritative zone on NS2 (

  1. Log in to NS2 ( web interface, sign the zone

  2. On the Jump-Desktop (, query the recursive name server ADA ( for the A record

  3. Does the name resolve? Does it have the AD (Authenticate Data) flag? Why or why not?

    Query the parent name server NS1 ( 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 ( 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 (, but also help the team at the headquarter to perform their tasks on the server NS1 ( After both of these missing pieces have been put in place, the zone should become fully validated.

  1. Login to NS2 ( and export trust anchor for This is the task that your team (delegated child zone) needs to perform.

  2. Login to NS1 ( and import trust anchor for This is the task that the headquarter team (parent zone) needs to perform.

  3. Test DNS resolution again for the A record 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.


Task 1 solution: Signing the zone

Deploy DNSSEC to the authoritative zone, by signing the zone on NS2 (

  1. Log in to NS2 ( web interface using the credentials (admin/infoblox), sign the zone

    1. Navigate to Data Management → DNS → Zones, click on

    2. Navigate to the Toolbar, click the drop down menu DNSSEC, select Sign Zones as shown in the following figure. Restart services when prompted.

  2. On the Jump-Desktop (, query the recursive name server ADA ( for the A record

  3. Does the name resolve? YES Does it have the AD (Authenticate Data) flag? NO
    Root Cause: The child zone 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 (, 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 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 (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 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, and packet #231
    shows NS1 responding to ADA with NSEC3, indicating the DS record does not exist, and 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 (, send the file to the team maintaining the parent zone (coffee.corp), and help them import the information into their name server NS1 (

  1. Export the trust anchor from the delegated child zone.

    1. Login to NS2, navigate to Data Management → DNS → Zones, click on In the Toolbar, select DNSSEC → Export Trust Anchors

    2. Export Trust Anchors dialog appears, select DS records and the zone 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.

  2. Import the exported trust anchor into the parent zone. 

    1. Login to NS1 (, navigate to Data Management → DNS → Zones, click on coffee.corp. In the Toolbar, select DNSSEC → Import Keyset

    2. The Import Keyset dialog appears. Copy and paste the DS record text from text editor (ds_records.txt in our example) and click Import

    3. There are now DS records in the zone coffee.corp, where there are previously none.

  3. Test DNS resolution again for the A record 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 (
    Detailed Analysis: Depending on when you last performed a DNS lookup for the name on the validating resolver ADA (, 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 (, 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 (, note the AD flag.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.