Slashdot Mirror
Windows 2000 to provoke domain game
According to this article found on PC Week, Mircosoft Windows 2000 implements DDNS (Dynamic Domain Name System) in a way that makes it extremely difficult for administrators to
integrate the operating system upgrade with Unix systems, which use the older, static DNS. I would like to ask if someone here could explain what is the difference between Static DNS and Dynamic DNS, and why it's not implement almost at all unices, including Linux. I smell a fight here between Unix Admins and NT/2000 Admins in some corporates. Am I wrong?
This is my current project, so here is my take on what micros~1 is doing.
:-) At the end is an opinion, which is not a clue, but can be ignored or countered as you see fit.
/etc/hostname.
/etc/hostname in option 61 of the DHCPREQUEST, and get that code into every major package out there. Then the FUDders will not be able to do any more than superficial damage.
First, some background as to what Dynamic DNS truly is, because its obvious most of the slashdotters are posting without a clue. Here's a clue, and its free, as in free software
What is Dynamin DNS?
DynDNS is result of putting together several RFC documented techniques in a quite nifty way. Start with DNS [rfc1034 & 1035], add DHCP [1531, 1532, 1533, 1534] and tie the two together with Incremental Zone Transfers and Notify [rfc 1995 & 1996], and call it DynDNS [rfc 2136 & 2137].
Read rfcs 1995 & 1996 for a discussion on why full zone transfers [AXFR] are a bad thing (for bandwidth consumption), and see the elegant solution proposed with the incremental zone transfer [IXFR] extension. This is the basis for updating a primary name server with a new RR containing the hostname & IP pair (and IP->hostname reverse pair). You can also use this mechanism to remove a RR when the host is no longer associated with that address. There is also a discussion of security so that only pre-programmed IP addresses can do IXFRs, and allows extensions for fully authenticated updates when someone gets around to writing the code someday.
Read rfc 2132 to understand how a DHCP client does a DHCPREQUEST to a dhcp server, and how it can pass its hostname inside of option 61, client identifier. This is what win9x currently does with its client code, but only a patched version of some dhcp clients for linux do this.
Now, to put it all together.
A machine [win or linux] with a dhcp client boots up, broadcasts a bootp request (the transport mechanism for dhcp) with a DHCPDISCOVER message. A dhcp server on the network responds with its local address in a broadcast (because the client has no IP address at this point, all traffic must be broadcasts), and then the client broadcasts a DHCPREQUEST to that specific server. Contained in the REQUEST packet is option 61, containing the hostname of the machine. In win9x, this is what is entered in the network control panel "computer name" field, in *nix it the contents of
Then there is a whole bunch of communication between the dhcp server and client so they both agree on things (go read the rfcs, or sniff some packets off the wire, or both) with the end result the dhcp server now has given the client a lease on an IP address for a certain amount of time.
Now comes the DynDNS bit.
The dhcp server now communicates to the primary name server with an IXFR message, sending a RR containing an A record (and a PTR to the reverse DNS server) with the any and all information that might be contained in a RR, and the TTL is set to one half of the lease time given to the client. If the name and IP address are not currently in the DNS database, they are added. If they already exist, the IXFR message is refused, and the DHCP server must change the name to something unique. This is one mechanism to prevent overwriting your important servers addresses with bogus info.
What micros~1 is doing.
From what I can tell from some presentations I have seen, and playing with win2k beta, they have tied their DynDNS into ActiveDirectory as an attempt to shut out the *nix/OSS implementations until they get a foothold in the corporate door. I can't tell exactly what they are doing until I get a lab testbed set up and see if they interact correctly with BIND 8.2.1 or other rfc2136 compliant systems (someone mentioned cisco's registrar product, its real nice, and real expensive, and not based on any bind code). There is something going on with rfc 2052 defining directory servers on the internet, but I only read enough of it to give me a headache.
Static vs. Dynamic
M$ strategy is to put all IP addresses into AD, making the entire network a big, dynamic mess. As a network guy, I want all the important services to have static IP addresses. This means servers, DNS machines, router ports, mail servers, and anything else that should be stable.
M$ considers servers to be unstable (based on BSoDs and regular reboots), so they want the IP addresses to be dynamic. That's a bad way of thinking.
The article in ZD is actually correct on a lot of things. There are already battles going on between the ultra-reliable thinking *nix admins and the reboots-are-good ninnies who have realised they can't make M$s win2k work in a unix based world.
The only solution is for the OSS community to make a standard implementation of dhcp client, one that by default passes
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
DDNS is indeed implemented in the Unices - w/o a problem. The current version of Bind (8) supports DDNS and the development version of DHCP supports the DDNS updates.
The difference in the two (Dynamic/Static) is that, as everyone knows, static DNS requires you to know the IP address of the domain name you're recording. In DDNS, the client requests an IP address from a DHCP server, then, as long as the DHCP server is configured to 'know' the client, it recognizes which client is requesting the IP (based on MAC addressing) and informs the DNS server that it is giving a certain IP address to a client for a particular domain name, and the DNS server accepts the information and adjusts its lookup tables accordingly.
I've implemented this in Linux w/o a problem whatsoever - and I know of a school that has implemented it in a Solaris environment.
Its been out there for a LONG time, btw - by that I mean at least 3 yrs. It wasn't pretty, at times, 3 yrs ago - but it was there. Now, it is a very well integrated solution.
Its nice to be able to connect w/ a laptop anywhere on a 100+ subnet network and get the same domain name to resolve everytime :).
Btw - first? :-)
Brice