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

When you are using this non-public IP address range Ensure that your "split horizon" DNS service provides an "internal" view of the DNS namespace from these points on downwards

Unspecified addresses

::/128
  • 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.0.ip6.arpa.
0.0.0.0/8
  • 0.in-addr.arpa.

Host-local loopback addresses

::1/128
  • 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.
127.0.0.0/8
  • 127.in-addr.arpa.

Link-local addresses

FE80::/10
  • 8.E.F.ip6.arpa.
  • 9.E.F.ip6.arpa.
  • A.E.F.ip6.arpa.
  • B.E.F.ip6.arpa.
169.254.0.0/16
  • 254.169.in-addr.arpa.

Site-local addresses

FEC0::/10
  • C.E.F.ip6.arpa.
  • D.E.F.ip6.arpa.
  • E.E.F.ip6.arpa.
  • F.E.F.ip6.arpa.
10.0.0.0/8
  • 10.in-addr.arpa.
172.16.0.0/12
  • 16.172.in-addr.arpa.
  • 17.172.in-addr.arpa.
  • 18.172.in-addr.arpa.
  • 19.172.in-addr.arpa.
  • 20.172.in-addr.arpa.
  • 21.172.in-addr.arpa.
  • 22.172.in-addr.arpa.
  • 23.172.in-addr.arpa.
  • 24.172.in-addr.arpa.
  • 25.172.in-addr.arpa.
  • 26.172.in-addr.arpa.
  • 27.172.in-addr.arpa.
  • 28.172.in-addr.arpa.
  • 29.172.in-addr.arpa.
  • 20.172.in-addr.arpa.
  • 31.172.in-addr.arpa.
192.168.0.0/16
  • 168.192.in-addr.arpa.

Locally-assigned local addresses

FD00::/8
  • D.F.ip6.arpa.

Test networks and special broadcast addresses

192.0.2.0/24
  • 2.0.192.in-addr.arpa.
255.255.255.255/32
  • 255.255.255.255.in-addr.arpa.

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:

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:

(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:

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.


© Copyright 2004–2004 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.