Consolidated NIOS DDI DNS Service Administration Lab (2582)

Subtask 1.1 Solution: Allowing DNS queries on a member

DNS Access Control can be applied at any level of the DNS hierarchy. In this lab, we will be applying it on members.

1. Navigate to Data Management → DNS → Members

2. Check the box next to ibns1.techblue.net and click Edit

3. In the Member DNS Properties window, click on the Queries tab

4. Click Override in the Allow queries from section

5. Choose Set of ACEs radio button and click Add  dropdown

6. Select Any Address/Network and click Save & Close

Subtask 1.2 Solution: Restricting DNS queries on a member

For ibns2.techblue.net we will allow one network and deny all others

1. Navigate to Data Management → DNS → Members

2. Check the box next to ibns2.techblue.net and click Edit

3. In the Member DNS Properties window, click on Queries tab

4. Click Override in the Allow queries from section

5. Choose Set of ACEs radio button and click Add dropdown

6. Select IPv4 Network

7. Use the slider to set Netmask as /16

8. In the Address box, type in 10.100.0.0 and click Add

9. Click Save & Close

Subtask 1.3 Solution: Restarting Grid services

Changes made to DNS configuration will only take effect after a service restart on all members that were involved.

1. Restart the Service when prompted by clicking Restart in the banner

2. In the Restart Grid Services window, click Restart

Alternatively, we can also restart services from the Members menu by navigating to Grid → Grid Manager → Members or Data Management → DNS → Members

1. From the Toolbar on the right, click Restart Services

2. Select the radio button for Force restart services

3. Click Restart

Subtask 2.1 Solution: Creating an authoritative name server group with all Grid members

1. Navigate to Data Management → DNS → Name Server Groups

2. Click on the Add drop-down menu and select Authoritative

3. For Name, enter Internal NSG

4. Click the Add dropdown menu and select Grid Primary

5. In the Add Grid Primary section, click Select to display the Member Selector

6. In the Member Selector window click the entry for ibns1.techblue.net

7. The selected device (ibns1.techblue.net) appears in the Add Grid Primary section

8. Click the Add button to add ibns1.techblue.net as primary server

9. Add the Grid Secondary device to the Name Server Group by clicking Add  → Grid Secondary

10. In the section for Add Grid Secondary, click Select to open the Member Selector window

11. Click on ibns2.techblue.net

12. The device ibns2.techblue.net appears as the selected Grid Secondary

13. The Name Servers table for this group now shows ibns1 as Grid Primary and ibns2 as Grid Secondary

14. Click Save & Close

Subtask 2.2 Solution: Creating an authoritative name server group with an external secondary

1. Navigate to Data Management → DNS → Name Server Groups

2. Click on the Add drop-down menu and select Authoritative

3. For Name, enter Dev NSG

4. Click the Add dropdown menu and select Grid Primary

5. In the Add Grid Primary section, click Select to display the Member Selector

6. In the Member Selector window click the entry for ibns1.techblue.net

7. The selected device (ibns1.techblue.net) appears in the Add Grid Primary section

8. Click the Add button to add ibns1.techblue.net as primary server

9. Add the Grid Secondary device to the Name Server Group by clicking Add  → Grid Secondary

10. In the section for Add Grid Secondary, click Select to open the Member Selector window

11. Click on ibns2.techblue.net

12. The device ibns2.techblue.net appears as the selected Grid Secondary

13. Add the External Secondary device to the Name Server Group by clicking Add  → External Secondary

14. In the Add External Secondary section, provide Name devns.techred.net and for Address type in 10.100.1.44

15. Click the Add button to add devns.techred.net as External Secondary server

16. The Name Servers table for this group now shows ibns1 as Grid Primary, ibns2 as Grid Secondary and devns.techred.net as External Secondary

17. Click Save & Close

Subtask 2.3 Solution: Creating an authoritative name server group with an external primary

1. Navigate to Data Management → DNS → Name Server Groups

2. Click on the Add drop-down menu and select Authoritative

3. For Name, enter MS NSG

4. Click the Add dropdown menu and select External Primary

5. In the Add External Primary section, provide Name dc01.techred.net and for Address type in 10.100.1.33

6. Click the Add button to add dc01.techred.net as the primary server

7. Add the Grid Secondary device to the Name Server Group by clicking Add  → Grid Secondary

8. In the section for Add Grid Secondary, click Select to open the Member Selector window

9. Click on ibns1.techblue.net

10. The device ibns1.techblue.net appears as the selected Grid Secondary

11. Add the other Grid Secondary device to the Name Server Group by clicking Add  → Grid Secondary

12. In the section for Add Grid Secondary, click Select to open the Member Selector window

13. Click on ibns2.techblue.net

14. The device ibns2.techblue.net appears as the selected Grid Secondary

15. The Name Servers table for this group now shows dc01.techred.net as External Primary, ibns1 and ibns2 as Grid Secondary devices.

16. Click Save & Close

Subtask 3.1 Solution: Creating a named ACL

1. Navigate to Administration → Named ACLs

2. Click Add

3. For Name, enter Company Internal Subnets

4. Click Next

5. At Step 2 of 3, click the Add dropdown menu and select IPv4 Network from the list

6. For Address, enter 172.31.0.0/16

7. Use the slider to set the Netmask to 16 (255.255.0.0)

8. Default Permission is set to Allow, leave it at that

9. Click Add

10. Repeat the above steps to add all subnets from table 2582-1

11. Click Save & Close

12. The Named ACL table now includes the Company Internal Subnets entry.

Subtask 3.2 Solution: Applying the Named ACL to existing objects

Edit the Member DNS Grid Properties for both ibns1 and ibns2 and allow Recursive Queries from the Company Internal Subnets ACL

1. Navigate to Data Management → DNS →Members

2. Place a check next to ibns1.techblue.net and click the Edit button

3. Select the Queries tab

4. Scroll down to find the section for Recursion

5. Click the Override button

6. Place a check mark in the box for Allow recursion

7. Select the radio button for Named ACL

8. Click the Select Named ACL button

9. If Company Internal Subnets is the only Named ACL you have created, it will be populated automatically, otherwise from the Named ACL Selector screen, click the Company Internal Subnets link

10. Click Save & Close

11. Repeat the above steps for ibns2.techblue.net

12. Restart the DNS service by clicking Restart on the banner at the top of the Grid Manager window

13. At the Restart Grid Services window, click Restart

Subtask 4.1 Solution: Verifying resolver functionality

There are 2 ways to execute dig from the Grid, from the Dashboard, or from the CLI.

Using dig From Dashboards

1. In the GM web interface, navigate to Dashboards → Status.

2. Scroll down to the Dig Request widget.

3. You want to make sure other members, such as ibgmc.techblue.net and ibrep.techblue.net can use ibns1 (10.100.0.105) and ibns2 (10.200.0.105) for DNS lookups. Use this widget several times to make sure you can successfully resolve external names such as time.apple.com. Screenshot below shows a dig originating from ibgmc.techblue.net to 10.200.0.105 (ibns2) to lookup the name time.apple.com.

   

Using dig From CLI

1. Switch to the console of the NIOS VM, and use the dig command from the CLI to perform the query to either ibns1 (10.100.0.105) or ibns2 (10.200.0.105).

2. You may use the commands dig @10.100.0.105 time.apple.com. and dig @10.200.0.105 time.apple.com. to verify DNS lookup functionality.

3. Screenshot below shows a successful query from one of the NIOS devices.

   

Subtask 4.2 Solution: Configuring Grid DNS resolvers

1. Navigate to Grid→Grid Manager→Members.

2. Click on Toolbar → Grid Properties.

3. Click on the DNS Resolver tab on the left.

4. Place a check mark next to Enable DNS Resolver.

5. In the Name Servers box, click add (+) twice to add two rows.

6. Click in each row and enter in the DNS server IP addresses: 10.100.0.105 and 10.200.0.105

   

7. Click Save & Close

Subtask 4.3 Solution: Verifying DNS resolution from NIOS Grid

1. Navigate to Grid → Grid Manager.

2. Click on the NTP tile near the top, to switch to the NTP services section.

3. Click on Toolbar → Edit → Grid NTP Properties. This brings up the Grid NTP properties dialog window.

4. Place a check mark next to Synchronize the Grid with these External NTP Servers.

5. In the section Synchronize the Grid with these External NTP Servers, click Add to add a new entry.

6. The Add NTP Server wizard appears.

7. In the section NTP Server (FQDN or IP Address), enter time.apple.com

8. Click the button Resolve Name.

9. You should see a light blue banner across the top informing you the name can be resolved.

   

Why configure this at the member level? You might be wondering why we are repeating the same set of steps twice, once on each member. Why can’t we just do this once at the Grid level? We could, but that will apply this setting to every member on the Grid. That is rarely the case when configuring something like allowing DNS recursion. This is usually configured on a per-member basis. Our instructions assume this common use-case.

Subtask 5.1 Solution: Verifying the current lookup behavior

Before configuring recursion on Grid members, you should verify the current lookup behavior. Lookup command-line tools such as dig are ideal for testing DNS resolution behaviors. By looking up an external domain, that is, a domain that is not configured as authoritative on the Grid, we can test the current recursive lookup behavior. For the following instructions, we are repeating many of the same operations twice.

1. Login to jump-desktop, run the command dig @10.100.0.105 www.example.com. This verifies the behavior for ibns1.

2. Still on jump-desktop, run the command dig @10.200.0.105 www.example.com. This verifies the behavior for ibns2. Below is an example output of executing this command. Notice the REFUSED code on line 7. This is a clear indication that currently this member is refusing or not accepting recursive queries.

$ dig @10.200.0.105 www.example.com. 
; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>> @10.200.0.105 www.example.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 27364
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: 888e2ee4f4281fdee7f0be7564b83649901d42acb5a86910 (good)
;; QUESTION SECTION:
;www.example.com.		IN	A
;; Query time: 3 msec
;; SERVER: 10.200.0.105#53(10.200.0.105) (UDP)
;; WHEN: Wed Jul 19 19:15:21 UTC 2023
;; MSG SIZE  rcvd: 72

Subtask 5.2 Solution: Enabling Recursion on Members

Now that we have verified the behaviors, we may configure the DNS members ibns1 and ibns2 to allow recursive queries from any subnet.

For ibns1.techblue.net

1. In the GM web interface, navigate to Data Management → DNS → Members.

2. Check the box next to the member (ibns1.techblue.net ) and click Edit.

3. The Member DNS Properties dialog appears. Click on the Queries tab.

4. Scroll down to the section Allow recursion.

5. Select the radio button for Any.

   

6. Click Save & Close

For ibns2.techblue.net

1. In the GM web interface, navigate to Data Management → DNS → Members.

2. Check the box next to the member (ibns2.techblue.net ) and click Edit.

3. The Member DNS Properties dialog appears. Click on the Queries tab.

4. In the Allow queries from section, Choose Set of ACEs radio button.

5. Remove the existing entry for 10.100.0.0/16 by checking the box next to it and clicking on Delete.

   

6. Now click Add  dropdown

7. Select Any Address/Network.

8. Then Scroll down to the section Allow recursion.

9. Select the radio button for Any

   

10. Click Save & Close

After you have updated both ibns1 and ibns2, restart Grid services following the system banner across the top of the screen.

Subtask 5.3: Verifying the lookup behavior

After restarting services on the Grid, you should run the same lookup commands from Task 1. The same commands now should yield different results. We should look at the example from querying ibns1 below. Notice the status code on line 6 is now NOERROR, and we have the answer on line 14.

$ dig @10.100.0.105 www.example.com.
; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>> @10.100.0.105 www.example.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9990
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1220
; COOKIE: ac54fe73314316b3c6021c2f64b84189ce3dcc70a51e6c8a (good)
;; QUESTION SECTION:
;www.example.com.		IN	A
;; ANSWER SECTION:
www.example.com.	86400	IN	A	93.184.216.34
;; Query time: 247 msec
;; SERVER: 10.100.0.105#53(10.100.0.105) (UDP)
;; WHEN: Wed Jul 19 20:03:21 UTC 2023
;; MSG SIZE  rcvd: 88

Subtask 6.1 Solution: Configuring members for IPv4 DNS Anycast

Repeat the following steps for both members ibns1 and ibns2.

1. Navigate to Grid → Grid Manager → Members.

2. Highlight the member (ibns1.techblue.net or ibns2.techblue.net) and choose Edit.

3. Select the section for Anycast.

4. Under the Anycast Interfaces section, click the Add dropdown menu and select IPv4 Address.

5. In the Address field, enter 10.24.7.53, and check the checkbox for BGP

   

6. Don’t save yet, scroll down to the BGP Configuration section.

7. For the ASN, enter 65400.

8. In the BGP Neighbor Configuration section below, click the Add button.

9. In the field for Neighbor Router, enter 10.100.0.1.

10. In the Remote ASN field, enter 65247.

11. Click the Add button to add this entry.

    

12. Click Save & Close

13. A Warning message appears about changing network settings. Read and click Yes.

14. This member will be restarting. Repeat the same steps on the other member.

Subtask 6.2 Solution: Configuring DNS services on members to listen on additional IPv4 addresses

Perform the following steps to reconfigure the DNS services on members ibns1 and ibns2.

1. Navigate to Grid → Grid Manager → Services → DNS.

2. Place a check mark in the box next to the member (ibns1.techblue.net or ibns2.techblue.net) and click the Edit button.

3. The Member DNS Properties dialog window appears.

4. Under the General tab (displayed by default), find the section Listen on these additional IP addresses. Click Add.

5. A new entry appears with a drop-down menu for Address selection. Choose 10.24.7.53 (Anycast).

   

6. Click Save & Close

7. Repeat the same steps on the other member.

8. Restart service after both members have been configured.

9. Wait until all members are back to the Running (green) state before starting the next task.

Subtask 6.3 Solution: Verifying anycast address is reachable

1. Wait until both ibns1 and ibns2 have finished restarting.

2. On the jump-desktop, open a Terminal window. Enter the command ping 10.24.7.53.

   

When dealing with DNS anycast, it is important to test each component separately. Remember that the DNS service is built on top of the anycast service. Test that anycast is working with ping. Then test DNS with dig.

Subtask 6.4 Solution: Verifying DNS service on anycast address

1. On the jump-desktop, open a Terminal window. Enter the command dig @10.24.7.53 test1.techblue.net.

2. What name we look up is not important, nor is the response. What is important here is that we see a DNS response from this IP address.

   

Subtask 6.5: Verifying redundancy on anycast address

Disable the DNS service on member ibns1 to simulate a systems failure. Then query the IPv4 anycast address to resolve a name. If anycast is working as expected, the same IPv4 address will still respond even when a member if offline.

Starting a contiguous ping to the anycast address

1. Before disabling the DNS service, start a contiguous ping on jump-desktop to the anycast address 10.24.7.53 from a Terminal window.

2. Keep this Terminal window open as you disable the DNS service. You can observe that the anycast address is available throughout the process.

Disabling the DNS service

1. In the GM web interface, navigate to Data Management → DNS → Members.

2. Place a check in the box beside ibns1.techblue.net and click the Stop button in the Toolbar.

3. Click Yes to confirm the action.

4. Use the Refresh button in the bottom left of the window to update the display.

5. Wait for the Service Status for ibns1 to change to Not Running.

   

Verifying anycast Functionality

1. Return to the Terminal window that has the contiguous ping command running.

2. You should see no packet loss to the IP address 10.24.7.53, and the address is still reachable even after one of the DNS members have been disabled.

Verifying DNS Functionality

Repeat the dig lookup command from Subtask 6.4 . You should receive the same results.

1. On the jump-desktop, open a Terminal window. Enter the command dig @10.24.7.53 test1.techblue.net.

2. What name we look up and the response is not important. What is important here is that we still see a DNS response from this IP address, although one of the DNS members is now disabled.

Enabling the DNS service

1. In the GM web interface, navigate to Data Management → DNS → Members.

2. Place a check in the box beside ibns1.techblue.net and click the Start button in the Toolbar.

3. Click Yes to confirm the action.

4. Use the Refresh button in the bottom left of the window to update the display.

5. Wait for the Service Status for ibns1 to change to Running prior to proceeding to the next task.

Follow the steps below to add default forwarders for ibns1 and ibns2 to forward all recursive queries to the IP address 8.8.8.8 and 9.9.9.9.

1. Navigate to Grid → Grid Manager → Services → DNS

2. Check the box next to the member (such as ibns1.techblue.net or ibns2.techblue.net) and click Edit

3. This displays the Member DNS Properties dialog window. Click on the Forwarders tab.

4. Click the Override button.

5. Click + to add a row. In the empty Address field, enter the address 8.8.8.8.

6. Click + to add another row. In the empty Address field, enter the address 9.9.9.9.

7. Leave the checkbox next to Use Forwarders Only unchecked. (See notes below).

   

8. Click Save & Close

9. Do not restart the service yet; repeat the same steps on the second member.

After you have updated both ibns1 and ibns2, restart Grid services following the system banner across the top of the screen.

Use Forwarders Only. This checkbox controls the behavior of the NIOS member whether or not to fall back to using the DNS root servers for name resolution. When this box is checked, NIOS will only use the forwarder(s) defined in the section above. When this box is unchecked, NIOS will prefer the forwarder(s) defined above and fall back to using the root servers if needed. In this scenario, since we are forwarding to external or public IP addresses, this implies the NIOS members already have Internet access. Thus, it makes sense to assume that if the forwarders (8.8.8.8 and 9.9.9.9 in this case) become unreachable, the NIOS members (ibns1 and ibns2) has the ability to fall back to querying the root servers directly.

Ultimately, the decision whether or not to check this box is up to you. There is no right or wrong answer, it’s how you want your DNS resolution to behave. If you want all queries to only go through the forwarder (8.8.8.8 and 9.9.9.9 in this case), then you can check the box. With the box checked, should 8.8.8.8 and 9.9.9.9 become unreachable, your DNS members (ibns1 and ibns2) will stop resolving domain names that require recursion (i.e. domain names that are outside of the Grid).

Subtask 8.1 Solution: Verifying DNS resolution before change

Using the VM testing-linux or testing-windows, verify the current DNS resolution before making changes. You may query for the names listed in Table 2582-2 and verify they resolve to addresses listed under Default View Answer. You should also execute the same lookup queries from the VM jump-desktop to compare current behavior.

Verifying from testing-windows

1. Switch to the VM testing-windows and login.

2. Launch a command prompt by clicking on the icon in the systems tray.

3. Use the nslookup command to verify DNS lookup behavior. We lookup the forward-mapping name, and lookup the IP address returned to check the reverse-mapping.

   CODE

   C:\Users\training>nslookup www.techblue.net.
   Server:  ibns1.techblue.net
   Address:  10.100.0.105
   Name:    www.techblue.net
   Address:  128.171.133.11
   C:\Users\training>nslookup 128.171.133.11
   Server:  ibns1.techblue.net
   Address:  10.100.0.105
   Name:    www.techblue.net
   Address:  128.171.133.11
   C:\Users\training>

