Re: DNS servers
On Fri, Nov 22, 2002 at 03:14:19AM -0200, Adriano Nagelschmidt Rodrigues wrote:
> > /etc/{passwd,group,shadow} have fixed formats, with fields separated
> > by colons. parsing them is as easy as splitting on : characters.
>
> This is also true for the tinydns data format, no? It just has more
> than one type of record, each with a fixed number of fields. That is,
> in addition, you have to look at the first character to know the type.
it's not also true. there are a variable number of fields per record,
and each record can be overloaded in meaning.
e.g. you can't find the A records for a given hostname just by searching
for the "=" lines, you also have to parse every other line in case an A
record is automagically defined elsewhere, e.g. in "&" or "." or "@"
lines.
this is fine for programs, but not for humans.
just because djb says it is human readable doesn't make it true.
the alleged documentation for tinydns-data is atrocious too, it's ALL
done by example, no syntax definition, no overview. examples are a
great thing to have but you need the definition as well. i'll bet that
someone, somewhere has created a useful "cheat-sheet" table of
definitions, but it doesn't look like it's anywhere on djb's site or in
his documentation.
another thing that is bizarre and broken about tinydns-data is that
entirely separate zones are configured in the one file - e.g. even
though .in-addr.arpa zones have an entirely arbitrary relationship to
other zones (and may not even be delegated to the same server), the PTR
record is automagically created when you create the A record (and
vice-versa)....and then, get this, it really takes the cake, either or
both of the A & PTR records are completely ignored unless there are
appropriately corresponding NS records somewhere in the file.
that is simply bad design. there are lots of things that djb is a
genuine genius at designing and implementing, but config file formats
are not one of them. IMO, he would be a much better programmer if he
acknowledged his weaknesses (and did something about them) as well as
just crowing about his strengths....and if his devotees did the same.
btw, this whole thread would have been a lot shorter if it was possible
for djb's disciples to acknowledge that occasionaly even divinity can
make a mistake or get something wrong or be slightly less than 100%
perfect.
> > tinydns has a variable number of fields per line, and uses "%" and "="
> > and "@" etc to indicate what type of data is being represented (which is
> > fine for programs, but certainly doesn't qualify as "human readable").
>
> The record chars may be considered mnemonic: @ for MX, = for A, PTR,
> etc ;-)
i'll agree that @ is mnemonic, and that = isn't too difficult to
remember. and there may be one or two more that could be construed as
mnemonic (e.g. C for CNAME, maybe ^ for PTR if you're a pascal
programmer). that leaves the remainder which aren't at all mnemonic.
e.g. %, &, Z, +, and ` are supposed to be "mnemonic"?
OTOH, bind zone files are mnemonic. A for A record, PTR for PTR record,
MX for MX record, SOA for SOA record and so on, exactly as defined in
the RFCs. bind zone files are far from perfect, but they're a lot
easier for a human to read and update than tinydns zonefiles.
> > they're not the same thing at all. not even superficially close.
>
> Same underlying UNIX philosophy.
only in the sense that text files are somehow involved.
aside from that, he's thrown every other concept of traditional unix
configuration out and replaced them with hard-coded directories, magic
filenames, and strict enforcement (as in "it wont work any other way and
you're a complete fool for even thinking about it") of djb's way of
doing things.
> > in any case, nobody pretends that passwd,group, or shadow files are
> > primarily designed to be edited by humans. they can be in an
> > emergency, but the primary method has always been to use programs
> > such as adduser, deluser, chfn, etc.
>
> Precisely. Why do you think this reasoning doesn't apply to DNS data?
because djb claims that it's human readable when it clearly isn't. if
he didn't make such claims, there would be a lot less to argue with.
it's optimised to be machine-readable. a human can parse it, but only
by examining the entire zonefile and remembering (or looking up) the
meaning of each symbol - some are mnemonic, but others are just
arbitrarily selected. furthermore, colon characters are far from the
best separator for human readability, white space works best for humans.
> You also get to choose the interface you want to use, be it a text
> editor, web cgi, the bundled tools or even a script that creates
> tinydns data from bind zone files (eg using DNS::ZoneParse from CPAN).
ditto for bind zone files. or any text file for that matter. it's not
a unique advantage for djbdns.
btw, while you mention DNS::ZoneParse - aren't bind zonefiles supposed
to be extremely difficult for a program to parse?
craig
--
craig sanders <cas@taz.net.au>
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch
Reply to: