3515 - Troubleshooting reverse DNS resolution in NIOS

Scenario

The A record www.techblue.net is created, it points to the IPv4 address 10.65.29.10. The forward-mapping lookup resolves; however, the reverse-mapping does not work. Please study the output of the following dig commands in the lab and troubleshoot the issue on the Grid.

Estimate Completion Time

15 to 20 minutes

Credentials

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

Requirements

Administrative access to the Grid

Course References

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: Verifying forward-mapping DNS Lookup

Verify that the newly added record www.techblue.net can be resolved by querying members on the Grid. You may query ibns1 (10.100.0.105) or ibns2 (10.200.0.105).

Task 2: Troubleshooting reverse DNS lookup

Investigate reverse resolution issue with the help of dig tool and resolve the issue after finding root cause.

Solutions

Task 1 Solution: Verifying forward-mapping DNS Lookup

The out put from dig tells us that our name server (10.100.0.105) is indeed authoritative for the forward-mapping zone:

CODE

$ dig @10.100.0.105 www.techblue.net. 

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> @10.100.0.105 www.techblue.net.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28439
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: b9956f3221b78381d89294dd64c42921797150381bce3e64 (good)
;; QUESTION SECTION:
;www.techblue.net.		IN	A

;; ANSWER SECTION:
www.techblue.net.	28800	IN	A	10.65.29.10

;; Query time: 0 msec
;; SERVER: 10.100.0.105#53(10.100.0.105) (UDP)
;; WHEN: Fri Jul 28 20:46:25 UTC 2023
;; MSG SIZE  rcvd: 89

Detailed Analysis

Line 1: We query the name server 10.100.0.105 directly.
Line 7: The status code NOERROR indicates that the server 10.100.0.105 was able to resolve this name.
Line 8: We see both the aa and ra flags. This means while the server itself supports recursion, it did not use recursion to resolve this name. It was able to provide the authoritative answer directly, thus the aa flag. In other words, this is the name server telling us: "I did not need to ask anyone else about this name, because I am the authoritative server for that name.”
Line 17: This response in the ANSWER section confirms that this name points to the IP address 10.65.29.10.

With all of this information at hand, have verified that the forward-mapping for this name is configured correctly: the name www.techblue.net points to the IP address 10.65.29.10, and this data is authoritative on the server ibns1 (10.100.0.105).

Next, we need to check the reverse-mapping, to see if the IP address 10.65.29.10 points to the name www.techblue.net.

Task 2 Solution: Troubleshooting reverse DNS lookup

The out put from dig tells us that our name server (10.100.0.105) is not authoritative for the reverse-mapping zone:

CODE

$ dig @10.100.0.105 -x 10.65.29.10

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @10.100.0.105 -x 10.65.29.10
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44728
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: 4a20bc2aee506ce52b08ddbc6684eb57cc88e40ba510a74b (good)
;; QUESTION SECTION:
;10.29.65.10.in-addr.arpa.	IN	PTR

;; AUTHORITY SECTION:
10.in-addr.arpa.	10795	IN	SOA	prisoner.iana.org. hostmaster.root-servers.org. 1 604800 60 604800 604800

;; Query time: 4 msec
;; SERVER: 10.100.0.105#53(10.100.0.105) (UDP)
;; WHEN: Wed Jul 03 06:10:31 UTC 2024
;; MSG SIZE  rcvd: 158

Detailed Analysis

Line 1: The -x shorthand is the equivalent of querying for 10.65.29.10.in-addr.arpa, the proper FQDN for this reverse-mapping name.
Line 7: The status code NXDOMAIN indicates that the server 10.100.0.105 cannot resolve this name.
Line 8: We see the rd and ra flags, indicating the query we sent was requesting recursion, and the server responded with recursion-available. If this server (10.100.0.105) was authoritative, we should see the aa flag. The fact that the aa flag is missing, should clearly indicate that this server (10.100.0.105) is not authoritative for the zone.
Line 17: This response in the AUTHORITY section indicates the authoritative server should be prisoner.iana.org.

Combine what we learned from lines 7, 8, and 17, we know this name server (10.100.0.105) does not have the authoritative data, thus it went to the Internet attempting to resolve this name (10.65.29.10.in-addr.arpa), and the answer from the Internet is to query prisoner.iana.org.

Creating a reverse mapping zone

Create the missing reverse zone 29.65.10.in-addr.arpa and assign it to your DNS servers, ibns1 and ibns2. Reverse records will automatically be populated from Infoblox host records.