4. We can verify the answer(s) currently returned contain the public IP address(es) listed under the Default View Answer column.

Verifying from jump-desktop

1. Switch to the VM jump-desktop and login.

2. Launch a Terminal Emulator for command prompt by clicking on the icon in the systems tray.

3. Use the dig command to verify DNS lookup behavior. Again, we verify both the forward-mapping and the reverse-mapping.

   CODE

   $ dig @10.100.0.105 www.techblue.net. +short
   128.171.133.11
   $ dig @10.100.0.105 -x 128.171.133.11 +short
   www.techblue.net.

4. We can verify the answer(s) currently returned contain the public IP address(es) listed under the Default View Answer column.

Subtask 8.2 Solution: Creating a new DNS view

Create a new DNS view named VPN. Configure the view to match clients from the network 172.31.101.0/24.

1. Login to the GM interface. Navigate to Data Management → DNS.

2. From the Toolbar, click Add → DNS View. The Add DNS View dialog window appears.

3. Step 1 of 4, in the DNS View text field, enter VPN for the name of the view. Click Next.

4. Step 2 of 4, for Match Clients, click the radio button Set of ACEs

5. Click Add (+) → IPv4 Network, the Add IPv4 Network section appears.

6. For the Address, enter 172.31.101.0.

7. Slide the Netmask bar to 24.

8. Click Add. The entry is added (see screenshot below).

   

9. Click Save & Close.

10. The display under Data Management → DNS → Zones is now updated to show the 2 DNS views: VPN and default.

    

11. You do not need to restart services yet. Even if you do restart now, there is no data in the new VPN view for you to test against.

Subtask 8.3 Solution: Creating authoritative zones

You need to review the list of authoritative zones in the default view and decide which ones you need to re-create in the VPN view.

Reviewing zones in the default view

1. Login to the GM web interface. Navigate to Data Management → DNS → Zones.

2. Click on the default view. We can see a list of currently configured zones. Note the Authoritative zones, techblue.net, techred.net , 10.in-addr.arpa, and 133.171.128.in-addr.arpa.

   

Since the new VPN view is intended for clients with private or internal IP addresses (10.x.x.x), we can conclude that we do not need to copy the external network space reverse zone (133.171.128.in-addr.arpa) to the new view. This is something you should confirm with your network architecture team.

Creating a zone in the VPN view

Use the steps below to create the 3 authoritative zones techblue.net, techred.net, and 10.in-addr.arpa:

1. Login to the GM web interface. Navigate to Data Management → DNS → Zones.

2. If you are already in the default view, click the DNS Home link on the upper left corner (above the name of the view) to return to the list of all view.

3. Click on the VPN view. There are currently no authoritative zones.

4. Click Add (+) → Authoritative Zone, this brings up the Add Authoritative Zone Wizard.

5. In step 1 of 6, select the zone type (forward mapping for techblue.net and techred.net, IPv4 reverse mapping for 10.in-addr.arpa) and click Next.

6. In step 2 of 6, enter the zone name (for techblue.net and techred.net ) or the IPv4 network 10.0.0.0/8 for the reverse-mapping zone. Click Next.

7. Step 3 of 6, leave the selection at Use this Name Server Group: Internal NSG.

8. Click Save & Close. This will map the zone to both members ibns1 and ibns2.

Subtask 8.4 Solution: Copying zone data

Instead of manually re-entering all DNS records, copy zone data from the default view to the VPN view.

Below are steps you need to take to copy all records in the zone from the default view to the zone in the VPN view. You need to repeat this for the zones techblue.net and techred.net.

You only need to do copy data for the zones techblue.net and techred.net , not for the reverse-mapping zone 10.in-addr.arpa. This is because NIOS will automatically generate reverse-mapping data from the forward-mapping data for you. You can verify this by clicking on the reverse-mapping zone before you copy any records. It should already have some records automatically populated based on system-generated information.

