Chapter 6. Delegation and Registration

Section 6.1. Introduction

Section 6.2. Delegating a Subdomain

Section 6.3. Delegating a Subdomain of a Reverse-Mapping Zone

Section 6.4. Delegating Reverse-Mapping for Networks with Non-Octet Masks

Section 6.5. Delegating Reverse-Mapping for Networks Smaller than a /24

Section 6.6. Checking Delegation

Section 6.7. Moving a Name Server

Section 6.8. Changing Your Zone's Name Servers

6.1 Introduction

As the administrator of one or more zones, you need to manage two kinds of delegation: from your zones' parent zones to your zone, and from your zones to their subdomains. Both are ongoing processes:

After registering a domain name (as in Section 1.6), you still must update the delegation any time the set of authoritative name servers changes. Recipes Section 6.7 and Section 6.8 describe ways of handling this as painlessly as possible.
After delegating a subdomain of your zone to a set of name servers, you must check the delegation periodically (Section 6.6) to make sure the delegation remains correct.

You also need to manage this delegation for two kinds of zones: forward- and reverse-mapping zones. Delegating reverse-mapping subdomains that correspond to a network or subnet involves more than you might expect. It's covered in Recipes Section 6.4 and Section 6.5.

6.2 Delegating a Subdomain

6.2.1 Problem

You want to delegate a subdomain of your zone to a set of name servers.

6.2.2 Solution

Add NS records to your zone's data file delegating the subdomain to the name servers. For example, to delegate the baz.bar.example subdomain to the name servers ns1.baz.bar.example and ns2.foo.example , you'd add these two NS records to the bar.example zone data file:

baz.bar.example.    IN    NS    ns1.baz.bar.example.
baz.bar.example.    IN    NS    ns2.foo.example.

In this example, you'll also need to add an A record for ns1.baz.bar.example , even though the name server's A record would normally appear in the baz.bar.example zone:

ns1.baz.bar.example.    IN    A    10.0.1.1

Without the A record -- called a glue record -- another name server that was referred to ns1.baz.bar.example would not be able to follow the referral, since in order to find ns1.baz.bar.example 's address, it would need to query ns1.baz.bar.example . That's like trying to find someone's telephone number by calling and asking.

6.2.3 Discussion

The simplest test for determining whether you need to include a name server's A record with delegation is to check whether the domain name of the name server ends in the domain name of the subdomain being delegated to it. If so, you need to include an A record for the name server.

The name servers that the subdomain is delegated to need a zone data file for the subdomain and a zone statement configuring them as authoritative for the zone. So, on ns1.baz.bar.example and ns2.foo.example , you'd expect to find a zone statement like this:

zone "baz.bar.example" {
    type master;
    file "db.baz.bar.example";
};

Of course, one of the name servers is probably a slave for baz.bar.example .

6.2.4 See Also

Recipes Section 1.16 and Section 1.17, for instructions on configuring a primary master and a slave name server for a zone, and "How to Become a Parent: Creating Subdomains" in Chapter 9 of DNS and BIND .

6.3 Delegating a Subdomain of a Reverse-Mapping Zone

6.3.1 Problem

You want to delegate a subdomain of your reverse-mapping zone to a set of name servers.

6.3.2 Solution

Just as with a forward-mapping zone, add NS records to your reverse-mapping zone's data file delegating the subdomain to the name servers. For example, to delegate the 1.168.192.in-addr.arpa subdomain to the name servers ns1.baz.bar.example and ns2.foo.example , you'd add these two NS records to the 168.192.in-addr.arpa zone data file:

1.168.192.in-addr.arpa.    IN    NS    ns1.baz.bar.example.
1.168.192.in-addr.arpa.    IN    NS    ns2.foo.example.

6.3.3 Discussion

There's very little difference between delegating a subdomain of a forward-mapping zone and a subdomain of a reverse-mapping zone: you add NS records to the parent zone, specifying the name of the subdomain and the domain names of the name servers. Some of the labels in the subdomain's name are the octets in an IP address, but the name server doesn't care about that.

The correspondence between octets and labels causes problems if you use network or subnet masks that don't break on an octet boundary -- you end up with either multiple zones per network or subnet or multiple networks per zone. For more, see Recipes Section 6.4 and Section 6.5.

Oh, there is one difference in delegating reverse-mapping zones: glue A records are rarely necessary in reverse-mapping zones, since most people don't give their name servers names like ns1.1.168.192.in-addr.arpa .