3616 - Troubleshooting DNSSEC in NIOS

Scenario

You have started as a new 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 kona.coffee.corp on server NS2 (10.100.0.222). Users have reported some behaviors that leads them to suspect the delegation is not configured correctly. Please use your DNS knowledge to troubleshoot, locate the root cause(s), and make suggestions to the users.

Estimate Completion Time

• 45 to 60 Minutes
  

Credentials

Course References

• 2009: Configuring NIOS DNS Services

• 2023: Configuring NIOS DNS Zones

• 3011: DNS Troubleshooting Methodology

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: First Ticket

User reports that he is unable to resolve a domain name, with a screenshot attached. Please investigate the root cause.

Look at the spelling

Task 2: Second Ticket

User is still unable to resolve "sweet.kona.coffee.corp", and provided screenshot, investigate the root cause.

Task 3: Verify Delegated Resolution

You have learned that there is a third DNS server dedicated to perform recursive lookups. The server is ADA (10.100.0.100). Please use this server to resolve the delegated name and observe its behavior. On the jump-Desktop Command line, execute the following command:

dig @10.100.0.100 sweet.kona.coffee.corp. A

What IPv4 address does the name resolve to?

Task 4: Analyze and Recommend

Please analyze the settings and configurations on all 3 DNS servers: ADA (10.100.0.100), NS1 (10.100.0.111), and NS2 (10.100.0.222). Should the user who reported the issue continue to use NS1 (10.100.0.111) to resolve delegated names such as sweet.kona.coffee.corp? Why or why not?

It is useful to draw a diagram as you analyze each DNS server configuration, to visualize how each server is related.

Solutions

Task 1 solution: First Ticket

Root Cause

Misspelled domain name sweet.kona.coffee.crop., should be corp.

Detailed Analysis

The root cause is the name was misspelled.
The name server NS1 (10.100.0.111) is not authoritative for the coffee.crop domain name, and must resolve it using recursion. Since recursion is not enabled on the server NS1 (10.100.0.111), we receive the REFUSED response code. The clue can be seen in a line below the header section that reads:

WARNING: recursion requested but not available

Task 2 solution: Second Ticket

Root Cause

Client should not be using authoritative server to resolve delegated domain name. Point to 10.100.0.100 instead.

Detailed Analysis

The response is known as a REFERRAL in DNS, although it is not its own type of return code. This is normal behavior from authoritative name server, in response to a query that asks for a name that has been delegated. The authoritative name server NS1 (10.100.0.111) sends back the response that contains the NS record and the glue record, informing the client to query NS2 (10.100.0.222). At this point the client (desktop) is expected to perform a follow-up iterative query to NS2 (10.100.0.222), to "chase down the answer".

The proper solution is to introduce a recursive name server for the client to use, to perform all of the iterative queries to chase down the answer on behalf of the client.

While it is possible to simply enable recursion on the authoritative server NS1 (10.100.0.111), it is not the best practice. If possible, separate the roles of your DNS servers, so that authoritative servers only serve authoritative data, and another server is dedicated to performing recursive lookups. This is especially important if you wish to use DNSSEC, which requires this role separation.

Task 3 solution: Verify Delegated Resolution

Root Cause

No errors in this task, we are continuing our investigation from the previous one.

Detailed Analysis

Using the recursive server ADA (10.100.0.100) you are able to resolve the name sweet.kona.coffee.corp, it resolves to the IPv4 addrress 10.3.3.3.

Task 4 solution: Analyze and Recommend

Root Cause

The root cause for our users encountering DNS resolutions is because they are querying the authoritative server NS1 (10.100.0.111) who is not providing recursion. Users should query recursive resolver or recursive servers instead.

Detailed Analysis

After analyze the configurations on each DNS server, you should have a diagram like the one below showing how they related to one another. In this environment, both NS1 and NS2 are authoritative only, no recursion is available. This is considered best practice, to separate DNS server roles (authoritative and recursive). The server ADA is providing the recursive service. It is acting like a traffic cop, sending queries ending in coffee.corp to NS1, and the rest of the queries to the Internet. The behavior we observed in Task 2 is what happens when clients query authoritative servers directly: the DNS server sends back a REFERRAL, but clients are unable to follow the REFERRAL.