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

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 http://www.example.com./ or talk to my SMTP Submission server at mail.example.com.. 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 www.example.com. and mail.example.com. 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

• your Internet domain is "hosted" by a domain hosting company, not by you; and
• you are using Microsoft's DNS server and your Active Directory domain name is the same as your Internet domain name

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 whatever.example.com. 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 http://www.example.com./ 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

• mapping www.example.com. to the (chosen) IP address that your content HTTP server is listening on;
• mapping mail.example.com. to the (chosen) IP address that your SMTP Submission server is listening on; and
• providing any other mappings for any other servers that you have.

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

• If you are using Daniel J. Bernstein's djbdns, simply run the following commands:

  cd /service/tinydns/root
  ./add-alias www.example.com. 10.0.80.1
  ./add-alias mail.example.com. 10.5.87.1
  make
  

• If you are using Microsoft's DNS server, add "host" records in the documented manner to the example.com. "zone". The "Name" fields in the dialogue boxes must, of course, be www and mail.

• If you are using ISC's BIND, do the following:

  1. Edit the "zone" file for example.com., whatever you have chosen that to be, and add the line

     www IN A 86400 10.0.80.1
     mail IN A 86400 10.5.87.1
     

  2. Increment the serial number in the SOA resource record.
  3. Tell BIND to re-load the "zone" using

     rndc reload example.com
     

  4. Check BIND's log to see that the "zone" loaded successfully.

• For other content DNS server softwares, consult the documentation.

Second method: Having your "internal" content DNS server delegate each whatever.example.com. 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 www.example.com. to the IP address of your "external" content DNS server.

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

• If you are using Daniel J. Bernstein's djbdns, simply run the following commands:

  cd /service/tinydns/root
  ./add-childns www.example.com. 193.0.0.236
  ./add-childns www.example.com. 192.0.34.43
  make
  

• If you are using Microsoft's DNS server, add a delegation in the documented manner to the example.com. "zone" for the subdomain www.example.com., listing the IP address of your "external" content DNS server as the IP address that is being delegated to.

• If you are using ISC's BIND, do the following:

  1. Edit the "zone" file for example.com., whatever you have chosen that to be, and add the lines

     www IN NS 86400 a.ns.www
     www IN NS 86400 b.ns.www
     a.ns.www IN A 86400 193.0.0.236
     b.ns.www IN A 86400 192.0.34.43
     

     (The lack of trailing full stops is deliberate, note.)
  2. Increment the serial number in the SOA resource record.
  3. Tell BIND to re-load the "zone" using

     rndc reload example.com
     

  4. Check BIND's log to see that the "zone" loaded successfully.

• For other content DNS server softwares, consult the documentation.