You've forgotten to populate your "internal" DNS database with data.

You've come to this page because you've asked a question similar to the following:
I've just set up "split horizon" DNS service and now no-one who sees my "internal" view of the DNS namespace is able to access my web site at or talk to my SMTP Submission server at Why not ? And how do I make them able to ?

This is the Frequently Given Answer to such questions.

What is happening

It's very simple. You've created "split horizon" DNS service but you've forgotten to actually populate the "internal" DNS database with some data.

Because the domain names and only exist in the "external" DNS database, everyone who uses the "internal" DNS database is told that there is no such domain name.

You may not think that you have created "split horizon" DNS service. However, if

then you have, entirely unawares, effectively set up "split horizon" DNS service with separate content servers.

The corrective action to take

There are two ways to enable access to your servers. Which one you choose depends from whether your service servers are "dual-homed", listening on an IP address on your local LAN as well as on an IP address reachable by the rest of Internet.

First method: Explicitly adding the mappings, from to an IP address, to your "internal" DNS database

This is the preferred method. One reason to prefer it is that if you have "dual-homed" servers it allows the rest of Internet to use those servers' "external" IP addresses whilst having your machines use those servers' "internal" IP address.

(If your content HTTP server supports virtual hosting according to client IP address, you can even get flash and have the rest of Internet see your public web site at whilst your own machines see an augmented, intranet, web site at the same URL. This is "split horizon" HTTP service.)

It's very simple: Add records to your "internal" DNS database

(If your various servers are listening on non-public IP addresses, and you are using NAT to map the services at a public IP address onto those non-public IP addresses, bear in mind that most NAT implementations do not implement loopback. Traffic cannot be routed from a service client on a non-public IP address, through NAT to the public IP address, and then back through NAT again to the non-public IP address on which your server is listening. You must, therefore, choose the IP addresses that your servers are actually listening on.)

How you add the records depends from your choice of content DNS server software:

Second method: Having your "internal" content DNS server delegate each to your "external" content DNS server

This method is useful if both your content DNS service and your other services (that you are attempting to provide names for) are actually provided by an outside hosting company, because it does not require that you update your "internal" DNS database every time that the outside hosting company moves its service servers to new IP addresses.

However, this method is not appropriate if you want to take advantage of a "dual-homed" service servers (in order to provide "split horizon" HTTP service, or merely in order to prevent traffic between your machines and your service servers from travelling over "external" wires).

It's very simple: Instruct your "internal" content DNS server to delegate the various domain names such as to the IP address of your "external" content DNS server.

How you add the delegation depends from your choice of content DNS server software:

© Copyright 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.