2601 - Tracing DNSSEC Chain of Trust
Scenario
Your organization has recently adopted DNSSEC to align with the latest recommendations for DNS security. You decided to refresh your DNSSEC knowledge and trace the chain of trust for www.example.com using various methods to be ready when you need to troubleshoot DNSSEC.
Estimate Completion Time
35 to 50 minutes
Credentials
Description | Username | Password | URL or IP |
|---|---|---|---|
Grid Manager UI | admin | infoblox |
Requirements
1204: DNSSEC Fundamentals
2204: Learning about DNSSEC
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: Study Traffic Capture of Validation Steps
A packet capture 2601-task1-ada.pcap was taken previously; your task is to study the pre-captured traffic to show the complete validation steps performed by a validating resolver. In the capture file, the validating resolver has the IP address 10.100.0.100, and the client who initiated the query has the IP address 10.35.22.10.
Study the details between packets #211 and #212. #211 is sent from the client to the validating resolver #212 is validating forwarding the query. What is different between these two packets?
look in the additional section for OPT
Which key ID signed the www.example.com A record? Which packet shows this information?
Task 2: Manually Trace the Chain of Trust
Using your dig techniques and the details from studying the packet capture, fill in the commands in the table below needed to manually trace the chain of trust for the domain name www.example.org.
Use the local DNS Server 10.100.0.105 as your resolver.
Step Number | dig command | Responses |
|---|---|---|
1 and 2 | dig @10.100.0.105 www.example.org. A +dnssec +multi +nocrypto | Receives A record & RRSIG of www.example.org |
3 and 4 | Receives DNSKY and RRSIG of DNSKEY, for example.org | |
5 and 6 | Receives DS and RRSIG of DS, for example.org | |
7 and 8 | Receives DNSKEY and RRSIG of DNSKEY for org | |
9 and 10 | Receives DS and RRSIG of DS for org | |
11 and 12 | Receives DNSKEY and RRSIG of DNSKEY for root |
Task 3: Visual Analysis
Use DNSSEC Analyzer (https://dnssec-analyzer.verisignlabs.com/) to trace the chain of trust for www.example.com
Use DNSViz (http://www.dnsviz.net) to perform the same analysis.
Solutions
Task 1 Solution: Study Traffic Capture of Validation Steps
Answers
The difference between packet#211 and packet#212 is the DO (DNSSEC OK) bit. In packet#211, it is set to 0; in packet#212, it is set to 1.
The key tag ID is 56575.
Detailed Analysis
By studying the details between packets #211 and #212, we know that packet #211 is from the client to the validating resolver and does not contain the DO(DNSSEC OK) bit.
This is normal client behaviour since the client does not know how to handle all the extra DNSSEC record types.
Packet #212 is from the validating resolver ADA (10.100.0.100) to the forwarding name server 10.100.0.198 and has the DO (DNSSEC OK) bit present.
The following figure shows a screenshot from Wireshark on packet #212.
In packet #213, RRSIG shows the key tag 56575. This is the key ID of the ZSK that signed this A record.
The following figure shows the packet in Wireshark.
Task 2 Solution: Manually Trace the Chain of Trust
The necessary dig commands are provided in the table below.
Step Number | dig command | Responses |
|---|---|---|
1 and 2 | dig @10.100.0.105 www.example.org. A +dnssec +multi +nocrypto | Receives A record & RRSIG of www.example.org |
3 and 4 | dig @10.100.0.105 example.org. DNSKEY +dnssec +multi +nocrypto | Receives DNSKY and RRSIG of DNSKEY for example |
5 and 6 | dig @10.100.0.105 example.org. DS +dnssec +multi +nocrypto | Receives DS and RRSIG of DS for example.org |
7 and 8 | dig @10.100.0.105 org. DNSKEY +dnssec +multi +nocrypto | Receives DNSKEY and RRSIG of DNSKEY for org |
9 and 10 | dig @10.100.0.105 org. DS +dnssec +multi +nocrypto | Receives DS and RRSIG of DS for org |
11 and 12 | dig @10.100.0.105 . DNSKEY +dnssec +multi +nocrypto | Receives DNSKEY and RRSIG of DNSKEY for root |
Below are sample results of executing each command and highlighting the key ID that makes up the chain of trust.
The following figure shows step 1; the RRSIG is signed by the ZSK 37219.
The following figure shows step 3; we spot the ZSK 37219, signed by KSK 22273
The following figure shows step 5: We receive the DS record for example.org. The KSK ID 22273 is present. The DS record has an RRSIG signed by ZSK 55149.
Seeing multiple DNSKEY and DS records is normal, most likely due to key rollover, a topic discussed in a different course.
The following figure shows step 7; we spot the org ZSK 55149 with 1 RRSIG, signed by ZSK 3093 and 55149.
The following figure shows step 9. We see the DS record for 26974 and the RRSIG record signed by 5613.
The following figure shows step 11. We see the root ZSK 5613; it has one RRSIG signed by root KSK 20326.
Task 3 Solution: Visual Analysis
The following figure shows the DNSSEC Analyzer result of www.example.org
The following figure shows the DNSViz output of www.example.org
