Setting Up a Root Name Server

3.27.1 Problem

You want to set up your own root name server.

3.27.2 Solution

Create a data file for the root zone. The data file needs an SOA record for the root zone and NS records for all of your root name servers. For example:

$TTL 86400 . IN SOA ns1.corp.example. hostmaster.corp.example. ( 2002042600 1h 15m 30d 1h ) IN NS ns1.corp.example. IN NS ns2.corp.example.

You'll probably also need to add delegation to the zones at the "top" of your namespace. For example, if most of your internal domain names end in corp.example, you'd add NS records delegating corp.example to the right name servers:

corp.example. IN NS ns3.corp.example. corp.example. IN NS ns4.corp.example.

All of these name servers will require glue A records, too:

ns1.corp.example. IN A 10.0.0.1 ns2.corp.example. IN A 10.1.0.1 ns3.corp.example. IN A 10.2.0.1 ns4.corp.example. IN A 10.3.0.1

Don't forget to delegate the reverse-mapping zones that correspond to your networks:

10.in-addr.arpa. IN NS ns3.corp.example. 10.in-addr.arpa. IN NS ns4.corp.example.

Then add a new zone statement to the name server's named.conf file to tell it to load the root zone's data file:

zone "." { type master; file "db.root"; };

You can create slave root name servers, too, by adding a zone statement like this to their named.conf files:

zone "." { type slave; masters { 10.0.0.1; }; file "bak.root"; };

Finally, you should replace the root hints file on your non-root name servers with one that lists your new, internal roots:

. IN NS ns1.corp.example. IN NS ns2.corp.example. ns1.corp.example. IN A 10.0.0.1 ns2.corp.example. IN A 10.1.0.1

3.27.3 Discussion

Moving to a DNS architecture that uses internal root name servers is a big decision, with implications far beyond what I can cover here. For example, with an internal root architecture, you can't resolve Internet domain names. Make sure you know what you're doing.

3.27.4 See Also

"DNS and Internet Firewalls" in Chapter 11 of DNS and BIND.