Slave Server Issues


In the setting where the dynamic zone does not really change that often and immediate propagation of changes is not critical, there is nothing to add to what has already been said about slave servers in Chapter 2.

In the case where the dynamic zone changes often and immediate updates of slave servers is important, I would like to remind you of, and reinforce, some things said in Chapter 2. When an update is received, the server will follow the usual procedure when a zone is updated: After a random waiting period (in the order of tens of seconds), a NOTIFY request is sent out to all the listed nameservers and any additional servers listed in named.conf. In this setting keeping the list of nameservers up to date and ensuring that they really receive NOTIFY requests becomes important. Combining NOTIFY requests with appropriate intervals in the SOA record will ensure that your slave servers are current and up-to-date;.

There is one more thing. As long as your dynamic zone is not right under a TLD (as is the case for dyn.penguin.bv) and is almost exclusively used internally, which will also often be the case, the need for a slave server might not be that great especially in small places. One server can handle large amounts of requests for the zone, so load will not be an issue. It is more an issue of reliability and redundancy, which might be less important in the dynamic zone, but more important in larger organizations.



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