running w/ win2k as master and bind8 as slave (was win2k's dns)
John Hascall
john at iastate.edu
Tue Aug 31 18:03:53 UTC 1999
Jim Reid <jim at mpn.cp.philips.com> wrote:
}>>>>> "steve" == steve rader <rader at teak.wiscnet.net> writes:
} steve> Is there anything about win2k's use of dynmaic updates that
} steve> makes using a win2k primary and a BIND 8 slave Rude and/or
} steve> Evil?
Win2K's evil comes from its parentage not from DDNS.
We've been using DDNS since long before Win2K started oozing out.
}There are two parts to this answer. The first part is that Dynamic DNS
}is scary IMHO. There are serious security and scaling problems. The
}security problem can be summed up by asking "who/what do you trust to
}update the DNS?" and "can I be sure they don't tamper with Something
}Important like the zone's MX and NS records or the resource records
}for our mission critical web/whatever servers?".
Well, you answer your own question a little later: Step 1
is compartmentalize. (Step 0 is all the other general
security steps you should have already taken [protect
against IP spoofing, etc] before adding DDNS.)
} Secure Dynamic DNS
}just changes this problem: you use strong crypto to authenticate the
}thing making the update. But there's still no real control over what
}that update changes
How is that problem really different that there's no real change
control over what editting random.conf.file changes. Change
control is a more general management problem. If you're doing
a sloppy job pre-DDNS, you'll probably still do a sloppy-job
post-DDNS.
} and then you have the intractable problems of key
}management to grapple with.
Key management gets intractable when you have large numbers of
keys to manage. For small enough 'N' any problem is easy :)
We have 1 machine updating 8 DNS servers...small enough N.
} The scaling problem is that each update
}bumps the zone's serial number, causing another zone transfer. How
}often will the DNS be updated because systems get switched on or off
}or rebooted? One site in the net here is using Dynamic DNS and their
}local name server causes ~300 zone transfers a day to each of its
}off-site slave servers. Sigh.
Well, that bit *IS* a botch-and-a-half. What I did was modify
the nsupdate program/libraries to update ALL the NS's listed
not just the 1st one that succeeds. Voila', no need for NOTIFY,
no need for zone xfers. I also went to using time_t as the
serial# (instead of for example yymmddnn) when doing a full-gen
of the nameserver files from the management DB (typically once
a night for 'sanity'). Thus, as long as we have less than
86400 ddns updates/day we are OK (we had 427 yesterday, and a
peak of 3556 on the 19th).
}The second part of the answer concerns the software from Redmond. As a
}general rule, this seems to do weird and wonderful things unless it is
}very carefully set up. I would be very wary about letting the typical
}M$ desktop get write access to the DNS. Given their past history, this
}would be asking for trouble: who knows what a W2K box will want to
}stick in the DNS and how often will it want to do that? And will that
}be documented....?
Compartmentalize, compartmentalize, compartmentalize.
}Since W2K is inevitable and it relies on Dynamic DNS, this is going to
}a big problem. The least bad solution I've heard of is delegating a
}domain for these systems - say w2k.foo.com - and letting them scribble
}whatever they want there, well away from the "really important" stuff
}in foo.com. Hopefully this will at least contain the problem. If
}anyone has other ideas about how to make W2K and Dynamic DNS co-exist,
}I'd be glad to hear them.
Exactly, compartmentalize, compartmentalize, compartmentalize.
John
--
John Hascall, Software Engr, Acropolis Project Manager, ISU Computation Center
http://www.cc.iastate.edu/staff/systems/john/index.html <=- the usual crud
Shut up, be happy. The conveniences you demanded are now mandatory. Jello Biafra
More information about the bind-users
mailing list