This page's shorter URL is http://tinyurl.com./2ado.
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:
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:
run two separate content DNS servers
The first listens on an IP address that is reachable by the whole of Internet and listed in the public DNS database as being that of your domain's content DNS server. This server's database contains the DNS data that you wish to be published to the rest of Internet.
The second listens on an IP address that need only be reachable by your organisation's own resolving proxy DNS servers (which, if you have just the one resolving proxy DNS server, will usually be a loopback IP address on the same machine as that server). The only thing that needs know the IP address of this content DNS server is your organisation's resolving proxy DNS servers. No DNS client libraries need ever know directly of its existence, and it should not be listed in the public DNS database. This server's database contains the DNS data that you wish to be published to those within your organisation.
and
tell your organisation's resolving proxy DNS server to override the delegations that are published in the public DNS database for your particular domains, telling it to instead consult the second, internal, content DNS server that you have set up for its own private use.
With dnscache from Daniel J. Bernstein's djbdns, one does this by placing appropriately named files in the root/servers subdirectory containing the IP address of the replacement content DNS server.
With dnsrcpd from the Internet Utilities for OS/2, one does this by placing appropriately named files in the Content subdirectory, again containing the IP address of the replacement content DNS server.
With ISC's BIND, one does this by creating a "stub" "zone" for each domain, listing the IP address of the "internal" content DNS server in "named.conf" and reconfiguring that content DNS server to support the "zone transfer" DNS database replication mechanism.
With Microsoft's DNS server in Windows NT 2003 and later, one does this by creating a "stub" "zone" for each domain, listing the IP address of the "internal" content DNS server as the master and reconfiguring that content DNS server to support the "zone transfer" DNS database replication mechanism.
With Microsoft's DNS server prior to Windows NT 2003, there is no simple way to override delegations listed in the public DNS database, and one must resort to the clumsier mechanism of making the server a "stealth slave" for the appropriate "zones" (with the "internal" content DNS server as the master) and reconfiguring the content DNS server to support the "zone transfer" DNS database replication mechanism.
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.
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.
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:
Records in the first group are tagged so that they are only served up when the IP address of the client is one of the IP addresses that your organisation's own resolving proxy DNS servers use to send their back-end queries to content DNS servers. These records are the ones that are intended only to be visible to those within your organisation.
Records in the second group are tagged so that they are only served up when the IP address of the client is not one of the IP addresses that your organisation's own resolving proxy DNS servers use to send their back-end queries to content DNS servers. These records are the ones that are intended only to be visible to the resolving proxy DNS servers used by the rest of Internet.
Records in the third group are served up to everyone. These records are the ones intended to be seen by those within your organisation and the rest of Internet, and to appear exactly the same to both.
In version 1.04 or later of Daniel J. Bernstein's djbdns, one does this using the client differentiation capabilities of tinydns. For example:
Two mappings from a single domain name to two different IP addresses, one mapping to be visible to those within your organisation and the other mapping to be visible to the rest of Internet, would look similar to:
+www.example:10.0.0.2:::IN +www.example:192.0.34.72:::EX
Preventing SMTP Relay clients within your organisation from falling back to secondary SMTP Relay servers outside of your organisation, whilst allowing the rest of Internet to do so, would look similar to:
@example:62.253.164.70:a:10::: @example::a.mx.isp:20:::EX @example::b.mx.isp:20:::EX
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.