Skip to main content
Skip table of contents

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

https://10.100.0.100/

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

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

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.

    1. Execute the following command on the Jump-Desktop (10.35.22.10):

      dig @10.100.0.100 broken.training.infoblox.com. A

    2. On the Grid Master IBNS1 (10.100.0.100), navigate to Administration → Logs → syslog

      1. What log messages were generated from resolving this domain name?

      2. Look into the capture file, was there any packet that show what the problem is?

    3. 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

    1. 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.

    2. Click + to add a new entry for bogus.training.infoblox.com under the Negative Trust Anchor section, as shown below:

    3. 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

    1. 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.

      image-20240314-083332.png
  • 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.

    image-20240314-083300.png


JavaScript errors detected

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

If this problem persists, please contact our support.