Employ split horizon DNS service if you are using non-public IP address ranges.

You've come to this page because you've asked questions similar to the following:

Many computers on my network are trying to communicate with 192.175.48.1 on port 53. Why is this? This is bringing up my dial-on-demand IP connection/tripping detectors on my firewall/bothering my cat. How do I stop it?

My DHCP client/server is reporting an error, saying that it was unable to send Dynamic DNS updates to prisoner.iana.org.. Why is this?

My machine is reporting an error, saying that its "security system" was unable to "establish a secured connection" with prisoner.iana.org.. Why is this?

This is the Frequently Given Answer to such questions.

Whenever you use one of the non-public IP address ranges, you employ router rules to ensure that IP traffic using your non-public IP addresses doesn't leak across your borders. Similarly, you should also employ "split horizon" DNS service in order to ensure that DNS lookups and Dynamic DNS update requests relating to your non-public IP address range don't leak across your borders, either.

The traffic to and from 192.175.48.1, the error messages from DHCP client/servers, and the security subsystem errors are all caused by the fact that you haven't done this.

What to do

A common mistake

A common mistake, that you should avoid making, is to reason that since one is only using a subnet of the reserved IP address range that one is using, one only need configure "split horizon" DNS service for that subnet only.

For example: If one were using only 192.168.0.0/24, one might reason that one only need configure "split horizon" DNS service for just 0.168.192.in-addr.arpa. and its subdomains, and not the entirety of 168.192.in-addr.arpa..

Doing this is wrong, for several reasons:

• It is not mistake-proof. Even though one might be using, say, only 10.0.0.0/24 instead of the entirety of 10.0.0.0/8, that doesn't preclude the possibility of network administrators (or others) making typing errors and hence using, say, 10.0.1.1.

  Covering the reverse lookup domains for the entire address range, conversely, ensures that even accidentally mis-typed IP addresses don't cause DNS lookups that will leak across one's borders.

• It is not future-proof. Even though right now one might be using, say, only 192.168.0.0/24 instead of the entirety of 192.168.0.0/16, that doesn't preclude the possibility of expansion in the future, such as, say, a network administrator creating an additional 192.168.1.0/24 subnet. If one configures "split horizon" DNS service for only 0.168.192.in-addr.arpa., then any future expansion to using additional subnets will result in DNS lookups that will leak across one's borders.

  Conversely, configuring one's "split horizon" DNS service for 168.192.in-addr.arpa. will allow easy expansion in the future without having to touch up one's DNS service configuration at the same time.

• It's, ironically, harder to maintain than doing things the right way is. It's actually easier to just cover the whole of 168.192.in-addr.arpa. in one fell swoop than it is to calculate which particular X.168.192.in-addr.arpa. subdomain is actually the appropriate one, both initially and whenever new subnets are added.

Always use the most general reverse lookup domain name for the IP address range that you are using, even if right now you aren't using the whole of the address range.

Note: The use of 0.0.127.in-addr.arpa. instead of 127.in-addr.arpa. is a classic, and commonly found, example of this mistake in action. Even though one might only be using 127.0.0.1/32, or even 127.0.0.0/24, right now, that doesn't preclude the use of other 127.0.0.0/8 addresses in the future. RFC 3330 reserves the whole of the address range for loopback. Several operating systems do by default route all of those IP addresses via loopback.

Where you are already doing this

Possibly unbeknownst to you, you are almost certainly already employing "split horizon" DNS service for a few of these IP addresses.

This is because RFC 1912 § 4.1 makes a similar recommendation to this answer, albeit that it does not explicitly articulate the general case recommendation (as this answer does) and does not actually list the correct IP address ranges. It recommends employing "split horizon" DNS service for:

• 0.0.0.0/8,
• 127.0.0.0/24, and
• 255.0.0.0/8.

(Note that the latter two address ranges are not correct as per RFC 3330. They should instead be those given in the table here in this Frequently Given Answer.)

Most resolving proxy DNS server softwares follow the RFC 1912 § 4.1 recommendation, approximately, either by being factory-configured to perform "split horizon" DNS service for the relevant portions of the DNS namespace or by handling those relevant portions of the DNS namespace as special cases internally:

