Split DNS is a method in some name server implementations that enables zone data to appear differently depending on which client queries the name server. For example, Internet clients might be restricted to a subset of resource records in a zone, while intranet clients might have access to all resource records in a zone.
The BIND 9 name server implementation supports split DNS through the view statement.
If you want to configure split DNS for an ADNR-managed zone, there are some special considerations. When implementing split DNS for a domain, the zone data is kept in separate files in the name server for each view of the zone. This implies that the data is disjointed, and in many respects ADNR must treat each view like a separate zone. When performing dynamic updates to a split DNS zone, the name server might determine which view to update based upon the source IP address of the nsupdate client. The BIND 9 name server uses this criteria to determine which view to update, and ADNR is the update client in this regard. Therefore, ADNR must use separate source IP addresses to update each view. This can be accomplished in the following ways:
By configuring an ADNR application for each view, a unique source IP address can be associated with each ADNR instance using job-specific source IP addressing. The source IP address assigned to ADNR needs to be configured appropriately in the name server. For the BIND 9 name server, the source IP address of the ADNR instance that you want to have update a specific view would appear in that view's match-clients statement.
The easiest way for each ADNR instance to use unique source IP addresses is to run each instance on separate systems or TCP/IP stacks. If each ADNR instance must run on the same TCP/IP stack, you can use job-specific source IP addressing to provide unique source IP addresses. This involves mapping the ADNR job names to the source IP address to be used using the JOBNAME entry in the SRCIP statement block of the TCP/IP profile. However, each ADNR instance creates multiple address spaces, whose job names are the ADNR start procedure name with a numerical digit appended (for example, the ADNR job creates the ADNR1 and ADNR2 jobs). To use this method, job-specific source IP addressing has to specify the ADNR start procedure name followed by a wildcard when specifying the job name. Also, to avoid conflicting job names of the spawned address spaces among the multiple ADNR instances, you need to name the start procedures of the ADNR jobs so that the spawned job names do not conflict. For example, the start procedure names of ADNRP and ADNRT create unique job names among their instances, such as ADNRP1 and ADNRT1; create unique source IP addresses by coding JOBNAME ANDRP* source_ip_address1 and JOBNAME ADNRT* source_ip_address2.
By understanding and exploiting TCP/IP's source IP address selection algorithm you can configure ADNR and locate name servers in the network, so that ADNR uses appropriate source IP addresses to dynamically update the appropriate views. For more information, see Source IP address selection.
This technique involves coding separate dns statements in the ADNR configuration file, specifying different IP addresses for each dns statement (of the same multi-homed name server) and using the separate dns statements to update different views. If configured correctly, and depending on the IP address of the name server, the source IP address of ADNR can be influenced to match the IP address in the match-clients statement of the appropriate view in the name server.
The most predictable way to assign the correct source IP address for each separate view in this scenario is to use the DESTINATION entry in the SRCIP statement block of the TCP/IP profile. For example, if two dns statements with different IP addresses are coded in the ADNR configuration file, where each represents different views in the same name server, two DESTINATION entries are coded in the SRCIP statement of the TCP/IP profile. One DESTINATION entry contains the IP address from one of the dns statements as the destination IP address, and the second DESTINATION entry contains the IP address from the other dns statement as the destination IP address. The source IP address contained in each DESTINATION entry matches one of the IP addresses in the match-clients statement in the name server configuration file of the appropriate view to be updated.