Creating a DNS delegated zone in Universal DDI (2593)
Scenario
You are the administrator for the domain techblue.net. The development team at Techblue has created a new environment for their internal use and testing. To support this, they set up their own DNS system and asked for full control of the subdomain dev.techblue.net.
The development team has already configured their DNS server support-server.dev.techblue.net (10.100.0.20) with the zone and records. The team has requested that you resolve the record app1.dev.techblue.net to verify that the setup is working properly.
Your task is to delegate the subdomain dev.techblue.net to this server, allowing the development team to manage their own DNS records.
In this lab scenario, we are delegating to only one server, 10.100.0.20. This is uncommon and not advised for production. For a production environment, choose at least two target servers for redundancy.
The example we have in the lab environment is more similar to an internal namespace rather than a public or external namespace. If you are setting this up for an internal or private namespace, you should probably avoid delegation and instead use a forward zone or conditional forwarding.
Estimated Completion Time
15 to 20 minutes
Prerequisites
Administrative access to the Infoblox Portal
Learning Content
Tasks
Pre-delegation Tests: Resolve the name app1.dev.techblue.net against both the parent and the child zone.
Create the Delegated Zone: Create the delegated zone dev.techblue.net on the parent zone techblue.net.
Validate the Delegation: Verify that the delegation is functioning correctly by resolving the name app1.dev.techblue.net against the parent zone.
Task 1: Pre-delegation Tests
Perform two separate lookups for the name app1.dev.techblue.net. The first lookup queries the parent (10.100.0.110), while the second lookup queries the child (10.100.0.20).
In the VM desktop-linux, use the command dig to execute two lookups for the name app1.dev.techblue.net. First, run the dig command against the parent oph1 (10.100.0.110). Then, run the identical dig command against the (would-be) child support-server.dev.techblue.net (10.100.0.20).
Task 2: Create the Delegated Zone
Now that we have verified the child zone is properly configured, create a delegated zone dev.techblue.net on the parent and delegate the authority to support-server.dev.techblue.net (10.100.0.20).
Task 3: Validate the Delegation
The goal here is to validate that the parent returns a referral message to delegate the namespace to the child as intended.
In the VM desktop-linux, use the command dig to query the parent server 10.100.0.110 for the name app1.dev.techblue.net and confirm the referral message is returned.
Solutions
Task 1 Solution: Pre-delegation Tests
If you do not have the zone techblue.net, retrace the steps in Creating a Primary Zone in Universal DDI.
We have two goals here: the first is to observe the response from the parent zone before delegation is created. The second goal is to make sure the child zone can resolve the name correctly before we delegate to it.
Use the virtual machine testing-linux and open a Terminal window.
Run the following command to query DNS server 10.100.0.110 for the A record of app1.dev.techblue.net:
dig @10.100.0.110 app1.dev.techblue.net. A. This should return NXDOMAIN since delegation is not yet configured, and the parent zone is not aware of this name. Notice the aa flag in the response. This is the parent zone server saying: I am authoritative for this name, and it (app1.dev.techblue.net) does not exist.
Next, query DNS server 10.100.0.20 (support-server.dev.techblue.net) for the same name using the command
dig @10.100.0.20 app1.dev.techblue.net. A. In this case, the status in the output shows NOERROR, and we can observe the aa flag in the DNS header, indicating that this server is authoritative for this name.
Task 2 Solution: Create the Delegated Zone
If you do not have the zone techblue.net, retrace the steps in Creating a Primary Zone in Universal DDI.
Log in to your lab’s jump-desktop.
Use your Education Infoblox Portal Credentials to log into the Infoblox Portal.
Navigate to Configure → Networking → DNS.
Select the Zones horizontal tab. A list of all currently configured DNS views is displayed. By default, there is only one DNS view named default.
Click on the DNS view default.
Click the button Create. Select Zone Delegation.
Click Select Zone
Select default → techblue.net and click Select.
Enter the Name dev (the zone name techbelue.net is automatically appended).
Under Authoritative DNS Servers, enter support-server.dev.techblue.net as the name and 10.100.0.20 as the IP address.
Click Save & Close.
You would be back to the Configure → Networking → DNS → Zones page.
Click on the hamburger menu next to techblue.net and click Edit.
Under Zone Settings Default, you must uncheck Use default forwarders to resolve queries for delegated subzones. For this, click the slider to Override. Click Save & Close.
If you do not perform the last step correctly to uncheck the box Use default forwarders to resolve queries for delegated subzones, queries for the child domain will be forwarded instead of being delegated. Depending on your configuration, names may still resolve (or maybe not), and there are subtle differences in name server responses and behaviors.
Task 3 Solution: Validate the Delegation
Switch to the virtual machine testing-linux and open a Terminal window.
Use the following command to verify the delegation is working:
dig @10.100.0.110 app1.dev.techblue.net. A. Compare this to the results from Task 1. Notice the aa flag is not here anymore. This is the parent zone saying: “I am not authoritative for this name. I resolved the name, and the answer was obtained from the authoritative server 10.100.20.21.”