Re: Securing bind..
On Wed, Jan 02, 2002 at 03:23:01PM +0200, George Karaolides wrote:
> On Tue, 1 Jan 2002, Craig Sanders wrote:
> > someday soon, someone's going to take the good ideas from djbdns,
> > combine it with the good stuff from bind (including backwards
> > compatibility with bind config & zonefile formats), add a few useful new
> > ideas (e.g. an "RXFR" protocol that embedded the rsync protocol
> > directly) to produce a fast, secure DNS daemon, and release it with a
> > GPL-compatible license. this will blow both bind & djbdns out of the
> > water.
>
> Roll on the day! When such a godsend appears, I'll grab it with both
> hands, provided of course that besides reverse compatibility with BIND
> config. files, it also gives you a new, simpler config. scheme.
what's so difficult about bind's zone files or configuration files?
they're simple, straight-forward, and intuitively obvious to anyone with
a functioning brain. they're also extremely well-documented, with
numerous books available (_DNS & Bind_ published by ORA being the
"must-have" book for *any* DNS administrator)
> In the meantime, I submit that djbdns is OK unless you really, really
> want to stick to the BIND zonefile format,
or unless you need something more than what djbdns's simplistic
limitations can provide.
> though I seem to recall hearing it can be made to read BIND zone
> files. IMHO once you're used to it, the djbdns data file format is
> actually quite nice. I've worked on both BIND and djbdns and I find
> the latter easier to use.
> For example, the following ten entries
> would require four entries in named.conf and four zone files:
that would be because there's actually four different zones involved.
four zones == four config entries, four zone files....not one file and a
bunch of half-arsed assumptions.
> # Nameserver for my network addesses...
> [djbdns config example deleted]
>
> Surely that's not all bad?
yes. there's too much "magic" - i.e. fixed assumptions that may or may
not actually correspond to what you need.
in other words, if what you need is *exactly* what DJB in his infinite
wisdom has catered for then you'll have no problem. if you need
something even slightly different then you're screwed...and don't bother
complaining or asking to be accomodated because that's just evidence
that you're an idiot.
in other words, it works for the single scenario of one domain and one
set of IP addresses, with DNS for both hosted on the same server. fine
for a leafnode site...no use at all for an ISP.
i.e. djbdns is only a toy, and something that works fine at the toy end
of the scale doesn't necessarily work at all when you need to scale it
up to a professional system catering for hundreds or thousands of
domains.
> You don't have to worry about keeping A and PTR records in sync.
frankly, anyone who thinks that this is difficult should not be trusted
to have anything to do with managing DNS.
> I know there are management tools that automate synchronisation of
> forward and reverse mappings in BIND zone files, but why should the
> reverse-mapping information be in a file separate from the forward
> information? Once the three conditions above are met, why should we
> need to administer the forward and reverse mappings separately?
because :
a) the relationship between forward and reverse mapping(s) is completely
arbitrary,
and
b) the .in-addrp.arpa zone isn't always hosted on the same server as the
forward zone(s) - it isn't at all unusual for a NS which is
authoritative for a domain to NOT be authoritative for any corresponding
.in-addr.arpa domain(s).
leafnode sites may have simple configurations which suit djb's
assumptions but they're also the sites *least* likely to be
authoritative for the .in-addr.arpa zones for their IP addresses...most
leafnode sites don't own their own addresses, they rent or borrow them
from their ISP.
> For all the arguments against djb's attitude re. development and
> licensing, it must be acknowledged that his keeping tight control of
> the software has prevented it from suffering from feature bloat.
prevents it from suffering from features too.
even worse, it prevents anyone other than djb from fixing or enhancing
it.
> And since it's open-source
no, it is NOT open source. the source may be available but it doesn't
meet the criteria of the Open Source Definition, which requires that the
source code be freely modifiable and redistributable AND that binaries
compiled from modified sources be redistributable.
> and you can distribute patches to it, there's no shortage of patches
> to get it to do what you want.
the rest of the unix world got sick of hunting for obscure patches to
programs ages ago - hunt for the original source, then hunt for half a
dozen patches to fix various problems or add required features and hope
that the patches will actually apply cleanly without any conflict. that
was the way we had to do things back in the bad old days. it sucked
then, and it still sucks now.
OTOH, djb thinks otherwise...and only an idiot would dare to disagree
with him, right?
craig
--
craig sanders <cas@taz.net.au>
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch
Reply to: