Skip to main content
Skip table of contents

3519 - Troubleshooting DNS zone transfer issues in NIOS


Your network team informs you that a new zone has been configured on the load balancer, the load balancer is ( The name of the new zone is You are tasked with configuring both ibns1 and ibns2 to hold a read-only copy of this zone.

Configure both Grid members (ibns1) and (ibns2) to be secondary name servers for this zone.

Estimate Completion Time

  • 30 to 40 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


To complete this lab, you need to perform the following tasks.

  1. Add secondary authoritative zone

  2. Troubleshoot name resolution issue

Task 1: Configure your Grid Members as Secondaries

Configure both Grid members (ibns1) and (ibns2) to be secondary name servers for this zone.

Task 2: Troubleshoot Name Resolution

After you have setup the secondary zone on both members (ibns1) and (ibns2), users report when they query (ibns1), the name resolves, but not when queried against (ibns2). Please troubleshoot and find the root cause.

Hint: Use the following commands for lookup:

Lookup using member ibns1: dig @

Lookup using member ibns2: dig @


Task 1 Solution: Configure your Grid Members as Secondaries

  1. First verify the primary master name server by retrieving the SOA record

    1. This will identify the primary as

  2. Resolve to determine its IP current address.

  3. Create an Authoritative Forward-Mapping zone for

    1. Specify as the External Primary.

    2. Specify ibns1 and ibns2 as Grid Secondaries.

  4. Verify in Grid Manager UI by navigating to Data Management DNS Zones, the zone data should load and you can see the records configured in the zone

  5. You should also verify by performing a lookup against ibns1 to verify the AA flag is present (indicating authoritative answer)

    $ dig @
    ; <<>> DiG 9.11.12 <<>> @
    ; (1 server found)
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64182
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
    ; IN   A
    ;; AUTHORITY SECTION: 300 IN SOA 4 10800 3600 2419200 300
    ;; Query time: 7 msec
    ;; SERVER:
    ;; WHEN: Thu Aug 19 21:04:30 UTC 2021
    ;; MSG SIZE  rcvd: 146

Task 2 Solution: Troubleshoot Name Resolution

  1. Resolution of against ibns1 should be successful.

    1. AA flag will be set in dig as ibns1 is authoritative for the zone.

  2. Resolution of against ibns2 will fail with SERVFAIL error message.

  3. Member (nios-4) is unable to transfer zone

    1. Performing standard dig queries against from ibns2 will work such as dig @

    2. Using dig on ibns2 with +tcp or +vc option set will cause the query to fail/timeout.

    3. Using dig on ibns2 to request a manual zone transfer (AXFR) will fail/timeout (dig @ AXFR)

This is proof that TCP/53 is blocked, preventing zone transfer from evocati to ibns2.

JavaScript errors detected

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

If this problem persists, please contact our support.