In addition to authoritative zones, the NIOS appliance allows you to configure delegated, forward, and stub zones. A delegated zone is a zone managed by (delegated to) another name server who owns the authority for the zone. A forward zone is where queries are sent before being forwarded to other remote name servers. A stub zone contains records that identify the authoritative name servers in another zone. This section covers the following topics:
...
- From the DataManagement tab, select the DNS tab -> Zones tab.
- Click the parent zone to open it.
Grid Manager displays the Records and Subzones tabs of the zone. - From the Subzones tab, click the Add icon -> Zone -> AddDelegation.
- In the AddDelegation wizard, specify the following:
- Name: This field displays a dot followed by the domain name of the current zone. Enter one or more labels before the dot to specify the domain name of the subzone.
- DNSView: This field displays only when there is more than one DNS view in the network view. Displays the DNS view of the current zone.
- Comment: Optionally, enter additional text about the zone.
- Disable: Click this check box to temporarily disable this zone. For information, see Enabling and Disabling Zones
- Lock: Click this check box to lock the zone so that you can make changes to it, and also prevent others from making conflicting changes. For information, see Locking and Unlocking Zones.
- Click Next to assign a delegation name server group or define the name servers for the zone. Select one of the following:
- Usethisnameservergroup: Select this to assign a delegation NS group for the delegated zone. You can select the delegation NS group from the drop-down list.
- Usethissetofnameservers: Select this to define name servers for the delegated zone. In the Name Servers panel, click the Add icon and specify the following information:
- Name: Enter the name of a remote name server to which you want the local server to redirect queries for zone data. This is a name server that is authoritative for the delegated zone.
- Address: Enter the IP address of the delegated server.
For information about delegation NS group, see Using Delegation Name Server Groups. - Save the configuration and click Restart if it appears at the top of the screen, or click Next to define extensible attributes as described in Using Extensible Attributes.
or
Click the Schedule icon at the top of the wizard to schedule this task. In the ScheduleChange panel, enter a date, time, and time zone. For information, see Scheduling Tasks.
Note |
---|
|
The DNS server resolves the FQDN of the delegated name server and does not use the IP address that you specify when assigning the delegated name servers. |
Configuring a Delegation for a Reverse-Mapping Zone
...
- From the DataManagement tab, select the DNS tab -> Zones tab.
- Click the parent zone to open it.
Grid Manager displays the Records and Subzones tabs of the zone. - From the Subzones tab, click the Add icon -> Zone -> AddDelegation.
- In the AddDelegation wizard, specify the following:
- IPv4Network: This field displays if you are creating a delegation zone for an IPv4 reverse-mapping zone. Enter the IPv4 address for the address space for which you want to define the reverse-mapping zone and select a netmask from the Netmask drop-down list. Alternatively, you can specify the address in CIDR format, such as 192/8.
- To use an RFC 2317 prefix, select a netmask value that is between 25 to 31, inclusive. Grid Manager displays the following fields:
- RFC2317Prefix: Enter a prefix in this field. Prefixes can include alphanumeric characters.
- AllowmanualcreationofPTRrecordsinparentzone: Select this check box to allow users to create labels that correspond to IP addresses in the delegated address space in the parent zone.
- For information about RFC 2317, see Specifying an RFC 2317 Prefix.
- IPv6NetworkPrefix: This field displays if you are creating a delegation zone for an IPv6 reverse-mapping zone. Enter the IPv6 prefix for the address space for which you want to define the reverse-mapping zone and select the prefix length from the drop-down list.
- Name: This field displays a dot followed by the domain name of the current zone. Enter one or more labels before the dot to specify the domain name of the subzone.
- DNS View: This field displays only when there is more than one DNS view in the network view. Select a DNS view from the drop-down list.
- Comment: Optionally, enter additional text about the zone.
- Disable: Select this option to temporarily disable this zone.
- Lock: Select this option to lock the zone so that you can make changes to it and prevent others from making conflicting changes.
- Click Next to assign a delegation name server group or define the name servers for the zone. Select one of the following:
- Usethisnameservergroup: Select this to assign a delegation NS group for the delegated zone. You can select the delegation NS group from the drop-down list.
- Usethissetofnameservers: Select this to define name servers for the delegated zone. In the Name Servers panel, click the Add icon and specify the following information:
- Name: Enter the name of a remote name server to which you want the local server to redirect queries for zone data. This is a name server that is authoritative for the delegated zone.
- Address: Enter the IP address of the delegated server.
For information about delegation NS groups, see Using Delegation Name Server Groups. - Save the configuration and click Restart if it appears at the top of the screen, or click Next to define extensible attributes as described in Using Extensible Attributes.
or
Click the Schedule icon at the top of the wizard to schedule this task. In the ScheduleChange panel, enter a date, time, and time zone. For information, see Scheduling Tasks.
Note |
---|
|
The DNS server resolves the FQDN of the delegated name server and does not use the IP address that you specify when assigning the delegated name servers. |
Anchor |
---|
| Configuring a Forward Zone |
---|
| Configuring a Forward Zone |
---|
|
Configuring a Forward Zone
...
Stub zones, like secondary zones, obtain their records from other name servers. Their records are read only; therefore, administrators do not manually add, remove, or modify the records.
Stub zone records are also periodically refreshed, just like secondary zone records. However, secondary name servers contain a complete copy of the zone data on the primary server. Therefore, zone transfers from a primary server to a secondary server, or between secondary servers, can increase CPU usage and consume excessive bandwidth. A name server hosting a stub zone maintains a much smaller set of records; therefore, updates are less CPU intensive and consume less bandwidth.
When a name server hosting a stub zone receives a query for a domain name that it determines is in the stub zone, the name server uses the records in the stub zone to locate the correct name server to query, eliminating the need to query the root server.
Figure 19.8 and Figure 19.9 illustrate how the NIOS appliance resolves a query for a domain name for which it is not authoritative. Figure 19.8 illustrates how the appliance resolves a query when it does not have a stub zone.
Figure 19.9 illustrates how the appliance resolves the query with a stub zone.
In Figure 19.8, a client sends a query for ftp.sales.corp200.com to the NIOS appliance. When the appliance receives the request from the client, it checks if it has the data to resolve the query. If the appliance does not have the data, it tries to locate the authoritative name server for the requested domain name. It sends nonrecursive queries to a root name server and to the closest known name servers until it learns the correct authoritative name server to query.
Figure 19.8 Processing a Query without a Stub Zone Drawio |
---|
border | true1 |
---|
viewerToolbar | true |
---|
fitWindow | false |
---|
baseUrl | https://infoblox-docs.atlassian.net/wiki |
---|
diagramName | 19.8 | simpleViewer | false |
---|
zoom | 1 |
---|
pageId | 22251653 |
---|
custContentId | 8656202 |
---|
lbox | 1 |
---|
contentVer | 1 |
---|
revision | 1 |
---|
|
In Figure 19.9, when the NIOS appliance receives the request for the domain name in corp200.com, it determines it does not have the resource records to resolve the query. It does, however, have a list of the authoritative name servers in the stub zone, corp200.com. The appliance then sends a query directly to the name server in corp200.com.
Figure 19.9 Processing a Query with a Stub Zone
Drawio |
---|
border | true1 |
---|
viewerToolbar | true |
---|
fitWindow | false |
---|
baseUrl | https://infoblox-docs.atlassian.net/wiki |
---|
diagramName | 19.9 | simpleViewer | false |
---|
zoom | 1 |
---|
pageId | 22251653 |
---|
custContentId | 7345686 |
---|
lbox | 1 |
---|
contentVer | 1 |
---|
revision | 1 |
---|
|
Stub zones facilitate name resolution and alleviate name server traffic in your network. For example, the client in the previous examples is in corpxyz.com. The corpxyz.com and corp200.com zones are partners, and send all their communications through a VPN tunnel, as shown in Figure 19.10. The firewall protecting corpxyz.com is configured to send all messages for the 10.2.2.0/24 network through the VPN tunnel. Infoblox_A hosts the stub zone for corp200.com. Therefore, when the host in corpxyz.com sends a query for ftp.sales.corp200.com, Infoblox_A obtains the IP address of Infoblox_B (10.2.2.7) from its stub zone records and sends the query to the firewall protecting corpxyz.com.
Because the destination of the query is in the 10.2.2.0/24 network, the firewall (configured to encrypt all traffic to the network) sends the request through a VPN tunnel to Infoblox_B. Infoblox_B resolves the query and sends back the response through the VPN tunnel. All name server traffic went through the VPN tunnel to the internal servers, bypassing the root servers and external name servers.
Figure 19.10 Stub Zone Configuration Drawio |
---|
border | true1 |
---|
viewerToolbar | true |
---|
fitWindow | false |
---|
baseUrl | https://infoblox-docs.atlassian.net/wiki |
---|
diagramName | 19.10 | simpleViewer | false |
---|
zoom | 1 |
---|
pageId | 22251653 |
---|
custContentId | 8656196 |
---|
lbox | 1 |
---|
contentVer | 1 |
---|
revision | 1 |
---|
|
In parent-child zone configurations, using stub zones also eases the administration of name servers in both zones. For example, as shown in Figure 19.10, sales.corp200.com is a child zone of corp200.com. On the corp200.com name servers, you can create either a delegated zone or a stub zone for sales.corp200.com.
When you create a delegated zone, you must first specify the name servers in the delegated zone and manually maintain information about these name servers. For example, if the administrator in sales.corp200.com changes the IP address of a name server or adds a new name server, the sales.corpxyz.com administrator must inform the corp200.com administrator to make the corresponding changes in the delegated zone records.
If, instead, you create a stub zone for sales.corp200.com, you set up the stub zone records once, and updates are then done automatically. The name servers in corp200.com that are hosting a stub zone for sales.corp200.com automatically obtain updates of the authoritative name servers in the child zone.
In addition, a name server that hosts a stub zone can cache the responses it receives. Therefore, when it receives a request for the same resource record, it can respond without querying another name server.
...