7.4 Setting Up a Hidden Primary Master Name Server

7.4.1 Problem

You want to run a primary master name server "hidden," so that other name servers don't query it.

7.4.2 Solution

Configure the slave name servers for your zones to use the primary master as their master name server, but don't list the primary master in the zones' NS records. For example, if ns1.foo.example, at 192.168.0.1, is the primary master name server for foo.example, you'd add zone statements like these to the slaves' named.conf files:

zone "foo.example" {
    type slave;
    masters { 192.168.0.1; };
    file "bak.foo.example";
};

But the NS records for foo.example wouldn't include ns1.foo.example:

foo.example.    IN    NS    ns2.foo.example.
foo.example.    IN    NS    ns.isp.net.

In addition, make sure the delegation information for foo.example does not include ns1.foo.example.

7.4.3 Discussion

"Hidden primary" configurations are often used to give the administrator of the primary master name server direct control over zone data without incurring any of the zone's query load. For example, a broadband Internet customer could run a local primary master name server on which to administer the zone, but leave his ISP's slaves to answer queries for data in the zone.

If you use Microsoft dynamic update clients, such as Windows 2000, be sure to list the real primary master name server in the MNAME field of the SOA records of dynamically updated zones. Microsoft dynamic update clients will send their updates to the name server designated in the MNAME field regardless of whether that name server also appears in the zone's NS records.

Clients with BIND-based update code will only send updates to name servers listed in a zone's NS records, so make sure your zones' slave name servers support update forwarding (that is, run BIND name servers from 9.1.0 on) and have update forwarding configured. See Recipe Section 3.12 for instructions on configuring update forwarding.

7.4.4 See Also

Section 3.12, for configuring update forwarding.