Andrew Hudson - Fedora™ Unleashed, 2008 edition

You should now be able to resolve 1.0.0.127.in-addr.arpalocally (try dig @localhost 1.0.0.127.in-addr.arpa PTR +norec) and other names via recursive resolution. If you cannot accomplish this resolution, something is wrong, and you should read the "Troubleshooting DNS" section later in this chapter to diagnose and correct your problem before proceeding further. Remember to read the logs!

You can expand the minimal nameserver configuration you just created into one that performs useful name service for a real domain. Suppose that your ISP has assigned to you the IP addresses in the 192.0.2.0/29 range (which has six usable addresses: 192.0.2.1-6) and that you want to serve authoritative data for the domain example.com. A friend has agreed to configure her nameserver (192.0.2.96) to be a slave for the domain, as well as a backup mail server. In return, she wants the foo.example.com subdomain delegated to her own nameservers.

First, you must introduce the zone to named.conf:

----------

| zone "example.com" {

| type master;

| file "example.com";

| };

----------

and create the zone file:

----------

| $TTL 2D

| @ SOA ns1.example.com. hostmaster.example.com. (

| 2001090101 ; Serial

| 24h ; Refresh

| 2h ; Retry

| 3600000 ; Expire (1000h)

| 1h) ; Minimum TTL

| NS ns1.example.com.

| NS ns2.example.com.

| MX 5 mx1.example.com.

| MX 10 mx2.example.com.

| A 192.0.2.1

|

| ; Addresses

| ns1 A 192.0.2.1 ; Nameservers

| ns2 A 192.0.2.96

| mx1 A 192.0.2.2 ; Mail servers

| mx2 A 192.0.2.96

| www A 192.0.2.3 ; Web servers

| dev A 192.0.2.4

| work A 192.0.2.5 ; Workstations

| play A 192.0.2.6

|

| ; Delegations

| foo NS dns1.foo.example.com.

| foo NS dns2.foo.example.com.

| dns1.foo A 192.0.2.96

| dns2.foo A 192.0.2.1

----------

The SOArecord is similar to the one you saw before. Note that the next five records use the implicit name @, which is short for example.com.

The two NS records define ns1.example.com (your own server, 192.0.2.1) and ns2.example.com (your friend's server, 192.0.2.96) as authoritative nameservers for example.com.

The MX( Mail Exchanger ) records specify a mail server for the zone. An MXRR takes two arguments: a priority number and the name of a host. In delivering mail addressed to example.com, the listed MXes are tried in increasing order of priority. In this case, mx1.example.com(your own machine, 192.0.2.2) has the lowest priority and is always tried first. If the attempt to deliver mail to mx1fails for some reason, the next listed MX, mx2.example.com(your friend's server), is tried.

The Arecord says that the address of example.com is 192.0.2.1, and the next few lines specify addresses for other hosts in the zone: your nameservers ns1and ns2, mail servers mx1and mx2, two web servers, and two workstations.

Next you add NS records to delegate authority over the foo.example.comdomain to dns1and dns2.foo.example.com. The Arecords for dns1and dns2are known as glue records, and they enable resolvers to find the address of the authoritative nameservers so that they can continue the query. (If you were using dig, the NSrecords for dns1and dns2would be listed in the AUTHORITYsection of the response, whereas the ADDITIONALsection would contain their addresses.)

Notice that dns2.foo.example.comis 192.0.2.1, your own nameserver. You are acting as a slave for the foo.example.comzone and must configure namedaccordingly. You introduce the zone as a slave in named.confand 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.comand a slave for example.com. She must also configure her server to accept mail addressed to example.com. Usually, mx2would just queue the mail until it could be delivered to mx1.

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 namedto 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/29network. 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.arpazone, 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 CNAMErecord says that 1.2.0.192.in-addr.arpais 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 CNAMEaliases while resolving names. When they ask about the 1-6domains, they find the NSrecords 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 PTRrecords (apart from the SOAand NSrecords). 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.conffor it.