Providing DNS for a Real Domain

 < Day Day Up > 

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.

Forward Zone

First, we 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 SOA record is similar to the one you saw before. Note that the next five records all use the implicit name @, which is short for example.com.

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

The MX (Mail Exchanger) records each specify a mail server for the zone. An MX RR 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 (our own machine, 192.0.2.2) has the lowest priority and is always tried first. If the attempt to deliver mail to mx1 fails (for whatever reason), the next listed MX, mx2.example.com (our friend's server), is tried.

The A record 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: our nameservers ns1 and ns2, mail servers mx1 and mx2, two web servers, and two workstations.

Next, we add NS records to delegate authority over the foo.example.com domain to dns1 and dns2.foo.example.com. The A records for dns1 and dns2 are known as glue records, and they enable resolvers to find the address of the authoritative nameservers so that they can continue the query. (If we were using dig, the NS records for dns1 and dns2 would be listed in the AUTHORITY section of the response, whereas the ADDITIONAL section would contain their addresses.)

Notice that dns2.foo.example.com is 192.0.2.1, our own nameserver. We are acting as a slave for the foo.example.com zone and must configure named accordingly. We 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, our 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

Let us pretend that we live in a perfect world: Our highly competent ISP has successfully delegated authority of our reverse zone to us, and we must set up named to handle reverse resolution as well. 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 only delegate authority 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 ours because the divisions aren't at octet boundaries, but in the middle of an octet. In other words, our 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 don't belong to our tiny 192.0.2.0/29 network. To set up a reverse zone for our network, we 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. We don't have 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 domain, they find the NS records defined previously and continue with their query by asking our nameserver about 1.1-6.2.0.192.in-addr.arpa.

So, we 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 we set up earlier, and should contain six PTR records (apart from the SOA and NS records). Note that we make 192.0.2.96 (ns2) a slave for the reverse zone as well, so the administrator must add a suitable 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 will remain 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, who 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. 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 our 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.

     < Day Day Up > 


    Red Hat Fedora 4 Unleashed
    Red Hat Fedora 4 Unleashed
    ISBN: 0672327929
    EAN: 2147483647
    Year: 2006
    Pages: 361

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net