Fedora™ Unleashed, 2008 edition

| 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.

CAUTION

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.

NOTE

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.

If your registrar's bills for your domain are not promptly paid, the registrar might discontinue the delegation of authority for your zone. If this happens (and the whois record for your domain usually mentions this), the best thing to do is quickly pay the registrar and ask for a renewal of the delegation. It is better not to let it happen, however, because such changes can take a relatively long time to make and propagate.

Reverse Lookup Problems

Reverse lookup problems are often hard to diagnose because they manifest themselves as failures in systems other than DNS. Many security-sensitive services perform reverse lookups on the originating host for all incoming connections and deny the connection if the query fails.

Even if reverse resolution succeeds, many servers might reject connections from your host if your A and PTR records do not match. That is, the PTR record for a particular IP address refers to a name and the A record for that name refers to a different IP address. They perform a double lookup to verify that the PTR and A records match to eliminate spoofing attacks. Carefully maintain your reverse zones at all times.

Delegation problems are a frequent source of woe. Unfortunately, many ISPs appear unable to understand, configure, or delegate reverse zones. In such cases, you often have little choice but to try and tell your ISP what to do to fix the problem. If the ISP staff refuses to listen, find a new ISP (or live with broken DNS).