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.

7.5 Setting Up a Stealth Slave Name Server

7.5.1 Problem

You want to set up a stealth slave name server, one that isn't queried by remote name servers.

7.5.2 Solution

Configure the name server as you would any other slave, but don't include it in the NS records for the zone (or zones) it's authoritative for.

7.5.3 Discussion

A stealth slave name server is a close cousin of a hidden primary master. Like a hidden primary, a stealth slave isn't included in the NS records for the zone it's authoritative for. Other than that, though, it has the same configuration as any other slave name server for that zone.

The function of a stealth slave name server may not be as obvious as that of a hidden primary. A hidden primary's benefit -- making it possible to manage a zone without the burden of serving queries for the zone -- doesn't apply to a stealth slave. So what's a stealth slave for ?

Sometimes, you need another authoritative name server for a zone to serve some group of resolvers. Say you need a name server on a particular subnet, to serve the local resolvers . All of the subnet's resolvers live in the same zone, so they'll probably generate lots of queries for domain names in that zone. Shouldn't their local name server be authoritative for the zone?

But what if you already have as many NS records for the zone as you can fit in a UDP-based DNS message (usually 10 or 11)? Or what if you don't want remote name servers to query the new slave, because the subnet it's on isn't well-connected to the rest of the network? Just don't list it in the zone's NS records: remote name servers won't follow delegation to it, but you can configure local resolvers to query it directly.

Since the slave isn't in the list of NS records for the zone, the zone's other authoritative name servers won't send it NOTIFY messages by default. You'll have to configure the stealth slave's master name server to send it NOTIFY messages; for instructions, see Section 3.13.