- Dynamic DNS
- Of Masters and Slaves
- Accepting and Doing Updates
- TSIG
- The Dynamic Zone
- The Client
- Update Prerequisites
- Update Actions
- Using nsupdate
- Slave Server Issues
- Reverse Zones
- A One Host Zone
- DHCP
- Mixing DNS and DHCP Implementations
- DHCP and Static DNS Entries
- DHCP and Dynamic DNS Entries
- Dynamic Updates by the Client
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 greatespecially 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.