Copying data to the VPN view

Use the steps below to copy data from the default view to the VPN view.

1. In the GM web interface, navigate to Data Management → DNS → Zones .

2. If you are already in the VPN view, click the DNS Home link on the upper left corner (above the name of the view) to return to the list of all view.

3. Click on the VPN view. Select the zone to copy data from. Click Toolbar → Copy Records. The example below shows the zone techblue.net selected.

   

4. The Copy Records dialog window appears. In Destination, click Select Zone.

5. The Zone Selector dialog appears. Use the DNS View drop-down menu to switch to the VPN view.

   

6. Select the zone in the VPN view to copy data to. Click OK. This returns you to the Copy Records dialog window. Click Copy & Close.

   

Sub Task 8.5: Updating DNS records in the copied zone

Change records listed in Table 2582-2 to reflect the private IP addresses listed under VPN View Answer.

1. Login to the GM web interface. Navigate to Data Management → DNS → Zones.

2. If you are already in the default view, click the DNS Home link on the upper left corner (above the name of the view) to return to the list of all view.

3. Click on the VPN view. There should be 3 authoritative zones that we created and copied data into here.

4. Click on the zone techblue.net to access all the records that were copied here in the previous task.

5. Edit the records ftp and www to the private IP addresses listed in Table 2582-2:

   • ftp.techblue.net → 10.100.0.22

   • www.techblue.net → 10.100.0.11

     

6. Navigate to the zone techred.net by clicking on the link VPN above the zone name, then click on the zone techred.net.

7. Edit the records bar to the private IP addresses listed in Table 2582-2:

   • bar.techred.net → 10.100.0.33

8. Navigate to the zone 10.in-addr.arpa by clicking on the link VPN above the zone name, then click on the zone 10.in-addr.arpa.

9. You can review that all the reverse-mapping records have been automatically generated here.

Subtask 8.6: Verifying DNS view ordering

Because your DNS members have more than 1 view, you need to verify order of DNS views on the members are correct.

Best practice recommends “one member, one view”, and there would be no DNS view ordering involved. However, since we are making our DNS members serve 2 views, we must verify the order of DNS views correct. In our case, we want the VPN view to be listed at the top, because it has a match-client statement for 172.31.101.0/24. The default view does not have any match-client statement. If the default view was listed first, no one will ever hit the VPN view, everyone will get matched into the default view.

Repeat the steps below for both ibns1 and ibns2.

1. In the GM web interface, navigate to Data Management → DNS → Members.

2. Select the member (ibns1 or ibns2) and click Edit. The Member DNS Properties dialog opens.

3. Toggle to the Advanced Mode if not already toggled.

4. Click the DNS Views tab on the left.

5. Scroll down to the section Order of DNS Views. Make sure VPN is listed first.

   

6. Click Save & Close.

7. Restart services when prompted.

Subtask 8.7 Solution: Verifying DNS resolution after change

Repeat the lookups from Task 1 to verify the new DNS resolution after making changes.

Verifying from testing-windows

1. Switch to the VM testing-windows and login.

2. Launch a command prompt by clicking on the icon in the systems tray.

3. Use the nslookup command to verify DNS lookup behavior:

   CODE

   C:\Users\training>nslookup www.techblue.net.
   Server:  ibns1.techblue.net
   Address:  10.100.0.105
   Name:    www.techblue.net
   Address:  10.100.0.11
   C:\Users\training>nslookup 10.100.0.11
   Server:  ibns1.techblue.net
   Address:  10.100.0.105
   Name:    www.techblue.net
   Address:  10.100.0.11
   C:\Users\training>

4. We can verify the answer(s) currently returned contain the private IP address(es) listed under the VPN View Answer column.

Verifying from jump-desktop

