3605 - Configuring Negative Trust Anchor (NTA) in NIOS
Scenario
You are a DNS administrator for a company, part of your responsibilities is to resolve user submitted tickets.
Users have reported their inability to resolve a new domain used by your organization broken.training.infoblox.com, a packet capture was provided to you by a colleague, please use the packet capture and syslog to find the issue and fix it.
Estimate Completion Time
45 to 60 minutes
Credentials
Description | Username | Password | URL or IP |
|---|---|---|---|
Grid Manager UI | admin | infoblox |
Course References
1204: DNSSEC Fundamentals
3011: DNS Troubleshooting Methodology
2204: Explaining DNSSEC
2025: Configuring Recursive 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: Analyze the traffic capture
In this task we will use a previously taken packet capture file 3605-task1-ada.pcap and some syslog messages to determine what the issue is.
Execute the following command on the Jump-Desktop (10.35.22.10):
dig @10.100.0.100 broken.training.infoblox.com. AOn the Grid Master IBNS1 (10.100.0.100), navigate to Administration → Logs → syslog
What log messages were generated from resolving this domain name?
Look into the capture file, was there any packet that show what the problem is?
What can you do to fix the issue?
Task2: Adding NTA
This lab simulates when a domain outside of our control is misconfigured, resulting in a bogus response. After contacting the domain's operator, we determined it will be more beneficial to our network users if we allow-list the domain on our end.
Install NTA (Negative Trust Anchor) to change resolution behavior for broken.training.infoblox.com
Login to IBGM (10.100.0.100), navigate to Data Management → DNS, Toolbar → Grid DNS Properties → DNSSEC, scroll down to the Negative Trust Anchor section.
Click + to add a new entry for bogus.training.infoblox.com under the Negative Trust Anchor section, as shown below:
Save and restart services, then retest the domain name resolution using the following command:
dig @10.100.0.100 broken.training.infoblox.com. A
Solutions
Task 1 solution: Analyze the traffic capture
Root cause
The output of the command does show a SERVFAIL response code and this is because the domain name is bogus as reported due to DS record and DNSKEY mismatch, syslog shows it more clearly than packet capture.
Detailed Analysis
Keep in mind that bogus domains are really signed domains that has an error that caused validation. Thus, it usually has all of the same information as a secure domain, just the information doesn't match up.
In that case,reading the packet capture is a difficult way to determine that the validation failed, requiring us to read each packet detail, noting down the key ID, and tracing it manually.
In the provided packet capture file lab4-task6-ada.pcap, we need to look at the RRSIG in packet #325 to find the ZSK key tag, then check packet #327 to find corresponding KSK key tags in the DNSKEY RRSIG, and again in packet # 329 look for the key tag in the DS record response.
There is no clear missing packet that tells us what the problem is, and that's the point of this task: it's hard to determine that the domain name is bogus from reading packet captures, the better and easier way is to look at syslog.
As shown below, syslog shows all of the validation checks that failed while resolving this name.
Task2 solution: Adding NTA
Solution
The solution for this is to add an NTA (Negative Trust Anchor) to our resolver since this domain is outside of our control.
The NTA creates an allow list and turns bogus responses into insecure responses.
Detailed Analysis
After adding a Negative Trust Anchor on the validating resolver IBNS1 (10.100.0.105), the same lookup now returns an insecure response as shown below missing the AD flag.
