Notice that dns2.foo.example.com is 192.0.2.1, your own nameserver. You are acting as a slave for the foo.example.com zone and must configure named accordingly. You introduce the zone as a slave in named.conf and specify the address of the master nameserver:
----------
| zone "foo.example.com" {
| type slave;
| file "foo.example.com";
| masters {
| 192.0.2.96;
| };
| };
----------
Similarly, your friend must configure 192.0.2.96, which is a master for foo.example.com and a slave for example.com. She must also configure her server to accept mail addressed to example.com. Usually, mx2 would just queue the mail until it could be delivered to mx1.
Reverse Zone
Take a moment to pretend that we live in a perfect world: Your highly competent ISP has successfully delegated authority of your reverse zone to you, and you must set up named to handle reverse resolution, too. This process is very similar to what you used to set up the reverse zone for 0.0.127.in-addr.arpa. Now, however, you must determine your zone's name.
DNS can delegate authority only at the . in domain names; as a result, you can set up reverse zones for the whole of a class A, B, or C network because they are divided at octet boundaries in the IP address. This approach is clearly unsuitable for classless subnets such as yours because the divisions are not at octet boundaries, but in the middle of an octet. In other words, your network cannot be described as x.* (Class A), x.y.* (Class B), or x.y.z.* (Class C). The latter comes closest, but includes several addresses (such as 192.0.2.22) that do not belong to the tiny 192.0.2.0/29 network. To set up a reverse zone for your network, you must resort to the use of classless delegation (described in RFC 2317).
The ISP, which is authoritative for the 2.0.192.in-addr.arpa zone, must either maintain your reverse zone for you or add the following records into its zone file:
----------
| 1 CNAME 1.1-6
| 2 CNAME 2.1-6
| 3 CNAME 3.1-6
| 4 CNAME 4.1-6
| 5 CNAME 5.1-6
| 6 CNAME 6.1-6
|
| 1-6 NS 192.0.2.1
| 1-6 NS 192.0.2.96
----------
The first CNAME record says that 1.2.0.192.in-addr.arpa is an alias for 1.1-6.2.0.192._in-addr.arpa. (The others are similar. There are no CNAME records for network and broadcast addresses 0 and 7 because they do not need to resolve.) Resolvers already know how to follow CNAME aliases while resolving names. When they ask about the 1-6 domains, they find the NS records defined previously and continue with their query by asking the nameserver about 1.1-6.2.0.192.in-addr.arpa.
So you must set up a zone file for 1-6.2.0.192.in-addr.arpa. Apart from the peculiar name, this zone file is similar in every respect to the reverse zone set up earlier, and should contain six PTR records (apart from the SOA and NS records). Note that you make 192.0.2.96 (ns2) a slave for the reverse zone, too, so the administrator must add a suit able zone statement to named.conf for it.
Be aware that in the real world you might have to wait for months for your ISP to get the reverse delegation right, and your reverse zone remains broken until then.
Registering the Domain
You now have a working DNS setup, but external resolvers cannot see it because there is no chain of delegations from the root nameservers to yours. You need to create this chain by registering the domain; that is, by paying the appropriate registration fees to an authority known as a registrar, which then delegates authority over the chosen zone to your nameservers.
Nothing is magical about what a registrar does. It has authority over a certain portion of the DNS database (say, the com. top-level domain [TLD]), and, for a fee, it delegates authority over a subdomain (example.com) to you. This delegation is accomplished by the same mechanisms that were explained earlier in the delegation of foo.example.com.
The site http://www.iana.org/domain-names.htm contains a list of all the TLDs and the corresponding registrars (of which there are now several). The procedure and fees for registering a domain vary wildly between them. Visit the website of the registrar in question and follow the procedures outlined there. After wading through the required amounts of red tape, your domain should be visible to the rest of the world.
Congratulations! Your job as a DNS administrator has just begun.
Troubleshooting DNS
Several sources offer good information about finding and fixing DNS errors. The DNSRD Tricks and Tips page at http://www.dns.net/dnsrd/trick.html and the comp.protocols.tcp-ip.domains FAQ (an HTML version is located at http://www.intac.com/~cdp/cptd-faq/) are good places to start. This section discusses some of the more common errors and their cures.
RFC 1912, "Common DNS Operational and Configuration Errors," discusses several of the most common DNS problems at length. It is available at http://www.intac.com/~cdp/cptd-faq/.
Delegation Problems
Your zone must be delegated to the nameservers authoritative for them, either by the root nameservers or the parents of the zone in question. Improper delegation can cause the name service for your domain to become dysfunctional, prevent some networks from using the name service, and numerous other problems. These problems typically occur only in the initial stages of setting up a domain when the delegations have not propagated widely yet.
If you experience such problems, you can use dig to follow delegation chains and find the point at which problems occur. A tool such as dnswalk might also be useful (see "Tools for Troubleshooting" later in this chapter).
Lame delegation is another common DNS delegation problem. Lame delegation occurs when a nameserver is listed as being authoritative for a zone, but in fact is not authoritative (it has not been configured to be a master for the zone); the nameserver in a lame delegation is called a lame server. Unfortunately, lame delegations are very common on the Internet. They can be the temporary result of domains being moved or (especially in the case of reverse zones) more permanent configuration errors that are never detected because of a lack of attention to detail.