3607 - Performing DNSSEC KSK rollover 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 change algorithm from RSA/SHA256 to RSA/SHA512. You're tasked with this update, please perform the configuration changes, and ensure necessary data has been uploaded to parent zone.

Estimate Completion Time

65 to 80 minutes

Credentials

Description	Username	Password	URL or IP
Grid Manager UI	admin	infoblox	https://10.100.0.100/

Course References

1204: DNSSEC Fundamentals
3011: DNS Troubleshooting Methodology
2204: Describing DNSSEC
2026: Configuring Recursive DNSSEC in NIOS
3028: Managing DNSSEC Keys 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.

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: KSK Rollover on NS2

We want to perform a KSK rollover on NS2. This task walks us through the steps.
1. Before performing the steps, execute the following command on the Jump-Desktop (10.35.22.10) and note down the results.
  dig @10.100.0.100 kona.coffee.corp. DNSKEY +multi +nocrypto
2. On NS2 (10.100.0.222):
  1. navigate to Data Management → DNS, on the Toolbar Grid DNS Properties → DNSSEC (toggle Advanced Mode if needed)
  2. Change Key-Signing Key (KSK) from RSA/SHA-256 to RSA/SHA-512.
  3. Click Save & Close
  4. Read the warning message then click Yes
    
    This message informs us that new algorithm will only take effect after key rollover. In a live environment, it is safe to proceed, knowing that the impact on existing signed zones will be at the next key rollover event. In the lab, we speed up this process immediately and manually (described below). This speed-up is not advised for production environment.
  5. navigate to Data Managment → DNS → Zones
  6. select kona.coffee.corp.
  7. on the Toolbar, click DNSSEC → Rollover Key-Signing Key
  8. Restart Services when prompted.

Task 2: Upload the DS record on the parent zone

Performing a key rollover requires uploading new DS records to the parent zone. We will perform that in this task.
1. Export the trust anchor from the delegated child zone.
  1. Login to NS2, navigate to Data Management → DNS → Zones, click on kona.coffee.corp. In the Toolbar, select DNSSEC → Export Trust Anchors
  2. Export Trust Anchors dialog appears, select DS records and 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 (10.100.0.111), 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.

Task 3: Analyzing the changes

Can you remove the old DNSKEY from NS2?
What DNSKEY records are cached on ADA (10.100.100)?
Will validation break durig this rollover? why or why not?

Solutions

Brief Description:

Key rollover is safer than Apply Algorithm Change, in that it keeps the old key so no signatures are orphaned.
The actions performed in this lab do not break validation, and NIOS has safety mechanisms in place to protect DNSKEY from being deleted.

Detailed Analysis:

By following the steps described in detail in task 2 to export the new DS record from kona.coffee.corp. on NS2 (10.100.0.222) and import it into coffee.corp. on NS1 (10.100.0.111).

Before performing the key rollover, we take an inventory of the current DNSKEY in the zone kona.coffee.corp by issuing the dig command in the following figure:

On NS2, navigate to Data Managment → DNS → Zones, click the zone kona.coffee.corp in the Toolbar select DNSSEC → Rollover Key-Signing Key, as shown below:

Execute the following dig command, note there is a new KSK as the result of performing the rollover, the following figure shows the new KSK with the new key tag of 51531

dig @10.100.0.222 kona.coffee.corp. DNSKEY +multi +nocrypto

We can query the validating resolver to see the DNSKEY entries cached. We see the previous 3 keys and the new KSK 51531 is not present in the following figure:

We can manually flush the DNS 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.
Then rerun the query and we will see the new KSK 51531 appear in its cache, as shown in the following figure:

NIOS does not allow manual deletion of DNSKEY, so the old keys will be around for at least another 48 hours, before being removed automatically. This is a safety mechanism. With a key rollover, both the old and new keys are published for a period of time, and the old key is removed automatically at a later date when it is safe. The point of this lab is to show that when changing keys, rollover is the safer route to do so, and it cannot be done in a hurry without breaking validation.