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?
you are allowed to use parts of copyrighted material in review, critique, or parody. I'd say this prolly falls under review. Besides, zdnet i'm sure is happy everytime one of their articles gets posted to slashdot, more hits, more banners loaded, more ad money.
-matt
Correct me if I'm wrong, but hasn't BIND 8.x had this capability for some time? What is the difference in M$'s implementation? Are they "extending the specs" the way they did HTML?
---
Stephen L. Palmer
http://midearth.org
Just another BOFH.
Have you just noticed this fact? Most slashdot headlines are taken verbatim from the original article. This isn't unusual in itself, but custom and courtesy dictate that the name of the publication or service be placed before the headline. This is what Linux Today does.
I've finally had it: until slashdot gets article moderation, I am not coming back.
DHCP Distribution: Version 3.0
Current Version: 3.0b1pl0
Version 3 of the ISC DHCP Distribution adds conditional behaviour, address pools with access control, and client classing. An interim implementation of dynamic DNS updates for the server only is included, but is not supported. The README file contains information about how to enable this - it is not compiled into the DHCP server by default.
Features in upcoming releases, starting with 3.1, will include the final asynchronous Dynamic DNS Support, DHCPv4 16-bit option codes, asynchronous DNS query resolution, DHCP Authentication, and support for a DHCP Interserver Protocol and live querying and update of the DHCP database. I don't see why they say it doesn't exist on UNIX. There are also perl scripts that do the job.
I'm working with DDNS both at home and at work using both Unix (Proprietary or Linux) and Win2K. They interoperate fine.
The only issues I've seen are with IXFR implementations (incremental zone transfers) and some "noise" data for some subzones. The workaround is that you can delegate the "noise" zones back over to a Win2K box until the BIND 8.2.1 code is fixed.
The REAL PROBLEM as documented in the story about Boe...oh, the "large aerospace firm" is that many large enterprises segment their IT structure along operating system lines rather than functional lines. It is much more efficient to LOSE operating system religion and use the "appropriate tool" for a job.
The DNS folks where I'm consulting use both Solaris and Win2K systems as nameservers. Solaris hosts the root namespace and the IP management tools. Win2K hosts the Active Directory Integrated delegated zones. The same folks in THE NETWORK GROUP (a functional split not an OS-centric split) manage all of these zones. There is no pissing contest over OS machismo. If more companies were to split their IT into functional areas, rather than OS empires, they might see a better result.
I'll get off my soapbox now. Just my two cents.
This is very open to interpretation. Linux has more security issues, because the code is able for review by anyone.
Beside the fact that I disagree with you, perhaps the reason that NT has less "security issues" is because the code is not open for such review.
If the code was at least open for REVIEW (not development), at least a lot of unresolved bugs that are going to pop up sooner or later, and take big hits with them. At least if the code is there for review, an admin could take steps to prevent something from getting exploited, even if it doesn't actually FIX the problem.
I'm a full advocate for open source, but when security is an issue, the more you can see the better.
-Erik-
I think dynamic DNS is a solution in search of a
E XT=935866614.1926103089&hitnum=9
problem.
You say, "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."
Why?
How many people besides you regularly connect to
a server running on your laptop?
Are you sure you control the TTL on your DNS
server, every DNS server used by every client
that talks to you, and every server you talk to?
What do you do when a remote site's TCP wrappers
refuse access because they cached your old PTR
record?
What assurances do you have that someone can't
spoof your dynamic name and steal credentials? If
you think you're authenticated by MAC address,
try ifconfig eth0 hw de:ad:be:ef:01:23 (doesn't
work with all enet cards, but does with the common
ones). If you use kerberos, x509, or ssh host keys
and you actually bother to verify them, then you
have less of a problem, but many common services,
like unencrypted web pages, have no end-to-end
server verification protocol. Interestingly
enough, Microsoft's NT domain protocols do not
strongly authenticate the server to the client.
If an attacker puts himself at the server's IP
address and generates a nonrandom nonce, you lose.
Microsoft considered strongly authenticating
DDNS to be too hard (and nonexportable), so they
basically trust whatever you put in the Network
Control Panel (or a packet manufactured with
smblib) as long as the name has not already been
taken. Taken names can probably be freed up with
the same sort of games people play to take over
IRC channels. Bzzt! Game Over.
Microsoft says it plans to get rid of WINS, but
the initial implementation brings all the
instability and insecurity of WINS to DNS. No
thanks. The non-Microsoft solutions tend not to
be much better at this time.
Out-of-band authentication like MyIP or the old
ml.org web page works, but that ain't DDNS,
that's end-user access to static DNS... which
can be a good thing. We provide something similar
for our students.
In case deja URLs aren't permanent, search for "WINS" in comp.os.ms-wendows.networking.win95 during January 1996.
http://x22.deja.com/getdoc.xp?AN=135549278&CONT
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
If anyone is interested in actually reading them, the RFCs MS is SUPPOSED to be following with this are 2136 and 2052.
Also, no one I know who is testing this out (in the IT consulting firm who will be doing a great deal of this whem it spills out upon the world) is fooling themselves about what a GIANT political battle this could turn into. To avoid this, you will probably see Active Directory Domains handling their own DDNS, and forwarding to existing UNIX infrastructure for all other name resolution if those doing the implementation aren't up to the fight.
...how other systems in the network will resolve to systems in the DDNS zones is supposed to be worked out, (with the use of some crazy zone magic) but I've not seen it work yet.
"I don't think I ain't" -Thompson's Corollary to Descartes
I have a laptop (usually running Linux, occasionally running Win98) that gets its IP address via DHCP (from a Linux server at home, an NT server at work).
At home, because it's almost always the only DHCP client, my laptop always gets 192.168.0.10 (the beginning of my assigned DHCP range), so I can pretend it has a fixed IP address for local DNS purposes. At work, it gets a different IP address almost every day. WINS can resolve its name anyway; DNS can't because we don't have DDNS yet. MS supporting DDNS is good; my Solaris and Linux machines (which have clients for DNS but not WINS) would be able to look up my laptop by name, just like my Windows box (which has clients for both DNS and WINS).
Yes, MS might screw up DDNS, through malice or incompetence, and provide something only 99% compatible with the RFC. Recall the pump DHCP client included with Red Hat 6.0, which worked great with most Unix DHCP servers but not with NT's. But note that it was quickly patched to work with NT. Open-sourced clients can quickly deal with a bit of incompatibility, whether malicious or accidental.
The fact that MS supports a new open standard like DDNS before your favorite OS does is a reason to start working on an open DDNS client, not an excuse to bash MS. DDNS is good. NT becoming more standards-compliant is good. If at some point in the future MS starts changing their DDNS server around to deliberately cause problems with other people's clients, *then* bash MS, and suggest to your local sysadmin that he run DHCP and DNS from a cheap Linux/*BSD/whatever box instead of an NT server to maintain maximum compatibility with existing clients. But bashing MS in advance just for announcing the intent to support a good, new, open standard is counterproductive. Would you really prefer WINS?
-- David Ripton
With DDNS, the hostname is bound to a device and the IP changes. With static DNS, the IP is bound to a device and the name changes.
ayottesoftware.com
How is DDNS related to DHCP? I would think that the DHCP server implements DDNS... and I thought that clients and servers for DHCP were already available (for Linux). But I am not wise in the ways of Bind. Am I missing something?
"in a coperate envoiornment, this isn't an issue"
I agree with you completely, because this strengthens my theory about MS's server strategy.
DDNS may not be a compelling solution for a global, public network, but it sounds as though it's a very nice option for a local net, and that's where Microsoft is concentrating their efforts.
It is important to remember that the Winxx platform is not the logical center of Microsoft's empire. MS Office is. MS Office is the "killer app" which makes most businesses buy Wintel boxes on the desktop, and Windows on the desktop is why those same businesses buy NT servers. The presence of MS Office for the Mac was a significant factor in Apple's resurgence in sales.
Microsoft is leveraging this advantage very effectively, integrating Office with IIS, and with DDNS they are now making it even easier for any salesperson to connect their Windows laptop to connect to any open ethernet port in the office and start working immediately.
That, all by itself, is a good thing. What is not a good thing is for MS to specifcially design their ActiveDirectory so that it requires DDNS. Novell's NDS doesn't require DDNS, and from what I've seen ActiveDirectory does less than Novell's solution. I'm sure that the programmers behind W2K are very good at their jobs, so I must assume that the decision to make W2K DDNS dependant was a conscious choice. If MS publishes a white paper stating the reasons for this, I will read it, (and the soon-to-follow slashdot commentary) and make my mind up then.
PC Week deserves criticism for not doing their homework on this (no surprise there). To state that Unix does not offer this service, when it does, is terrible journanlism.
But then, any "news" article about Windows 2000 which is followed by a link titled
"Check prices: Windows 2000" isn't actually journalism at all, it's an infomercial.