1. Switch to the VM jump-desktop and login.

2. Launch a Terminal Emulator for command prompt by clicking on the icon in the systems tray.

3. Use the dig command to verify DNS lookup behavior:

   CODE

   $ dig @10.100.0.105 www.techblue.net. +short
   128.171.133.11
   $ dig @10.100.0.105 -x 128.171.133.11 +short
   www.techblue.net.

4. We can verify the answer(s) currently returned contain the public IP address(es) listed under the Default View Answer column.

Subtask 9.1 Solution: Renaming the DNS View

1. In Data Management → DNS → Zones, you should see both views (VPN and default).

2. Select the view default and click Edit.

3. In the DNS View field, change the name to External. Click Save & Close.

4. Now select the view VPN and click Edit.

5. In the DNS View field, change the name to Internal. Click Save & Close.

If you do not see multiple DNS views under Data Management → DNS → Zones, you might be inside of a zone. Look for the DNS Home link on the upper left corner, it should be located between the name of the view and the sub menus. This link will display all of the DNS views configured for the Grid.

Subtask 9.2 Solution: Configuring NAT'ed IP Addresses for Glue Records

The DNS member configuration needs to be updated. After the update, the Infoblox Grid will automatically reconfigure the zone records in the external DNS view.

Perform the following steps on the members ibns1 and ibns2:

1. Navigate to Data Management → DNS → Members, edit the Member DNS Properties.

2. Toggle into Advanced Mode and select DNS Views from the side menu.

3. In the section IPv4 Address of Member Used in DNS Views, look for External. It defaults to Interface IP address. Change it from Interface IP Address to Other IP Address, and enter the public or external IP address for this member. The example screenshot shows the completed configuration for the member ibns1.techblue.net. Please refer to Table 2582-3 for details.

   

4. Click Save & Close. You will be prompted to restart the service. Wait until you have configured both members, then restart the service.

Subtask 9.3 Solution: Verifying resolution

Verifying from testing-windows

1. Switch to the VM testing-windows and login.

2. Launch a command prompt by clicking on the icon in the systems tray.

3. Use the nslookup command to verify DNS lookup behavior:
   When we run the query from testing-windows, the answer comes from the Internal view, and we can verify that it is correct. Notice the presence of the private IP address, which confirms that the response is sourced from the Internal DNS view on member 10.100.0.105.

   CODE

   C:\Users\training>nslookup ibns1.techblue.net.
   Server:  ibns1.techblue.net
   Address:  10.100.0.105
   
   Name:    ibns1.techblue.net
   Address:  10.100.0.105
   
   C:\Users\training>nslookup 10.100.0.105
   Server:  ibns1.techblue.net
   Address:  10.100.0.105
   
   Name:    ibns1.techblue.net
   Address:  10.100.0.105

Verifying from jump-desktop

1. Switch to the VM jump-desktop and log in.

2. Launch a Terminal Emulator for command prompt by clicking on the icon in the systems tray.

3. Use the dig command to verify DNS lookup behavior:
   When we run the same query, the answer comes from the External view, and we can verify that it is correct. Notice the presence of the AA flag, which confirms that we are receiving this authoritative answer from member 10.100.0.105.

   CODE

   $ dig @10.100.0.105 ibns1.techblue.net. A
   ; <<>> DiG 9.11.12 <<>> @10.100.0.105 ibns1.techblue.net. A
   ; (1 server found)
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59671
   ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
   ;; OPT PSEUDOSECTION:
   ;; QUESTION SECTION:
   ;ibns1.techblue.net.            IN    A
   ;; ANSWER SECTION:
   ibns1.techblue.net. 28800 IN    A     203.0.113.50
   ;; Query time: 5 msec
   ;; SERVER: 10.100.0.105#53(10.100.0.105)
   ;; WHEN: Thu Aug 19 20:50:16 UTC 2021
   ;; MSG SIZE  rcvd: 91