This page's shorter URL is

Providing "split horizon" DNS service.

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

How do I provide "split horizon" DNS service, so that all of the DNS client applications within my organisation see a full range of internal domain names and IP addresses but everyone outside of my organisation sees a limited, and possibly different, set?

This is the Frequently Given Answer to that question.

There are three ways of providing "split horizon" DNS service:

Two separate content DNS servers

This is the traditional scheme for providing "split horizon" DNS service, that is briefly described in Daniel J. Bernstein's FAQ document in Felix von Leitner's FAQ document and in Wayne Marshall's tutorial. It is employed where there are reasons (almost always non-technical ones) that one cannot use content DNS server software capable of having a single server that allows database records to be tagged; or where the other softwares on the machine are so insecure that it is impossible to guarantee that the only way that an external attacker can access the DNS database is by querying the content DNS server, and thus it is impossible to guarantee the confidentiality of those data that one does not wish the rest of Internet to see.

You simply:

All of the resolving proxy DNS servers owned by everyone else on Internet follow the delegations that are published in the public DNS database, and end up querying your "external" content DNS server. Your organisation's own resolving proxy DNS server obeys the override, and ends up querying the "internal" content DNS server. As a consequence, what DNS clients in your organisation, using your organisation's resolving proxy DNS server, see is different to what everyone else on Internet, using their own resolving proxy DNS servers, see.

Everyone within your organisation, whom you intend to see the "internal" view of your domain, must of course configure their DNS client libraries to use your resolving proxy DNS server. Any forwarding proxy DNS servers within your organisation must also forward queries to your resolving proxy DNS server. (This is usually going to be the case anyway, however.)

Furthermore, you must deal with replicating common data between the databases of the two content DNS servers. How you do this varies from case to case, because it depends greatly from exactly how the "internal" and "external" views of your part of the DNS namespace differ.

One of the simplest scenarios is where the "external" view is a strict subset of the "internal" view, and all that you are doing is hiding extra "internal" stuff from the outside world. In this scenario, it is wisest to make the "internal" content DNS server's database the "master", to which all modifications are applied, and the "external" content DNS server's database the "slave". You then set up your database replication, from the "master" to the "slave", so that it employs a filter, that strips off all of the data that are not intended for external consumption.

In the case of tinydns and axfrdns from Daniel J. Bernstein's djbdns, this is achieved relatively simply, by running awk over the master's data file, stripping out the unnecessary records, in order to turn it into the slave's data file.

Because of the various syntactic quirks of BIND's database source file format, including the omission and abbreviation of owner names being permitted, it is far more difficult to filter BIND's database source files using ordinary text file processing tools such as awk.

Moreover, that simple scenario is often insufficient anyway. For example, you may wish to have DNS clients within your organisation map domain names to internal IP addresses, whilst all other DNS clients on the rest of Internet map domain names to external IP addresses. (This is a common requirement where one is employing IP masquerading, or where one wants to - say - have two different HTTP servers by the same name, one for public access and one for access within one's organisation.) Database replication becomes a lot more complex in such a scenario, and one usually ends up building both servers' databases from a third source, tagging records in that source so that they can be filtered in one way to generate the "internal" database and in another way to generate the "external" database. However, once you find yourself in this position, it is a very short step to stop having separate content DNS servers altogether and instead have a single content DNS server and tagged database records.

Multiple databases in one content DNS server

BIND version 9 supports a concept which its authors named views. The server employs multiple DNS databases, with each view having its own. Clients querying the server are categorised by the server, according to their IP address, into a particular view, and that view's database and other configuration information are used to generate the answer in the response that is sent to the client.

This can be used to implement "split horizon" DNS. You set up a single content DNS server, listening on the IP address listed in the public DNS database as your domains' content DNS server, and tell it to have two views, one for "internal" clients and one for "external" clients. In the database for the "internal" view you place the data that you wish those within your organisation to see; and in the database for the "external" view you place the data that you wish the rest of Internet to see.

Whilst this scheme has the advantage over having separate "internal" and "external" content DNS servers that it does not require that you tell your resolving proxy DNS server to vary from the standard process of query resolution, by overriding the delegations in the public DNS database; it shares with that scheme the disadvantage that you still have to create two distinct database source files somehow. Even though there is a single content DNS server, rather than two separate ones, there still have to be two separate databases, which you have to ensure remain in agreement with each other by hand. BIND provides no means for generating two database source files from a single central master copy, allowing one to be able to make modifications to records common to the two databases in one central place. And because of the syntactic quirks in BIND's database source file format, this is comparatively very difficult and cumbersome to achieve with ordinary text file processing tools such as awk.

And, of course, since the record already shows BIND version 9 to be seemingly prone to containing security vulnerabilities just as BIND version 8 is, and so may well have vulnerabilities that provide attackers with the means to access everything that the BIND server process itself can access, as BIND version 8 does, this scheme cannot guarantee the confidentiality of the "internal" database.

Tagged database records

Until at least 2002-07-19, this scheme was not described in any FAQ documents, although it had been mentioned quite frequently in various discussion fora for quite a while. It was first described on this page, and later, in 2003, Wayne Marshall created an addendum to his tutorial that described it.

It became feasible with the advent of content DNS server softwares that allow their database records to be tagged, specifying their visibility to different clients. No version of BIND supports such tagging.

This scheme has several advantages over the other two schemes:

You simply set up a single content DNS server, listening on the IP address listed in the public DNS database as your domains' content DNS server. You tag the records in that server's database so that they are in one of three groups:

In version 1.04 or later of Daniel J. Bernstein's djbdns, one does this using the client differentiation capabilities of tinydns. For example:

DNS client libraries do not talk directly to content DNS servers. The only client IP addresses that need concern your content DNS server are the IP addresses used by your organisation's resolving proxy DNS servers when they send back-end queries to content DNS servers. DNS client libraries will query your organisation's proxy DNS servers, expecting them to perform the task of query resolution. The DNS query datagrams that your content DNS server will actually see will come from your resolving proxy DNS servers, as they perform that query resolution on the clients' behalf. Those are the IP addresses that you must use when tagging your database records.

If one's domains have multiple content DNS servers, employing this scheme rules out using the "zone transfer" DNS database replication mechanism for replicating the DNS database across those servers, because the "zone transfer" mechanism is quite simply incapable of transferring the record tagging information. It expects one particular, fixed, DNS database schema, which does not include fields such as client visibility record tags.

© Copyright 2002–2003 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.