Internal Rootservers


Internal Rootservers and the Internet

A thing you must consider is reserving the domain name you want to use with the appropriate Internet name authority. If you connect to the Internet or use it to exchange email or other documents, you and those with whom you communicate can use your reserved name in all contexts, eliminating any need to duct-tape together things with mismatched naming schemes. Reserving a domain is discussed in Chapter 4, "Getting a Domain."

Implementing internal rootservers is a good option if one of the following is true: Your organization is somewhat complex; you want to use several TLDs internally because your organization is international; you want to use several TLDs internally because your organization is made up of several divisions within a corporation that has separate domains; or replicating the zones around to all the DNS servers is impractical.

A Traditional Rootserver

While root nameservers are special, they are not that special. The root zone is just another zone; however, the rootservers you set up obviously do not need a root.hints file. Instead, they are masters and slaves for the root zone, so no hints are needed to find a rootserver.

The following is a (very basic) rootserver configuration:

 options {         directory "/var/named";         allow-recursion { none; };         notify yes; }; zone "." {         type master;         file "root.zone"; }; 

Note that if the rootservers are rootservers only, you probably should limit recursive queries to them so they aren't used as regular nameservers. Incorrectly configuring DNS clients to use your rootservers because it seems to work can cause you headaches later.

The following is the root.zone file:

 ; Internal root zone for Bouvet ; $TTL    1D ; @                       IN SOA  @ root.penguin.bv. (                                 2000022043      ; serial                                 24H             ; refresh                                 1H              ; retry                                 4W              ; expiry                                 1H )            ; min ttl                         NS      ns.penguin.bv.                         NS      nic.walruss.bv. penguin.bv.             NS      ns.penguin.bv.                         NS      ns2.penguin.bv. walruss.bv.             NS      nic.walruss.bv.                         NS      ns.penguin.bv. 0.1.10.in-addr.arpa.    NS      nic.walruss.bv.                         NS      ns.penguin.bv. 0.10.in-addr.arpa.      NS      ns.penguin.bv.                         NS      ns2.penguin.bv. ; Glue records ns.penguin.bv.          A       10.0.0.2 ns2.penguin.bv.         A       10.0.10.2 nic.walruss.bv.         A       10.1.0.2

Notice that no separate bv zone file exists, because it's unnecessary. Instead, you immediately can begin listing the nameservers you swant to define. The root zone is just like any other zone in that respect, too. The maintenance overhead is low as long as the nameservers don't change addresses or names. This last point is very important. An internal DNS with delegated subdomains will break if someone running the delegated domains changes a nameserver's address without telling the rootserver administrator. I can't emphasize enough that you always should be conservative when making a decision about DNS servers. Otherwise, things won't work properly.

Stub Zones Only

One other, untraditional, way exists to accomplish this. Depending on how many zones, changes, and rootservers you have, using a pseudo rootserver that only holds stub zones might be beneficial. This will add administration overhead in some circumstances, though, because using a root zone enters all the pertinent data in a zone that BIND can transfer. In addition, using stub zones moves the maintenance into the configuration file. Therefore, because BIND doesn't have a configuration distribution or update mechanism, you must roll your own transfer mechanism.

The following demonstrates how you can set this up:

 options {         directory "/var/named";         notify yes;         allow-recursion { none; }; }; zone "penguin.bv" {         type stub;         masters { 10.0.0.2; 10.1.0.2; } ;         file "stub/penguin.bv.zone"; }; zone "0.10.in-addr.arpa" {         type stub;         masters { 10.0.0.2; 10.1.0.2; };         file "stub/10.0.zone"; }; zone "walruss.bv" {         type stub;         masters { 10.1.0.2; 10.0.0.2; };         file "stub/walruss.bv.zone"; }; zone "0.1.10.in-addr.arpa" {         type stub;         masters { 10.1.0.2; 10.0.0.2; };         file "stub/10.0.1.zone"; }; 

The advantage of this approach is that you will have a working root nameserver as long as the masters are capable of answering the stub queries SOA and NS.

A Rootserver with Stub Zones

You can even accomplish this using a third method. And in some situations, this next method is the best method. If you combine a root zone with stub zones, you will not need any glue records. That's because in this method, when a zone transfer is performed, the server supplies the necessary glue records from the stub zones. In other words, the stub zone listing must occur only on the master rootserver. On the slave servers, they are unnecessary because when the root zone is transferred, it contains all the necessary data. An example follows:

 options {         directory "/var/named";         notify yes;         allow-recursion { any; }; }; zone "." {         type master;         file "root.zone"; }; zone "penguin.bv" {         type stub;         masters { 10.0.0.2; 10.1.0.2; } ;         file "stub/penguin.bv.zone"; }; zone "0.10.in-addr.arpa" {         type stub;         masters { 10.0.0.2; 10.1.0.2; };         file "stub/10.0.zone"; }; zone "walruss.bv" {         type stub;         masters { 10.1.0.2; 10.0.0.2; };         file "stub/walruss.bv.zone"; }; zone "0.1.10.in-addr.arpa" {         type stub;         masters { 10.1.0.2; 10.0.0.2; };         file "stub/10.0.1.zone"; }; 

The previous code ensures that the nameservers in the root zone always have updated A records. In addition, it doesn't require you to roll your own transfer mechanism for the config file.

It can still be argued, though, that the first version a root zone file only is simpler because any changes have to be made to only one file. On the other hand, the mixed approach requires only two files to be changed: the zone file and the configuration file. Either option will work; you just have to decide which one will work best for you.



The Concise Guide to DNS and BIND
The Concise Guide to DNS and BIND
ISBN: 0789722739
EAN: 2147483647
Year: 1999
Pages: 183

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