• ISC's BIND version 8.4 comes factory-configured with a named.conf configuration file that creates "split horizon" DNS service for 0.0.127.in-addr.arpa. and 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. and with separate factory-supplied data files comprising the private DNS database content for these "zones".

• Microsoft's DNS server, as described in Microsoft KnowledgeBase article #198410, handles 0.in-addr.arpa., 127.in-addr.arpa., and 255.in-addr.arpa. specially. (Note that Microsoft's DNS server thus corrects one, but not both, of the errors in the RFC 1912 § 4.1 recommendation.) Every time that the DNS Server service is started, it automatically creates and populates these "zones" with hardwired values.

• dnscache in Dan Bernstein's djbdns handles 1.0.0.127.in-addr.arpa as a special case internally, supplying hardwired values without separate data files holding DNS database content.

• dnsrcpd and dnsfcpd in The Internet Utilities handle 1.0.0.127.in-addr.arpa, 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa., 0.0.0.0.in-addr.arpa, and 255.255.255.255.in-addr.arpa as special cases internally, supplying hardwired values without separate data files holding DNS database content, when they are invoked with the /LOCALHOST+, /IMPLICITALL0+, and /IMPLICITALL1+ command-line options. (They can instead, if those command-line options are unset, be explicitly configured to direct all queries for those "zones" to a content DNS server such as dnsdsd.)

The resolving proxy DNS servers thus intercept the reverse DNS lookups for the various different IP address ranges, and prevent those lookups from leaking out beyond your proxy DNS services.

What is happening with Dynamic DNS

Without "split horizon" DNS in place for the relevant reverse lookup domain names, the DNS lookups for your non-public IP addresses leak across your borders. In the (distributed) public DNS database, all of these reverse lookup domain names are delegated to the same two public content DNS servers, at 192.175.48.6 and 192.175.48.42. (In theory, no data for these reverse lookup domain names exist in the public DNS database, and the "external" view of the "split horizon" DNS service is thus empty. In practice, many people don't configure their "split horizon" DNS service to cover all of the appropriate domain names, and lookups leak across their borders to the public content DNS servers. These two special-purpose content DNS servers, and the delegations pointing to them, were created to take the load of handling all of these leaked lookups off the "." content DNS servers.)

Your DHCP clients/servers comprise Dynamic DNS update clients, which attempt to update the DNS database with address-to-name mapping information as leases are granted and revoked. Dynamic DNS update clients attempt to automatically determine, in the absence of their having been explicitly told, what content DNS server to send their update requests to. They do this by looking up what is published in the DNS database. They perform a series of SOA resource record lookups, starting with the domain name whose DNS data they wish to update and proceeding to progressively shorter domain names until a non-empty SOA resource record set is found; and then perform a name-to-address lookup on the name, in the MNAME field of the SOA resource record thus located, to find the addresses on which the relevant content DNS servers are listening for Dynamic DNS update requests. They then send their Dynamic DNS update requests to those addresses. If they are using Secure Dynamic DNS update, then depending from the actual client authentication mechanism in use, they may also attempt to negotiate a shared secret with those addresses.

Without the proper "split horizon" DNS service in place, these SOA lookups reach those two public content DNS servers at 192.175.48.6 and 192.175.48.42. These publish that the relevant content DNS server to send updates to, for all of the non-public IP address reverse lookup domains, is prisoner.iana.org., which domain name maps to 192.175.48.1.

[C:\]dnsqry /serverip:192.175.48.6 soa 10.in-addr.arpa. | grep /b/u Answer:
Answer: 10.in-addr.arpa. IN SOA 604800 2002040800 1800 900 604800 604800 prisoner.iana.org. hostmaster.root-servers.org.

[C:\]

Thus your Dynamic DNS clients, attempting to register information in the DNS database about IP addresses in the non-public IP address ranges that you are using, end up attempting to negotiate shared secrets with, and attempting Dynamic DNS update transactions with, 192.175.48.1. (It supports neither service, of course.)

With the proper "split horizon" DNS service in place, these SOA lookups reach your private content DNS servers, serving up your private DNS database content comprising your "internal" view of the reverse lookup DNS namespace. Your private content DNS servers list one or more of their number as the relevant place to send updates to. And your Dynamic DNS clients thus end up negotiating shared secrets with and performing Dynamic DNS update transactions with your private content DNS server(s), without troubling your dial-on-demand connection, your firewall, or your cat.