How Dynamic Addressing Is Made Usable With DDNS
Today, most Domain Name System (DNS) servers must be updated manually to change allocated names and addresses. Since most DNS entries are not updated very often, this isn't a big deal. But it becomes a different story when you're trying to keep up with the constant updates that are incurred by linking Dynamic DNS (DDNS) names to Dynamic Host Configuration Protocol (DHCP)-leased addresses. If you also have slave DNS servers--servers that have cache
d their information for a set or lengthy period of time--they
most likely won't get the information when it's needed.
Enter IP management systems. Among the products we tested in Network Computing's lab at the University of Wisconsin, most solutions ran their own central DNS, DHCP and database servers. Since DNS server updates are cached, dynamic addresses were resolved immediately. On the downside, since serial numbers have not been changed, secondary DNS servers do not know to reread the configuration files. However, if you
combine these services with a periodic update of the zone file and serial number, your secondary DNS servers will be updated in a somewhat timely manner. This paradigm, however, is not true DDNS.
The Internet Engineering Task Force (IETF) has a new RFC outlining how DDNS should work. RFCs 1996 and 2136 propose a solution that will be implemented in the standard DNS server, BIND 8.1. Once BIND 8.1 becomes widely used, vendors will likely support the methods of updating BIND servers.
The DDNS strives to create an environment where DNS
can function without causing a tremendous load on the DNS servers. As an IP address changes, the DHCP server sends a message to the DDNS server stating the change. The DDNS server then sends this update to its dependent slave servers. Additionally, a very short cache time-out will enable DNS servers on the Internet to receive changes, while still providing for all the features DNS offers.
|
RSS
