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 |
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:
$ 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
andra
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 theaa
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:
$ 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
andra
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 theaa
flag. The fact that theaa
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.