Skip to main content
Skip table of contents

3515 - Troubleshooting reverse DNS resolution in NIOS


The A record is created, it points to the IPv4 address 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






Grid Manager UI




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

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


Task 1: Verifying forward-mapping DNS Lookup

Verify that the newly added record can be resolved by querying members on the Grid. You may query ibns1 ( or ibns2 (

Task 2: Troubleshooting reverse DNS lookup

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


Task 1 Solution: Verifying forward-mapping DNS Lookup

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

$ dig @ 

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> @
; (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

; EDNS: version: 0, flags:; udp: 1220
; COOKIE: b9956f3221b78381d89294dd64c42921797150381bce3e64 (good)
;		IN	A


;; Query time: 0 msec
;; WHEN: Fri Jul 28 20:46:25 UTC 2023
;; MSG SIZE  rcvd: 89

Detailed Analysis

  • Line 1: We query the name server directly.

  • Line 7: The status code NOERROR indicates that the server 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

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

Next, we need to check the reverse-mapping, to see if the IP address points to the name

Task 2 Solution: Troubleshooting reverse DNS lookup

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

$ dig @ -x

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @ -x
; (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

; EDNS: version: 0, flags:; udp: 1220
; COOKIE: 4a20bc2aee506ce52b08ddbc6684eb57cc88e40ba510a74b (good)

;; AUTHORITY SECTION:	10795	IN	SOA 1 604800 60 604800 604800

;; Query time: 4 msec
;; 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, the proper FQDN for this reverse-mapping name.

  • Line 7: The status code NXDOMAIN indicates that the server 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 ( was authoritative, we should see the aa flag. The fact that the aa flag is missing, should clearly indicate that this server ( is not authoritative for the zone.

  • Line 17: This response in the AUTHORITY section indicates the authoritative server should be

Combine what we learned from lines 7, 8, and 17, we know this name server ( does not have the authoritative data, thus it went to the Internet attempting to resolve this name (, and the answer from the Internet is to query

Creating a reverse mapping zone

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

JavaScript errors detected

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

If this problem persists, please contact our support.