qmail (Was: Maintaining Access Control Lists )
and...@cream.org
Benjamin Krueger wrote:
>
> Barring that, network daemons that run out of inetd can use tcp wrappers (the
>/etc/hosts.allow system). This has a flexible system for configuring access to
>various daemons from the network, however has the unfortunate achilles heel of being
>entirely dependant on inetd to pick up traffic for it and spawn a new instance of
>the daemon to run it. I've heard reports of tcpserver of qmail fame doing the same
>thing, and even with some speed gains, but I'm not a big fan of the author or his works.
>hosts_options(5) for more information.
>
Benjamin,
I was interested about what you said about qmail and its author. I've
recently started playing with qmail to investigate what mail server I
prefer, but I agree that there is perhaps something a little strange
about its author. I don't know what, perhaps its just that I find
qmail.org such a weird site.
What's your take on the situation?
Andrew.
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
brad.k...@skynet.be
> I was interested about what you said about qmail and its author.
> I've recently started playing with qmail to investigate what mail
> server I prefer, but I agree that there is perhaps something a
> little strange about its author. I don't know what, perhaps its
> just that I find qmail.org such a weird site.
The author of qmail is rightly considered to be one of the most
whacked-out kooks on the 'net.
I've been on IETF mailing lists with him, and his attitude is
always that he is always right (by definition) and everyone else is
always wrong (by definition). He insists on replying to each and
every mail message posted to the list, and constantly dredging up old
points that everyone else has agreed were dead a long, long, long
time ago.
He will reply to messages that are not anywhere near remotely
related to his favourite topic, quote some random line that is least
unlike the straw-man position that he wants to destroy, and then go
off on a multi-page rant.
He considers himself to be God's gift to programming, security,
Internet mail, DNS, cryptography, and anything else he cares to
decide to screw around with, and woe betide anyone who ever disagrees
with his world-view -- even if that world-view changes and you used
to be his most vocal supporter.
The problem is that he is generally totally fscking clueless (at
least on all the topics with which I am familiar), and his
whacked-out ideas of how things should be done are non-solutions to
non-problems, and he simply doesn't understand what the real problems
are.
Let's take qmail as one example. Read the literature, and you
will find pretty universal agreement that the single biggest problem
with handling Internet e-mail is the issue of synchronous meta-data
updates, followed by synchronous data writes -- basically, you're
waiting on the disk, which is the single slowest device in the entire
system by many, many orders of magnitude, and the RFCs require you to
do things that mean that you can't really make much use of the kinds
of buffers and things you'd normally use to help insulate yourself
from such seriously heinous latency issues.
The problem is that every time you create a file, delete a file,
or rename a file, the entire directory in which that file is located
must be locked for the exclusive use of that one process, for the
length of that directory operation. Now, you may be able to handle
these operations very quickly, but when you serialize all directory
operations in a busy mail queue, this starts to become a serious
problem.
Compound this problem with the fact that you are required by the
RFCs to have committed the mail message to stable storage before you
respond to the sender "Okay, I've got it." You have to flush the
buffer for that file, and wait for the writes to complete before you
can proceed. You also have to flush the write buffer for the
directory before you can proceed (to ensure that the meta-data
updates are reliably written out).
Now, it turns out that older versions of sendmail make this
problem doubly worse by using two files in /var/spool/mqueue for
every mail message -- a qf* file and a df* file (with others being
optional). This means twice as many files get created, written,
read, and deleted in a very short period of time (with appropriate
flushes of the buffers and waiting for the message to be committed to
stable storage before continuing, etc...).
But qmail makes this even worse -- it uses *three* files per
message! At least postfix is more intelligent and it uses only one
file (albeit in a proprietary format).
Starting with version 8.12, sendmail has a new async I/O library
that allows it to avoid *ALL* synchronous meta-data updates in most
cases (i.e., those where the initial delivery attempt is successful).
It's kind of hard to beat zero synchronous meta-data updates. ;-)
More importantly, the author of postfix has relatively little ego
wrapped up in his programs, and if you can show him an error or an
incorrect assumption, he will generally listen to you.
Do you know why no one has never collected the "bug bounty" that
the author of qmail has offered? Simple -- he has never publicly
acknowledged that any of his programs are less than 100% completely
and totally perfect, and any time someone does point out something
that is wrong, while he doesn't recognize it as a "bug", the problem
does seem to mysteriously get fixed in later releases.
There's a lot more development going on with regards to sendmail,
and it may be more difficult to get them to listen to you. But I do
know that Eric, Greg, Claus, and crew do listen, because they are in
the process of eliminating every single major potential software
bottleneck that I identified in my "Sendmail Performance Tuning for
Large Systems" paper that I presented at SANE'98 (see
<http://www.shub-internet.org/brad/papers/sendmail-tuning/>).
I've got a whole laundry list (some twenty-three items by now) of
things that are wrong with tinydns and dnscache, and a lot of them
have to do with problems regarding the megalomaniacal author and his
unholy disciples. I will be writing them up, but I can't make any
guarantees as to when I'll be able to put them online.
Even if I document my writings extensively with references to his
own web pages, documentation, etc... and the public writings of
others, I'm sure that he'll still file libel and slander charges
against me -- he does the same to anyone else who dares to speak out
against him, especially those who do so in a public forum.
God help you if you ever join the Church of Dan. And Dan help
you if you don't.
--
Brad Knowles, <brad.k...@skynet.be>
Do you hate Microsoft? Do you hate Outlook? Then visit the Anti-Outlook
page at <http://www.rodos.net/outlook/> and see how much fun you can have.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
brad.k...@skynet.be
> I've got to say this was one of the most entertaining peices of e-mail I've
> read all day; furthermore, it was the most informative of them all. I just
> started using qmail as my mail delivery system of choice because sendmail
> was EXTREMELY difficult to configure in the ways that I wanted.
I've never had problems configuring sendmail to do the things I
want, but then I recognized in 1994 that the configuration file
syntax is basically a data-driven self-recursive language, similar to
Prolog. I never had a problem with it after that. ;-)
More recent versions of sendmail have become easier to configure,
but there is still a lot of deep magic you need to understand, if you
want to implement more complex tasks for which m4 macros have not yet
been created, or just generally want/need to do something that
doesn't fit into the standard sendmail "flow" of doing things.
This is one of the reasons why I started looking seriously at
postfix, and got involved with it at a very early stage (back when
Wietse was still calling it VMail). There have been a number of
recommendations that I have made to Wietse regarding suggested
improvements, and most of them were made in short order (it took me a
little while longer to get him to come around on some of the others
;-).
IMO, postfix is not yet quite a 100% drop-in replacement for
sendmail, but it does handle 99% of the job, and most people won't
need that last 1% it doesn't yet do. Moreover, postfix has the
simplest configuration language that I have ever seen for any
program, and the largest set of "sane but secure" defaults -- It is
entirely possible to have a fully functional postfix installation
where the entire configuration file is just two lines long.
Just try having a two-line configuration file for any other
program on the planet.... Okay, any other general-purpose MTA. ;-)
> I'm
> beginning to start up a webhosting service with virtual domain hosting with
> full e-mail services and qmail was frankly the only package out there with
> the commitment and features that seemed close to my liking. I was also
> looking at the other tools out there that I could slap on top of qmail to
> make it more functional (vpopmail, sqwebmail, etc).
Granted, there are a number of add-on features that have been
created for qmail. I believe that it is possible to duplicate those
features, or significantly improve on them, using other programs with
other MTAs (including sendmail and postfix), but it would take more
work to do so because you'd have to take a number of programs from
different groups and put them together.
However, this is the real power of the Unix "toolbox" philosophy
-- you can put the tools together that you want, in most any way you
want, making the result do just about whatever you want.
Unfortunately, Dan breaks this philosophy by tightly integrating all
his tools together, and making it so that they are all
interdependent. For example, you can't use the standard inetd that
ships with your system, you are instead forced to use his tcpserver.
And heaven help you if you need to do something that isn't covered by
his tools, because Dan sure won't.
If qmail does everything you need and does it in a way that you
can comprehend, then you would be pretty foolish to just throw all
that away because of personality issues with the author.
Nevertheless, I would encourage you to look at alternatives,
because sooner or later I believe that you are either going to need
to do something that Dan does not consider to be important, or you
are going to run afoul of personality issues with him yourself --
either way, you will then be out in the cold.
t...@sleepy.wojomedia.com
> -- you can put the tools together that you want, in most any way you
> want, making the result do just about whatever you want.
> Unfortunately, Dan breaks this philosophy by tightly integrating all
> his tools together, and making it so that they are all
> interdependent.
You are kidding right? It looks to me that you are completely blinded by
your disdain for Dan. You don't think Postfix took a lot of design hints
from qmail? qmail is one of the most modular systems out there.
> For example, you can't use the standard inetd that
> ships with your system, you are instead forced to use his tcpserver.
> And heaven help you if you need to do something that isn't covered by
> his tools, because Dan sure won't.
From the INSTALL file on a qmail-1.03 distribution
16. Set up qmail-smtpd in /etc/inetd.conf (all on one line):
smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env
tcp-env /var/qmail/bin/qmail-smtpd
> because sooner or later I believe that you are either going to need
> to do something that Dan does not consider to be important, or you
> are going to run afoul of personality issues with him yourself --
> either way, you will then be out in the cold.
the qmail user community is more than sufficient for support.
I like Postfix myself, but you are so blatantly biased I am not sure you
are any better than what you are accusing Dan of.
Tim
brad.k...@skynet.be
> You are kidding right? It looks to me that you are completely blinded by
> your disdain for Dan. You don't think Postfix took a lot of design hints
> from qmail? qmail is one of the most modular systems out there.
Wietse saw qmail, and saw that there were a whole host of things
wrong with it. Moreover, he also knew that the author was
intractable, and there was no hope of ever getting any of these
problems fixed. Since he needed to have a subject for a particular
chapter of his upcoming book on "secure programming" that he is
writing with Dan Farmer, he took this subject matter and began the
VMailer project. This later became the program we now call postfix.
IMO, qmail is modular in the same sense that a hammer is modular
-- you can use it to bang on whatever you want. Hmm, make that a
rock, and not a particularly sturdy one.
I'm sorry, if you haven't been doing Internet mail for around a
decade or so, and you haven't personally gone toe-to-toe with Dan
when he gets on one of his whacked-out kicks, you just don't have the
experience that you would need in order to be able to defend your
position.
Contrariwise, anyone who has crossed swords with Dan, or seen one
of his many irrational tirades, can easily provide their personal
evidence of his behaviour problems.
>> For example, you can't use the standard inetd that
>> ships with your system, you are instead forced to use his tcpserver.
>> And heaven help you if you need to do something that isn't covered by
>> his tools, because Dan sure won't.
>
>>From the INSTALL file on a qmail-1.03 distribution
>
> 16. Set up qmail-smtpd in /etc/inetd.conf (all on one line):
> smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env
> tcp-env /var/qmail/bin/qmail-smtpd
Try that with tinydns or dnscache. I was talking about a general
philosophy that Dan applies, not necessarily the specific
implementation found in qmail. Moreover, you still haven't answered
the issue of the size of the configuration file, or the number of
lines required. Can you actually do anything useful with any program
written by Dan in two lines of configuration file?
> the qmail user community is more than sufficient for support.
Riiiiiiiiiiiiiight. Just like C makes a perfectly good macro language.
> I like Postfix myself, but you are so blatantly biased I am not sure you
> are any better than what you are accusing Dan of.
I loathe and despise Dan, that is correct. I am perfectly honest
and upfront about that. And because I do not trust the author as far
as I can bodily throw his planet of residence, I do not trust the
code that he writes. Moreover, because of the reality distortion
field that he seems to manifest, I also don't trust anything
associated with any of the programs he writes.
I've been using Unix and the Internet since 1984 -- almost twenty
years. I've been administering Unix and the Internet since 1989 --
thirteen years. I've been doing DNS and Internet mail system
administration since sometime around 1991, so about eleven years.
In that time, I have been the Technical POC for disa.mil, I
helped set up the DOD CERT (assist.mil) in just seven days from mere
concept to operational reality (at a time when there was just a
single NIC, and the root zone was only updated once a week), I was
the Postmaster and Internet mail systems administrator for over
10,000 users on the DISAnet network, and one of my "customers" was
the Milnet Manager himself (Major Dave Paciorkowski at the time). I
was also responsible for turning in a number of Class A and B network
numbers that were not being used, as well as convincing the SIPRnet
folks (the people on the classified side) that they should use the
DNS and not HOSTS.TXT files, and that they should use real network
numbers assigned by the NIC, in case there ever was a time in the
distant future when they were connected to the real Internet.
I have also been the Sr. Internet Mail Systems Administrator for
America Online, responsible for providing technical leadership to the
team administering well over a hundred servers that provided the
e-mail gateway to/from the Internet for millions and millions of AOL
customers. I also designed what is probably still the worlds largest
caching nameserver farm while I was at AOL, benchmarked at being
capable of handling 32,000-64,000 DNS queries per second.
I have also been a Sr. Consultant for Collective Technologies, a
leading Unix/Internet consulting firm in the US. While at CT, I
consulted for a number of companies, including some of the largest
freemail service providers in the world. I have also been the
Systems Architect for Belgacom Skynet, the largest ISP in Belgium. I
have given classes on DNS for the company Men & Mice, using material
written by Cricket Liu (and I will be doing so again at SANE 2002).
I will soon again be a Sr. Consultant, this time for Snow BV in the
Netherlands, another leading Unix/Internet consulting company in
Europe.
In all the time I've been in this business, and with all my
hard-earned experience, I have found damn few programs that can stand
up to the rigors of the kind of work that I have done.
With regards to being a general-purpose MTA, sendmail is at the
top of that list, especially with recent improvements that allow it
to be as fast or faster than anything else on the planet. I also
have very high regard for postfix, and I have heard a lot of good
things about Exim (although I regret that I have not yet had an
opportunity to do any work with it). I have had more or less
negative experiences with every other MTA that I have encountered,
and qmail ranks below dog poop in my book. IMO, you would literally
be better off flinging canine excrement than using qmail.
With regards to nameservers, there simply is nothing else
publicly available to compare with BIND. Yes, some companies have
developed internal nameserver programs that they have used to help
them provide service at an unequalled level (e.g., Nominum), but
those programs are not publicly available. Of the programs that are
available, BIND wins hands-down.
If you can show me a comparable level of experience and talent on
your part, then I'd be very interested in having a private in-depth
discussion on the relative merits and demerits of various programs
with you, including discussions of detailed benchmarks that you have
run as compared to benchmarks that I have run, etc....
However, unless you are willing and able to function on this
level, I doubt that there is anything you're likely to bring to this
debate that I would find useful or interesting.
--
Brad Knowles, <brad.k...@skynet.be>
Do you hate Microsoft? Do you hate Outlook? Then visit the Anti-Outlook
page at <http://www.rodos.net/outlook/> and see how much fun you can have.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
t...@sleepy.wojomedia.com
my defeat.
For anybody else that wishes to judge a piece of software by its merits
beyond the size of the configuration file or the personality of its
author, I'd suggest that you read the respective archives on the
history of how qmail and dnscache/tinydns (and now djbdns) came to be.
I like postfix just fine but I run qmail for a number of reasons.
I'd recommend http://www.lwq.org and http://www.djbdns.org for more
information on qmail/djbdns.
Tim
t...@sleepy.wojomedia.com
provided information instead of random drivel.
Brad could very much be right in the end. He just couldn't get
past his DJB hatre to provide any real merits in his argument (like
judging software base on ease of configuration and the size of the
configuration file - what was that all about?). I am not surprised,
however, about Dan's antics. I've observed his conversations since
he was a graduate student at NYU.
I do have a question though:
> It was not
> a problem to do the updates of the primary and secondary
> seperately, following an update of the database from which
> the domain data placed in the configuration files was derived,
> since there is implicit fail-over support based on having a
> hierarchical relationship between servers. With Dan's
> arrangement, the secondary answering in the negative is cached
> as authoritative, and the dmaon is off the air for at least
> another 300 seconds (if not longer), as that's the minimum
> default cache expiration time that most ISPs run on their
> caching name servers.
Can you explain this further? I've read it about 5 times and I am
not sure I understand exactly.
d...@ofug.org
> I've got to say this was one of the most entertaining peices of e-mail I've
> read all day; furthermore, it was the most informative of them all. I just
> started using qmail as my mail delivery system of choice because sendmail
> beginning to start up a webhosting service with virtual domain hosting with
> full e-mail services and qmail was frankly the only package out there with
> the commitment and features that seemed close to my liking.
You can't have looked very hard at Postfix.
DES
--
Dag-Erling Smorgrav - d...@ofug.org
t...@sleepy.wojomedia.com
> includes DNS service for the domain, and the primary data
> source is actually a database, then daemon configuration files
> are actually derived data from the database.
Yes makes sense. I believe most larger sites do it like this.
> The secondary update was staggered to occur after the primary;
> what this meant was that there would be an immediate zone
> transfer from the primary for the new zone in the secondary,
> so the only data that needed updating was the zone record
> itself. Everything else happened on the primary. Because
> the secondary was subservient in the hierarchy, the replication
> of the data to the secondary was automatic, and guaranteed
> correctness. In the djbdns case, both would be primary, and
> one might contain stale data relative to the other (e.g. a
> bad serial number) because the configuration data was derived.
First, I am assuming that you serialize the administration
script (no parallel scripts going on).
If primary/secondary has the exact same zones, then with djbdns it
looks like this:
database -> ns1
rsync ns1 ns2
ns2 will always be consistent with ns1 (guaranteed by rsync and
filesystem semantics) if rsync is triggered after ns1 update.
I agree it's more complex, from the administrative script side, if
they don't have the exact same zones. The hierarchy must be enforced
on the administrative script side.
I agree with your points. On the other hand, djbdns
solves a specific set of user needs very well (basically, those
that maintain n servers each of which containing the same zones).
I think it really depends on your needs.
Thanks for the clarification.
Tim
brad.k...@skynet.be
> To create a zone in a secondary bind server, you have to list
> the zone in the secondary's list of zones for which it is a
> secondary, and therefore performs periodic zone transfers.
Right, this is the /etc/named.conf file (or #include'd from it).
Indeed, this really isn't any different on the primary than it is on
the secondary.
> If you are adding a domain to a virtual hosting system that
> includes DNS service for the domain, and the primary data
> source is actually a database, then daemon configuration files
> are actually derived data from the database.
Do you mean that the primary is directly using the database, and
not the standard /etc/named.conf files?
> What that means is that when I add a new zone to the database,
> for it to take effect, I have to add it to the DNS servers.
Right.
> For the primary, I can relax the rule on zone creation via
> DNSUPDAT, and do it in software, without an interruption of
> service. But for a secondary, it is not possible to do the
> same thing, because of the semantics of the security policy.
> In other words, you are allowed to relax the rules for zone
> creation on a primary DNS server, but doing so on a secondary
> can't be done.
Once you start using DNSUPDATE (assuming you're doing so based on
cryptographic keys), you can't use manual administrative methods on
the same server. With BIND 8, you could kind of hack this by
shutting the server down and having it flush all its updated zones
back to the configuration files and the zone files, but this doesn't
work with BIND 9.
> What you could do, if you truly wanted to solve this problem,
> would be to establish a security association between the
> primary and the secondary.
Sure. Secondaries can forward updates to primaries that they are
configured to know about, as well as to other servers that they are
configured to send them to. You can do the same from the primary
perspective using "also-notify".
> Then, if you trusted the primary not to send bogus zone
> creation requests to you, the secondary, you could piggyback
> the zone creations on the security association for a domain
> you already know about (the easiest one to use would be the
> domain for the hosting facility itself, if it were self-hosted
> in the same DNS).
Using cryptographic keys, you can make this part of the process
as trustworthy as the original update.
> Instead, what we did was just stagger the updates, and derive
> both the primary and secondary server from the central database,
> and then kick the DNS servers on both machines in the head. So
> we didn't use DNSUDAT, and we didn't hack bind or security code.
This also works. We did this sort of thing at my previous
employer, although we used a stealth primary and the advertised
servers were secondaries of the internal primary.
> Really, you want to be able to turn around a preliminary
> domain registration within a browser timeout, and have the
> customer functional.
Absolutely.
> Unfortunately, the domain registrars aren't very cooperative
> when it comes to deploying dynamic update protocols, even if
> you are IBM doing the asking. It's really annoying. There
> are workarounds for the sneaky, but they require dead chickens
> and other dark talismans. ;^). DNS registration is like the
> old phone company slogan from the fortunes database:
>
> "We don't care. We don't have to. We're the phone company."
Sadly, this is very true. Indeed, the problem is even worse.
According to the RFCs (including RFC 2870, "Root Name Server
Operational Requirements", see
<http://www.faqs.org/rfcs/rfc2870.html>), root nameservers are
supposed to be authoritative-only, in part to avoid cache pollution
problems, etc....
Now, you would think that the same requirements would apply to
all TLD nameservers around the world. Unfortunately, this is not
true. It turns out that ns.eu.net is one of the advertised
authoritative nameservers for something like 72 TLDs (mostly ccTLDs),
and not only is it also a public recursive caching nameserver (i.e.,
anyone can ask it any question and it will try to obtain the
appropriate information and provide it to you), it also allows zone
transfers. So, if you want to screw up any of these domains, you can
get a zone transfer of the entire domain, and then using knowledge of
cache pollution techniques, you can then hijack the entire domain.
This kind of thing basically puts the entire Internet at serious risk.
Now, you would think that the authors of the above RFC would care
about this kind of problem. And one of the authors (D. Karrenberg)
is the head of the RIPE NCC, so he would be in an ideal position to
do something about it.
However, when I asked him, it didn't seem to bother him a bit
that this was going on. Now there is hypocrisy and apathy for you,
from the kind of guy you would think should care most about these
kinds of problems.
--
Brad Knowles, <brad.k...@skynet.be>
Do you hate Microsoft? Do you hate Outlook? Then visit the Anti-Outlook
page at <http://www.rodos.net/outlook/> and see how much fun you can have.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
brad.k...@skynet.be
> Wedging per domain mail queues into Postfix is much harder
> than wedging them into sendmail. They are almost natural
> in sendmail (well, older versions of sendmail; the newer
> stuff breaks a lot of intersting things by putting security
> barriers in the way).
Per-domain mail queues is one of the few things that Wietse had
yet to support in postfix as of the last time I did anything with it.
I believe that it was something added soon thereafter, but I haven't
been able to confirm that.
> If you do wedge them in, then on an ETRN/ATRN, you are
> guaranteed a 100% hit rate on queue messages, instead of
> just the percentage of the main queue of the messages for
> a particular domain.
Indeed, that is a problem. And if you get 50-60 ETRN requests
per second (as our business-class mail server was getting), this
causes untold amounts of unholy hell.
brad.k...@skynet.be
> First, I am assuming that you serialize the administration
> script (no parallel scripts going on).
Big shops can't afford to do this. The locking has to be done at
a lower level.
> If primary/secondary has the exact same zones, then with djbdns it
> looks like this:
>
> database -> ns1
> rsync ns1 ns2
Right. But rsync isn't a part of the DNS standard protocol.
> I agree with your points. On the other hand, djbdns
> solves a specific set of user needs very well (basically, those
> that maintain n servers each of which containing the same zones).
> I think it really depends on your needs.
Sigh.... It looks like I'm going to have to publicly post my
list of 18 things that I have found wrong so far with djbdns, as
opposed to simply sending it privately to a few individuals. So be
it:
1. By default, tinydns does not hand out referrals to questions it
is asked about zones it does not control. I believe that this
violates the spirt of the RFCs, if not the letter.
2. By default, tinydns does not support the use of TCP at all. This
most definitely violates the spirt of the RFCs, as well as the
letter (if a DNS query via UDP results in truncation, you're
supposed to re-do the query using TCP instead).
Indeed, if you want to support TCP under tinydns, you have to
configure an optional program called "axfrdns", which was
intended to handle zone transfers, but also happens to share the
same database as tinydns, and can handle generic TCP queries.
3. The suggested method for copying contents of DNS zones is rsync,
scp, or other remote copy tools. The DNS standard method of
zone transfers (query type "axfr") is only supported as an
additional, disrecommended method.
4. Without a patch from a third party, tinydns does not listen to
more than one IP address. If you have a multi-homed server, you
have to apply a patch from someone other than they author,
before you can get it to listen on more than one
address/interface.
5. Without a patch from a third party, tinydns does not support the
standard "NOTIFY" protocol of informing secondary nameservers
that the zone has been updated, and that they need to check the
SOA serial number and download a new copy (if they don't already
have it).
6. Without a third party patch, tinydns does not support standard
SRV records (which are intended to ultimately replace MX
records, as well as perform similar functions for services other
than mail).
7. You cannot set an alternative SOA contact address (other than
what is hard-coded within tinydns), if you do not have a patch
from a third party.
8. Like tinydns, dnscache will not bind to more than one IP address
without a third party patch.
9. Because they are separate programs, you can't have both tinydns
and dnscache listening to the same IP address(es) on the same
server.
While this is not the recommended mode of configuration, some
sites don't have the luxury of having separate
authoritative-only and caching/recursive-only server(s), and
need to mix them both on one machine (or set of machines). With
the BIND 9 "view" mechanism, this is relatively easy to do.
With djbdns, this is impossible.
10. There aren't even any patches that can get djbdns to
implement TSIG, Dynamic DNS, or DNSSEC, nor are they ever likely
to be created (my understanding is that the author is strongly
opposed to them).
Unfortunately, as time goes on and more and more people are
doing things like IPv6, VPNs based on IPSec, or people just care
about being able to cryptographically prove that their servers
are handing out the only correct information and that the
clients are able to cryptographically verify this fact (think:
electronic banking), these kinds of features are going to become
ever more commonplace.
Note that, with the advent of BIND 9, you can create a
caching-only server that will validate cryptographically signed
records, and all clients can benefit even if they do not
themselves implement any of the new DNSSEC features.
11. There are a number of things that djbdns does which I believe to
be outright bugs. However, the author of this package simply
refuses to accept that his code could be anything less than 100%
perfect, and while he claims to have a "bounty" that he will pay
for any bug that is found, in reality he is the one that gets to
define what he accepts as a "bug", and has repeatedly
demonstrated a tendancy to openly refuse to accept some
purported bug, but then to quietly fix the code with future
releases.
So, let's look at some of these bugs:
A. When an IQUERY is sent to a djbdns server, it will
respond with opcode set to QUERY. (it should simply
copy the opcode, not make something up).
B. DNSCACHE (the caching server) does not respond to
queries with the RD bit clear in the query. (Instead
of simply answering from cache without recursing
the dns-tree).
11. Unfortunately, there is very little documentation available
for djbdns. Whereas for BIND you will discover at least four or
five separate books directly related to BIND on Unix (and one
for BIND on Windows NT), and at least sixteen different books
that are related to the DNS in general (not including books
where the DNS forms just a relatively small part of the whole),
there are no books available on djbdns.
If you're at a site all by yourself, and you don't have access
to normal mailing lists, newsgroups, or other support services,
then whatever books you can carry in with you are your last
refuge of assistance.
12. Commercial support for djbdns is also questionable. Yes,
there are a few groups listed at <http://www.tinydns.org/>, but
how big are they? How long have they been around? How likely
are they to still be here in six months? How many combined
decades of experience do they have in designing DNS protocols or
programs to serve them?
These are not the kinds of questions you need to ask when you go
to the folks at Nominum (see <http://www.nominum.com/>), since
they wrote BIND 9 under contract to the ISC, and they have their
own implementation of a nameserver (not based on BIND) which is
used as the core of the Global Name Service solution that they
offer. Indeed, the GNS is a singularly unique service that is
not available anywhere else at any other company in the world,
and even goes beyond the current technical implementation of a
root nameserver or a gTLD nameserver. Note that Nominum also
offers free secondary nameservice to anyone in the world through
secondary.com (see <http://www.secondary.com/>) for up to five
domains and less than 100 records per person/organization, and
they use the GNS to provide this service.
If you're looking for BIND support in Europe, you can talk to
Nominum, or you can look to the folks at Men & Mice (see
<http://www.menandmice.com/>), who also have a service agreement
with the ISC.
13. Training for djbdns is minimal or non-existent. Contrariwise,
if you go to any major Unix or Linux conference in the world,
they will probably have training available on BIND.
In partnership with the ISC, the two official providers of
training on DNS and BIND are Nominum (see
<http://www.nominum.com/services/training/index.html>), and in
Europe, both Nominum and the company Men & Mice (see
<http://www.menandmice.com/DNS-training/index.html>) provide
training.
In addition, there are other third-parties also providing
training in the DNS, BIND, etc.... Quick searches at Google
(see <http://www.google.com/>) turned up Genesis Communication
(see <http://www.genesiscom.ch/Services/S_prfeduEdns.htm>),
Intranet Solutions (see
<http://www.intranet-solutions.com/home/services/training/
dnstraining.htm>), and VeriSign (see
<http://www.verisign.com/training/courses/dns/>). I'm sure there
are plenty of others, these are just the ones I turned up with a
trivial search and which I found to be of interest.
Of course, note that Cricket Liu (one of the co-authors of the
book _DNS and BIND_) recently left his previous employer
(NSI/VeriSign), and is now employed by Men & Mice. He continues
to work for them doing many of the same things he used to do
before -- including providing training and consulting services,
etc....
14. One argument frequently used to support the use of djbdns
over BIND is performance. Upon further investigation, this
claim simply does not hold water.
Benchmarks published by Rick Jones have clearly shown that BIND
can scale up to at least 12,000 DNS queries per second, and
there is every indication that BIND 9.2 will be able to go
considerably higher. The best benchmarks available for tinydns
indicate that it can handle at least 500 queries per second, but
that is the highest number reported. Other people on the
bind-users mailing list have indicated that they have performed
their own (as yet unpublished) benchmarks of tinydns, and that
it had notable performance problems that BIND did not suffer.
The best published benchmarks from the author for dnscache
report a query handling rate of less than one million records
over a 4.5 hour period of time, which works out to an average of
less than sixty-two queries per second. Even if you look at
numbers of queries per CPU second, the best numbers they can
provide are 13.7 million queries over a four week period of time
with 128 minutes of CPU time used (an average of slightly less
than 1784 queries per CPU second).
Compare this with the requirement from RFC 2010 "Operational
Criteria for Root Name Servers" (since obsoleted by RFC 2870
"Root Name Server Operational Requirements") is that the machine
and software in question be able to handle at least 2000 queries
per second, and be scalable to levels higher than that. Indeed,
recent reports have indicated that a.root-servers.net
(considered by many to be the "primary" root nameserver) is
currently handling around 12,000 DNS queries per second at peak.
Preliminary benchmarks published on the bind-users mailing list
have indicated that, on the same hardware, there is little or no
performance benefit to using dnscache as opposed to BIND 9.1.2,
and when these tests are re-run with BIND 9.2, I'm sure that it
will come out even faster.
15. One of the recommended features of dnscache is the ability to
limit the amount of memory that the nameserver will use. If you
attempt to go over this limit, the nameserver will start
throwing away some old data, in order to fit the new data in.
On the surface, this sounds like a good idea, and a way to avoid
the problems you can get into if BIND ever starts paging and/or
swapping. However, on further reflection, this is, at very
best, a false economy.
Let's take the case where an unexpected process starts chugging
through a large log of a webserver, and it wants to do reverse
DNS resolution on all those collected IP addresses. If these
queries were aimed at your main caching nameserver, odds are
that you probably would never again need the answers to these
queries, at least not before they time out of the cache
naturally.
If the cache of this nameserver were relatively full of "real"
data already, the problem is that this real data would be thrown
away to make room for the new one-time-only queries. Even if a
Least-Recently-Used (LRU) algorithm were employed to choose the
answers that can best afford to be flushed (to make room for the
new answers to be stored), there is a significant amount of
overhead that the nameserver would have to go through in order
to simply perform the garbage-collection and memory flushing
routines.
Since an LRU algorithm probably won't be used, the overhead of
garbage collection and memory flushing would be much, much
greater -- and everything else the server does will suffer.
This also greatly increases the probability that a query will be
performed that would otherwise have been in the cache, except
for the fact that it was flushed to make room for new answers,
thus resulting in data thrashing.
Indeed, it is swap thrashing that was the intended goal to
avoid, but local disk typically has a latency measured in terms
of single digit milliseconds. Contrariwise, DNS queries that
have to go out to the Internet and come back are frequently
measured in terms of tens, hundreds, or even thousands of
milliseconds. Therefore, you will have traded a known serious
problem with local swap thrashing for an unknown and quite
probably much, much more serious remote data thrashing.
Moreover, once you get yourself into a thrashing scenario like
this, odds are that it will be at least as bad and unrecoverable
as it would be to have had BIND doing local swap thrashing.
No, it is much better to have a known problem such as local swap
thrashing that is relatively easily detected with tools like ps,
top, vmstat, iostat, sar, etc... than it is to have a mysterious
slow nameserver problem that you cannot easily detect, debug, or
resolve.
16. Unfortunately, a lot of the reasons the author gives for
running djbdns instead of BIND are related to problems in older
versions of BIND which have been fixed or are largely non-issues
in later releases of BIND 9.
For example, he makes a big point of tinydns being better than
BIND, because while the process is starting up, it still answers
queries. While previous versions of BIND would not answer
queries during startup, this is no longer a problem with BIND 9.
Dan also makes a great deal of the fact that the djbdns tools
run as a user other than root, and in chroot() environments.
While the "monolithic setuid root" situation was an issue with
older versions of BIND, even more recent releases of BIND 8
could be easily run as a non-priviledged user in a chroot()
environment, and this is the preferred method of running BIND 9.
Contrariwise, one of the legitimate big complaints about older
versions of BIND is that they implemented zone transfers in a
separate program. If the database was large, then the
fork()/exec() overhead was large, and the system could seriously
thrash itself to death as it copied all those pages (for systems
without copy-on-write), only to immediately throw them away
again when it fired up the named-xfer program. With BIND 9,
this problem is solved by having a separate thread inside the
server handling zone transfers, and no fork()/exec() is done.
However, tinydns/axfrdns goes back to the fork()/exec() model
that was so greatly despised.
17. The license under which the djbdns collection (and other
programs from the author) are published does not meet the
definition of "open source", according to the book _Open
Sources_ (see
<http://www.oreilly.com/catalog/opensources/book/perens.html>).
You may not care about this issue, but some people do. If you
do care about this issue, then this may be very important to
you. Certainly, the ability to legally make modifications to the
code is fairly important in this arena, and if you can't legally
do so, then it is much less useful to you to have the source
code at all.
18. Finally, I want to touch on the subject of the
trustworthiness of the code itself.
One of the basic concepts of the Open Source movement is that,
as the number of people participating in the project grows, and
as the collected design & implementation experience of those
people grows, and the number of sites running the software
grows, and the number of different types of hardware running the
software grows, then your probability of rapidly discovering
bugs (and being able to fix them) quickly approaches 100%, even
for the deepest bugs in the system.
Unfortunately, the djbdns programs are all large enough, and
dependant on enough system libraries, that they simply cannot be
proven to be bug-free. Once you reach this level of project
size, other factors start being more important than keeping down
absolute code size of the individual units.
In the case of djbdns, they have a relatively small community of
developers who are not all that experienced, a relatively small
number of sites that are running the software, and the software
is running on a relatively small sample of different types of
hardware. They just don't have enough aggregate CPU time spent
executing each and every line of code, and enough decades of
combined DNS protocol design experience that they can begin to
compare with BIND 9.
--
Brad Knowles, <brad.k...@skynet.be>
Do you hate Microsoft? Do you hate Outlook? Then visit the Anti-Outlook
page at <http://www.rodos.net/outlook/> and see how much fun you can have.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
t...@sleepy.wojomedia.com
> > First, I am assuming that you serialize the administration
> > script (no parallel scripts going on).
>
> Big shops can't afford to do this. The locking has to be done at
> a lower level.
Errr, you are going to have to lock/order the update of the
named.conf (or its included) file at some point. If you are already
doing that, you could very well lock/order the update of your tinydns
updates. Depending on your needs, one is easier than the other.
> > If primary/secondary has the exact same zones, then with djbdns it
> > looks like this:
> >
> > database -> ns1
> > rsync ns1 ns2
>
> Right. But rsync isn't a part of the DNS standard protocol.
So what? What DNS protocol allows you to kick/restart the secondary
bind server to tell it new zones are available?
> > I agree with your points. On the other hand, djbdns
> > solves a specific set of user needs very well (basically, those
> > that maintain n servers each of which containing the same zones).
> > I think it really depends on your needs.
>
> Sigh.... It looks like I'm going to have to publicly post my
> list of 18 things that I have found wrong so far with djbdns, as
> opposed to simply sending it privately to a few individuals. So be
> it:
You make a lot of good points in your list but I'm already aware of
most of them. Personally I think if you trim down your list to
about 8 points you'd have a LOT more credibility. I'll leave it to
somebody else more familiar with dns to answer your issues (although
I am unaware of any djbdns expert hanging around in -chat).
Once again, it depends on your needs.
Tim
tlam...@mindspring.com
[ ... Per domain mail queues ... ]
> > If you do wedge them in, then on an ETRN/ATRN, you are
> > guaranteed a 100% hit rate on queue messages, instead of
> > just the percentage of the main queue of the messages for
> > a particular domain.
>
> Indeed, that is a problem. And if you get 50-60 ETRN requests
> per second (as our business-class mail server was getting), this
> causes untold amounts of unholy hell.
With them in place, we handled as much email as Best Internet's
primary list server handled in a month in just under 48 hours,
on one 166 MHz dual processor PPC box (our test box), with
10,000 virtual domains, 5,000 using ETRN/ATRN, and 5,000
acting as "queue-only" only in the case of an outage of the
primary mail server for the domain. That's over half a million
10k messages every 24 hours.
We believed that our final deployment would scale at 50,000
virtual domains per node, all using ETRN/ATRN. At that point,
it was all about FS latency, which was much lower on a journalled
FS with btree directory structure than it would be on FreeBSD.
Gotta love sendmail... 8-) 8-).
-- Terry
t...@sleepy.wojomedia.com
> > First, I am assuming that you serialize the administration
> > script (no parallel scripts going on).
>
> derived data is a snapshot of a collection of records. So
> the record is not there, it's there and it's old, or it's
> there and it's new.
I understand that. What happens if:
database -> ns1
somebody mucks with the database (updates a serial # for zone for example)
database -> ns2
From your previous description, I had assume that it was important
for you to have consistency between ns1 and ns2 (and ns2 never has
newer information than ns1).
> This means that you can treat any record creation/update as
> if it happened either before or after the derivation, and
> the derived state is always consistent.
>
> If you couldn't do parallel updating, there'd really be no
> reason to use a database instead of a big honking file lock.
I am talking about serializing updates of named.conf in ns1 and ns2.
> There are man problems with this. The first is that the
> assumption of the primary and secondary machines having the
> same zones.
No argument there.
> The third and final problem here is that this form of
> replication is still subject to the negative caching
> problem with the update latency, because the servers do
> not maintain a hierarchical relationship. Thus, if you
> have a domain delegation to your DNS servers, and one of
> the DNS servers doesn't know about it, it's not going to
> forward the request to a server which is updated earlier
> (the primary) when it can't find the record locally.
OK you got me on this point. That's a scenario I had not realized.
> All of the top level DNS servers (the servers for "." and the
> servers for the "in-adder.arpa.", "com.", "net.", etc.
> delegations from "." run bind.
> Form that perspective along,
> you are taking your career in your hands if you run anything
> else, should an interoperability issue pop up.
Hey no arguments there. There is a reason I buy Cisco.
Tim
brad.k...@skynet.be
> Errr, you are going to have to lock/order the update of the
> named.conf (or its included) file at some point.
Yes, but this could be using fine-grained locking on the sending
side, as opposed to serializing all updates through a single person.
You could even batch them, so that updates happen in the database
asynchronously with their being pushed out to the servers.
> So what? What DNS protocol allows you to kick/restart the secondary
> bind server to tell it new zones are available?
I believe that the protocol is called "NOTIFY".
--
Brad Knowles, <brad.k...@skynet.be>
Do you hate Microsoft? Do you hate Outlook? Then visit the Anti-Outlook
page at <http://www.rodos.net/outlook/> and see how much fun you can have.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
brad.k...@skynet.be
> With them in place, we handled as much email as Best Internet's
> primary list server handled in a month in just under 48 hours,
> on one 166 MHz dual processor PPC box (our test box), with
> 10,000 virtual domains, 5,000 using ETRN/ATRN, and 5,000
> acting as "queue-only" only in the case of an outage of the
> primary mail server for the domain. That's over half a million
> 10k messages every 24 hours.
We had much the same situation with our "business" SMTP server,
handling roughly 40,000 120KB messages per day. Of course, a smaller
number of larger messages is easier to handle (less synchronous
meta-data overhead), but on the other hand I had not yet configured
the server to have a mail queue per domain.
--
Brad Knowles, <brad.k...@skynet.be>
Do you hate Microsoft? Do you hate Outlook? Then visit the Anti-Outlook
page at <http://www.rodos.net/outlook/> and see how much fun you can have.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
t...@sleepy.wojomedia.com
> At 5:16 PM -0600 2002/03/25, Tim wrote:
>
> > Errr, you are going to have to lock/order the update of the
> > named.conf (or its included) file at some point.
>
> Yes, but this could be using fine-grained locking on the sending
> side, as opposed to serializing all updates through a single person.
> You could even batch them, so that updates happen in the database
> asynchronously with their being pushed out to the servers.
Nothing in tinydns prevents you from doing that. Many people
generate data.cdb directly from the database. All my discussion is
with respective to Terry's points, which is how to propagate from
master to slave in a consistent manner.
> > So what? What DNS protocol allows you to kick/restart the secondary
> > bind server to tell it new zones are available?
>
> I believe that the protocol is called "NOTIFY".
Unless I am missing something, that only helps with zone CHANGES. It
does not help with new zones.
I understand there are out-of-band mechanisms to deal with with zone
creations from master -> secondary. That was essentially why Terry
gave detailed explainations in his previous email.
If you want further discussion, feel free to take it to the
djbdns mailing list. There are many people there much more knowledge
than me. I have a lot of respect for Terry's points but frankly,
you have shown very little real argument (you could still be right -
you just made some very silly points). Like for example, it occurred
to me that dnscache/tinydns doesn't even use tcpserver so I don't know
what your previous rant was about. Neither does either use fork().
Most of your arguments are the same by people who argue for Microsoft
(i.e. ease of configuration, established support - never mind that
tinydns is but a year or so old, etc). That said, I have no loyalty
towards djbdns, qmail, or any other piece of software for that matter.
I use what suits my needs at the moment. Bind works better for you -
great. Just don't spread misinformation about other pieces of software
because you have disdain for the author. Once again, if you narrow
down your 18 point list to about 8, you'll be taken more seriously.
Tim
tlam...@mindspring.com
> At 5:16 PM -0600 2002/03/25, Tim wrote:
> > So what? What DNS protocol allows you to kick/restart the secondary
> > bind server to tell it new zones are available?
>
> I believe that the protocol is called "NOTIFY".
Trick question. DNSNOT doesn't work for new zones, since they
have to be explicitly configured in secondaries... 8-).
-- Terry
brad.k...@skynet.be
> Bind works better for you -
> great. Just don't spread misinformation about other pieces of software
> because you have disdain for the author.
If I have made any factual errors, I welcome your corrections.
> Once again, if you narrow
> down your 18 point list to about 8, you'll be taken more seriously.
I'm sorry. If I see a hundred things wrong with a particular
system, I see no reason why all hundred should not be listed. If
people can't deal with the level of information provided, that's
their problem.
--
Brad Knowles, <brad.k...@skynet.be>
Do you hate Microsoft? Do you hate Outlook? Then visit the Anti-Outlook
page at <http://www.rodos.net/outlook/> and see how much fun you can have.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
t...@sleepy.wojomedia.com
On Mon, Mar 25, 2002 at 04:17:05PM -0800, Terry Lambert wrote:
> We can actually consider that the ordering of updates is only
> to ensure the availability of DNS records within some minimum
> time after instantiation in the database. In fact, we could
> really update in any order, and the only effect would be to
> widen the maximum update latency window X from X to (2X-1).
> This is an artifact of the forwarding of unknown requests to
> the primary when the secondary is listed as authroitative and
> has no record.
This last sentence was the main part I had not considered. I could
see that in your particular design that was a very important feature.
On Mon, Mar 25, 2002 at 04:32:30PM -0800, Terry Lambert wrote:
> It occurs to me that it's not obvious from this discussion so
> far what I meant about the number of lines of code in the earlier
> discussion of using DNSUPDAT to do zone creation on the secondary.
Well I got that part fine.
> to a transiently connected server on the customer premesis (these
> days, "DSL" qualifies as a transient connection, from my personal
> experience with a large customer base).
I can agree with that just from my own personal DSL connection!
> The djbdns method of achieving this result is to move the
> complexity to some out of band mechanism involving per scripts,
> rdist, and a human being (that last component is the one with
> the lowest MTBF 8-)).
Hmm, if you say "or a human being" I'd agree with you. There's
nothing in djbdns that prevents you from automating these things.
I think it's easier to say that djbdns is INCOMPLETE when it comes to
these scenarios than to say there is something inherently wrong with
its design (and don't confuse design with features - I understand
djbdns still lack many features most of which Brad had pointed out).
DNSNOT does not technically have to be part of the DNS server,
for example. It could be a separate program.
> and it still leaves the update of an
> active server to a reload operation, instead of an update.
Yes and no. Because of the design of cdb, every update could be
considered a reload but you don't really have the penalties associated
with a reload. The reload is essentially a rename() system call.
cdb() opens/closes on each data serving so actually there is nearly
zero penalty that I can think of, other than however long it might
have taken to generate the new cdb file. If you have a huge zone
file this could be an issue on a remote link - it's certainly not as
clean as sending just an empty named.conf file, but you don't have
to worry about the complexity of reloading the named.conf with bind
either (I know this was back in the older days, but I always thought
it was silly that the "recommended" way of running bind was to run
it in a tight loop in a sh script just in case it crashes).
Now, I also know that you understand filesystem semantics better than
most so I am prepared to be englightened again.
> Realize that a fully distributed DNSUDAT mechanism capable of zone
> creation in both primary and secondary server resolves all race
> windows in a way that a manually replicated set of primaries could
> never hope to do.
Absolutely. What I don't understand is why would you say that this
could not be done with djbdns? Again, I think djbdns is incomplete
in these type of scenarios, but one could design add on services,
without modification to djbdns code, that achieve many of these goals.
If you look at djbdns as a small tool in the overall scheme, I don't
see anything wrong with it. If you want a tool or a suite of tools
that'll do everything, then djbdns is very obviously not the way to go.
I have always considered djb programs to be a set of starter tools
that one could built upon. That's why I was puzzled when Brad insists
it wasn't modular. I do very much agree that very often it lacks
features that one wants by default, but I am continually surprised
but what one could do with djb tools with a little thought.
Thanks,
Tim
tlam...@mindspring.com
> > The djbdns method of achieving this result is to move the
> > complexity to some out of band mechanism involving per scripts,
> > rdist, and a human being (that last component is the one with
> > the lowest MTBF 8-)).
>
> Hmm, if you say "or a human being" I'd agree with you. There's
> nothing in djbdns that prevents you from automating these things.
> I think it's easier to say that djbdns is INCOMPLETE when it comes to
> these scenarios than to say there is something inherently wrong with
> its design (and don't confuse design with features - I understand
> djbdns still lack many features most of which Brad had pointed out).
> DNSNOT does not technically have to be part of the DNS server,
> for example. It could be a separate program.
If this were the case, then it would be non-interoperable, unless
you specifically dedicated a VIP to the task; the problem is that
you'd have to bind multiple programs to the same port/IP pair.
About the only way you could do this would be to use the BPF, as
seperate programs don't allow for the idea of a MUX based on the
query type within the packet. This is considered a security
feature of djbdns.
One way to deal with this might be to use the SRV records for
differentiated service types to move the DNS server components
themselves to a different port. There are two problems with
this scenario:
o There is no official support for this via the RFC
process defining differential service types for DNS
(this is easily overcome).
o There is an intentional failure to support SRV within
djbdns (this is not easily overcome)..
Another way to deal with this would be local forwarding of
unknown request types. This might be possible, but would need
modification of the djbdns. It's also a case of the intentional
failure to support, so doing this could have an adverse effect
on the security model of djbdns, as well.
> > and it still leaves the update of an
> > active server to a reload operation, instead of an update.
>
> Yes and no. Because of the design of cdb, every update could be
> considered a reload but you don't really have the penalties associated
> with a reload. The reload is essentially a rename() system call.
> cdb() opens/closes on each data serving so actually there is nearly
> zero penalty that I can think of, other than however long it might
> have taken to generate the new cdb file. If you have a huge zone
> file this could be an issue on a remote link - it's certainly not as
> clean as sending just an empty named.conf file, but you don't have
> to worry about the complexity of reloading the named.conf with bind
> either (I know this was back in the older days, but I always thought
> it was silly that the "recommended" way of running bind was to run
> it in a tight loop in a sh script just in case it crashes).
>
> Now, I also know that you understand filesystem semantics better than
> most so I am prepared to be englightened again.
The overhead is predominantly in the system call processing; the
open/read/close is threee sets of protection domain crossings.
There is also file system semantic overhead (as you imply) in the
close operation. The Single UNIX Specification has relaxed many
of the "SHALL be updated" semantics into "SHALL be marked for update"
semantics. This lets an FS compliant with the SUS2 and non-compliant
with POSIX (e.g. almost any log-structured FS in use today) make a
number of semantic shortcuts which take away much overhead. But...
in the case of the close semantics, items maked for update are
required to be updated on final close, and so you eat the full
overhead, even if you play fast and lose with the POSIX compliance
and comply with the lesser semantics of the SUS2.
Overall, opening and closing a file each time is a very bad thing,
performance-wise, even though it resolves a number of ordering
issues.
> > Realize that a fully distributed DNSUDAT mechanism capable of zone
> > creation in both primary and secondary server resolves all race
> > windows in a way that a manually replicated set of primaries could
> > never hope to do.
>
> Absolutely. What I don't understand is why would you say that this
> could not be done with djbdns? Again, I think djbdns is incomplete
> in these type of scenarios, but one could design add on services,
> without modification to djbdns code, that achieve many of these goals.
> If you look at djbdns as a small tool in the overall scheme, I don't
> see anything wrong with it. If you want a tool or a suite of tools
> that'll do everything, then djbdns is very obviously not the way to go.
I think we are back to the port/IP pair conflict for listens for
incoming requests. The djbdns really can't support an overall
framework without modification.
> I have always considered djb programs to be a set of starter tools
> that one could built upon. That's why I was puzzled when Brad insists
> it wasn't modular. I do very much agree that very often it lacks
> features that one wants by default, but I am continually surprised
> but what one could do with djb tools with a little thought.
As implementations, they are somewhat easier to understand,if you
can get around the coding style, which make them good examples of
minimal implementations, as long as you are aware of the inherent
limitations they have with respect to the RFCs, up front. They
would be a lot more useful as an educational tool, if there was
accompanying documentation that explained those limitations up
front.
For deployment, especially large systems deployment, where your
ability to sell in place of a competitor comes as a result of
service availability and turnaround time, I think that djbdns can
not be a first choice.
The ISC implementation (bind) has historically been more prone to
security problems; on the other hand, I think these have been
addressed in bind 9: the original code was not intended for a
deployment into an actively hostile network environment, while
the new code is. There's no reason to throw the baby out with
the bathwater.
-- Terry
t...@sleepy.wojomedia.com
> you specifically dedicated a VIP to the task; the problem is that
> you'd have to bind multiple programs to the same port/IP pair.
> About the only way you could do this would be to use the BPF, as
> seperate programs don't allow for the idea of a MUX based on the
> query type within the packet. This is considered a security
> feature of djbdns.
Yes I agree this is a design limitation. I always figure djb would
one day write a mux in front of all his *dns programs or figure out
another way. Maybe not. ;-)
> But...
> in the case of the close semantics, items maked for update are
> required to be updated on final close, and so you eat the full
> overhead, even if you play fast and lose with the POSIX compliance
> and comply with the lesser semantics of the SUS2.
> Overall, opening and closing a file each time is a very bad thing,
> performance-wise, even though it resolves a number of ordering
> issues.
Hmm, I always thought cdb is operating under these principles:
1) the file is never updated (so close() shouldn't be too costly,
if at all. You certainly understand under the hood better than I on
this)
2) the rename() operation occurs fairly infrequently (i.e. once every
minute or 5 minutes at most).
3) the OS is reasonably smart about caching the file so repeatedly
open(), 2 seeks(), 1 read(), and close() is relatively lightweight.
So I would not have guessed close() is a big problem.
> I think we are back to the port/IP pair conflict for listens for
> incoming requests. The djbdns really can't support an overall
> framework without modification.
I am in full agreement here and the rest of your e-mail.
Tim
vlad...@math.uic.edu
> I've been on IETF mailing lists with him, and his attitude is
> always that he is always right (by definition) and everyone else is
> always wrong (by definition). He insists on replying to each and
> every mail message posted to the list, and constantly dredging up old
> points that everyone else has agreed were dead a long, long, long
> time ago.
>
> He will reply to messages that are not anywhere near remotely
> related to his favourite topic, quote some random line that is least
> unlike the straw-man position that he wants to destroy, and then go
> off on a multi-page rant.
>
> He considers himself to be God's gift to programming, security,
> Internet mail, DNS, cryptography, and anything else he cares to
> decide to screw around with, and woe betide anyone who ever disagrees
> with his world-view -- even if that world-view changes and you used
> to be his most vocal supporter.
>
>
> The problem is that he is generally totally fscking clueless (at
> least on all the topics with which I am familiar), and his
> whacked-out ideas of how things should be done are non-solutions to
> non-problems, and he simply doesn't understand what the real problems
> are.
Brad,
You are making a very general statement. Such statements are usually
blind and unfair. I won't comment on Prof. Bernstein's abilities as
a programmer or his character, but in the areas of his direct expertise
(mathematics) he is very good. I am saying this as his former
colleague and student.
--
Vladimir
vlad...@math.uic.edu
> On Sun, Mar 24, 2002 at 07:57:12PM -0800, Benjamin Krueger wrote:
>
> > [ ... lengthy, humerous missive about djb in a nutshell here ... ]
> >
> > Brad, you have put this more eloquently than I ever could have, and you
> > couldn't be more correct. Thank You. =)
> >
> > Now I'm just counting the seconds until DJB suddenly appears on the list to
> > rebutt you and defend his dearest reputation against those who would sully
> > such a fine person...
>
> We may get our wish, sooner than we may like.
>
> Quoting from "http://cr.yp.to":
>
> "The cr.yp.to servers are located in the Department of Mathematics,
> Statistics, and Computer Science at the University of Illinois at
> Chicago.
>
> DNS service, HTTP/FTP service, and mail service are powered by djbdns,
> publicfile, and qmail respectively.
>
> The machines were running OpenBSD for some time, but they are being
> switched to FreeBSD. "
> ^^^^^^^^^^^^^^^^^^^^
FreeBSD is what most of our machines run. Just for the record, among
other reasons, we've also considered Dan's advice to use FreeBSD when
we dumped Linux a couple of years ago.
brad.k...@skynet.be
> > The problem is that he is generally totally fscking clueless (at
> > least on all the topics with which I am familiar), and his
> > whacked-out ideas of how things should be done are non-solutions to
> > non-problems, and he simply doesn't understand what the real problems
> > are.
>
> Brad,
>
> You are making a very general statement. Such statements are usually
> blind and unfair. I won't comment on Prof. Bernstein's abilities as
> a programmer or his character, but in the areas of his direct expertise
> (mathematics) he is very good. I am saying this as his former
> colleague and student.
Please note that I added a parenthetical comment "at least on all
topics with which I am familiar". I do not profess to be an expert
in cryptography, although it is a subject with which I have some
interest. I do not pretend to be able to analyze Snuffle or any
other cryptographic work that he has done, but I can read the
writings of other respected cryptographers (such as Bruce Schneier).
Specifically in the areas of Internet e-mail (especially the SMTP
protocol) and DNS, it is my firm belief that Dan is one of the
biggest menaces on the 'net, and he, his ideas, his code, and his
disciples pose a direct threat to the very existence of the 'net --
it all depends on how many people he tricks into becoming his
initiates.
--
Brad Knowles, <brad.k...@skynet.be>
Do you hate Microsoft? Do you hate Outlook? Then visit the Anti-Outlook
page at <http://www.rodos.net/outlook/> and see how much fun you can have.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
t...@sleepy.wojomedia.com
point out http://cr.yp.to/djbdns/knowles.html
I'm going to attempt to stay out of the rest of this discussion.
I know at least 3 people more knowledgeable than I reading this
thread now. My father taught me to shutup when people who know better
are present. ;-)
Tim
ipsw...@apk.net
<brad.k...@skynet.be> wrote:
>At 4:02 PM +0000 2002/03/24, Andrew Boothman wrote:
>
>> I was interested about what you said about qmail and its author.
>> I've recently started playing with qmail to investigate what mail
>> server I prefer, but I agree that there is perhaps something a
>> little strange about its author. I don't know what, perhaps its
>> just that I find qmail.org such a weird site.
>
> The author of qmail is rightly considered to be one of the most=20
>whacked-out kooks on the 'net.
Dan's definitely not RFC-compliant. :-)=20
> I've been on IETF mailing lists with him, and his attitude is=20
>always that he is always right (by definition) and everyone else is=20
>always wrong (by definition). He insists on replying to each and=20
Dan not only invented TCP/IP and the Internet, but he also invented
Unix and Al Gore.
I don't like Dan's personality and I find some of his ideas strange.
But there seem to be some good ideas in there, and he does write
pretty solid code.
However.... :-) I saw a comment that Qmail doesn't work properly on
Solaris. So, of course, Solaris is broken. And Qmail didn't work right
with ReiserFS, so of course ReiserFS was broken.
I also kind of picture Dan burning Weitse Venema dolls whenever
there's a new moon.
ipsw...@apk.net
<brad.k...@skynet.be> wrote:
>need that last 1% it doesn't yet do. Moreover, postfix has the=20
>simplest configuration language that I have ever seen for any=20
>program, and the largest set of "sane but secure" defaults -- It is=20
>entirely possible to have a fully functional postfix installation=20
>where the entire configuration file is just two lines long.
Agreed.
>> beginning to start up a webhosting service with virtual domain =
hosting with
>> full e-mail services and qmail was frankly the only package out there=
with
>> the commitment and features that seemed close to my liking. I was =
also
>> looking at the other tools out there that I could slap on top of =
qmail to
>> make it more functional (vpopmail, sqwebmail, etc).
>
> Granted, there are a number of add-on features that have been=20
>created for qmail. I believe that it is possible to duplicate those=20
There are a lot of tempting add-ons, but when you start looking at
them you find that it becomes a nightmare. 95 different patches from
different places and who knows when one patch will break another one
and where the fingers get pointed in blame.
Some of the add-on authors also have strange ideas about how to do
things. (Courier is pretty weird, for example.)
>
> However, this is the real power of the Unix "toolbox" philosophy=20
>-- you can put the tools together that you want, in most any way you=20
>want, making the result do just about whatever you want.=20
>Unfortunately, Dan breaks this philosophy by tightly integrating all=20
>his tools together, and making it so that they are all=20
>interdependent. For example, you can't use the standard inetd that=20
I seem to remember running qmail behind inetd a few years back. I
don't remember how well it worked or what was needed to get it to work
though.
> If qmail does everything you need and does it in a way that you=20
>can comprehend, then you would be pretty foolish to just throw all=20
>that away because of personality issues with the author.
I decided to play with qmail and djbdns on one box, although I run
postfix on my other machines. They're small and lightweight, and (once
you figure out the method behind the madness) they're pretty easy to
configure and maintain.
Tcpserver is arguably less complex than inetd and tcpwrappers. Other
people don't like inetd as evidenced by replacements for it.
Supervise has some interesting features.
That whole /package thing is pretty bizarre though. I think Dan wasn't
taking his medicine when he cooked that one up.
What do we run on our production boxes? Sendmail and BIND, tcpwrappers
and inetd. :-)
<shrug> Use what works well for you and move on to the next task.
t...@sleepy.wojomedia.com
> <shrug> Use what works well for you and move on to the next task.
That's what 99% of us do. The other 1% writes brilliant software or
bitches about other people doing it. ;-)
Tim
tlam...@mindspring.com
> Having helped prolonged this thread, I feel obligated to at least
> point out http://cr.yp.to/djbdns/knowles.html
Where is the page that linked to this page, please? I'd like
to see who else is (in)famous...
-- Terry
brad.k...@skynet.be
> Having helped prolonged this thread, I feel obligated to at least
> point out http://cr.yp.to/djbdns/knowles.html
Given the lies we've seen from Dan in the past, I won't bother to
waste my time with this page.
--
Brad Knowles, <brad.k...@skynet.be>
Do you hate Microsoft? Do you hate Outlook? Then visit the Anti-Outlook
page at <http://www.rodos.net/outlook/> and see how much fun you can have.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
t...@sleepy.wojomedia.com
between Dan and Brad, I would've stayed out of the conversation
altogether. ;-)
Tim
tlam...@mindspring.com
> At 8:02 PM -0600 2002/03/27, Tim wrote:
> > Having helped prolonged this thread, I feel obligated to at least
> > point out http://cr.yp.to/djbdns/knowles.html
>
> Given the lies we've seen from Dan in the past, I won't bother to
> waste my time with this page.
I still want to know where the link came from.
I also want to know how it is you can slander against a program
or other object which is not a legal entity like a person or a
corporation. ;^). But I'll save asking that for later...
-- Terry
ipsw...@apk.net
<brad.k...@skynet.be> wrote:
>> the qmail user community is more than sufficient for support.
>
> Riiiiiiiiiiiiiight. Just like C makes a perfectly good macro language.
There _are_ quite a few zealots in the "qmail user community," but
that's true of other groups too. Linux vs. FreeBSD anyone?
>have given classes on DNS for the company Men & Mice, using material=20
>written by Cricket Liu (and I will be doing so again at SANE 2002).=20
Men & Mice has some neat stuff.
I suppose I should also point out that BIND is the basis for several
commercial products. (Cisco Network Registrar, Metainfo's MetaIP, and
I believe also QIP that Lucent picked up. It's also part of Nixu
Namesurfer. Men & Mice put it to good use too. :-)
Postfix and Sendmail are also being used in a number of places. Qmail
is not. (I think this is a licensing issue since Dan thinks he knows
better than you how your filesystem should be laid out and is very
restrictive about distributing binaries unless you toe that line.)
>and qmail ranks below dog poop in my book. IMO, you would literally=20
>be better off flinging canine excrement than using qmail.
I won't go quite _that_ far, but I can understand why you feel this
way.
> However, unless you are willing and able to function on this=20
>level, I doubt that there is anything you're likely to bring to this=20
>debate that I would find useful or interesting.
Agreed. Those "Sendmail sucks and Qmail rulez d00d! responses don't do
much for me.
ipsw...@apk.net
wrote:
>On Wed, Mar 27, 2002 at 09:45:47PM -0500, Stuart Krivis wrote:
>> <shrug> Use what works well for you and move on to the next task.
>
>That's what 99% of us do. The other 1% writes brilliant software or
>bitches about other people doing it. ;-)
Brilliant software? Re-inventing the wheel just for the sake of
re-inventing is not brilliant. Requiring the world to conform to your
ideas is not brilliant.=20
Just as an example, tcp wrappers is brilliant software. It does
exactly what is needed and it also plugs right in to the way you were
already doing things. Ssh was/is also brilliant software. Ditto for
the shadow password suite.=20
ipsw...@apk.net
wrote:
>
>Brad could very much be right in the end. He just couldn't get
>past his DJB hatre to provide any real merits in his argument (like
>judging software base on ease of configuration and the size of the
>configuration file - what was that all about?). I am not surprised,
It sounded valid to me. I actually prefer software that is easy to
configure and doesn't need 30 million statements in 19 different
config files scattered all over. (And I'm not inferring that qmail is
hard to configure or that it needs wildly complex config files.)
ipsw...@apk.net
<brad.k...@skynet.be> wrote:
> Sigh.... It looks like I'm going to have to publicly post my=20
>list of 18 things that I have found wrong so far with djbdns, as=20
>opposed to simply sending it privately to a few individuals. So be=20
>it:
I'm glad that you did. It is very informative.
p...@ehlke.net
>
> I still want to know where the link came from.
>
uhhh... predictable.
-Pete
--
"religious fanatics are not part of my desired user base."
- d...@cr.yp.to
t...@sleepy.wojomedia.com
argument about what constitutes brilliant software. If *you* think
any piece of software is brilliant, good for you. I shall quote you:
<shrug> Use what works well for you and move on to the next task.
Tim
On Thu, Mar 28, 2002 at 04:41:14AM -0500, Stuart Krivis wrote:
> On Wed, 27 Mar 2002 20:48:44 -0600, Tim <t...@sleepy.wojomedia.com>
> wrote:
>
> >On Wed, Mar 27, 2002 at 09:45:47PM -0500, Stuart Krivis wrote:
> >> <shrug> Use what works well for you and move on to the next task.
> >
> >That's what 99% of us do. The other 1% writes brilliant software or
> >bitches about other people doing it. ;-)
>
> Brilliant software? Re-inventing the wheel just for the sake of
> re-inventing is not brilliant. Requiring the world to conform to your
> ideas is not brilliant.
>
> Just as an example, tcp wrappers is brilliant software. It does
> exactly what is needed and it also plugs right in to the way you were
> already doing things. Ssh was/is also brilliant software. Ditto for
> the shadow password suite.
To Unsubscribe: send mail to majo...@FreeBSD.org
tlam...@mindspring.com
> On Wed, Mar 27, 2002 at 11:20:08PM -0800, Terry Lambert wrote:
> >
> > I still want to know where the link came from.
> >
> Dan posted it to the djbdns mailing list. The response there has been...
> uhhh... predictable.
Darn. I was hoping for a public rogue's gallery... defaced
pictures, images of hanged effigies, that sort of thing. 8-).
-- Terry
p...@ehlke.net
>
> Darn. I was hoping for a public rogue's gallery... defaced
> pictures, images of hanged effigies, that sort of thing. 8-).
>
ftp client that can parse the obscene output that his ftp server
generates, you might be able to find some of it by poking around his
site.
-Pete, proud to have been called an idiot by djb.
--
"religious fanatics are not part of my desired user base."
- d...@cr.yp.to
To Unsubscribe: send mail to majo...@FreeBSD.org
rs...@online.fr
> > Darn. I was hoping for a public rogue's gallery... defaced
> > pictures, images of hanged effigies, that sort of thing. 8-).
> >
> Heh. Dan's rogue's gallery is obfuscated and distributed. If you have an
> ftp client that can parse the obscene output that his ftp server
> generates, you might be able to find some of it by poking around his
> site.
I found the following:
http://cr.yp.to/qmail/knowles.html (I assume the original comment here
was tongue-in-cheek...)
http://cr.yp.to/qmail/warfield.html
http://cr.yp.to/qmail/jackson.html
http://cr.yp.to/qmail/venema.html...
R
re...@reedmedia.net
> http://cr.yp.to/qmail/jackson.html
DJB says "The largest Exim host is doing a mere 50000 deliveries per day."
The publically available Exim users mailing list archives show a lot
more. For example:
"... we use an old SparcStation 20 to ship around 60,000 emails a day and
according to the exim stats 98% of those are shipped in under a minute.
The load average on the machine is next to nothing to the extent that I
get paranoid if it ever approaches one."
(<2000071409...@apple.ukc.ac.uk>)
"... My server processes 50,000 to 100,000 messages a day and every one
of those passes through a filter that currently contains 200 rules,
mostly regex matches (checks for worms and viruses, scores potential
spam, etc.) Server load hovers around 0.30 (FreeBSD, Pentium III 400MHz)
with the odd "spike" to 1.0 or so."
(<m15gs9c...@island.islandnet.com>)
"Under exim, I put about 5GB (bytes not bits) from one machine between
8pm and 9am. That is over one million outbound emails in 12 hours. You
do the math. That is a lot of traffic and is on a small dual processor
PIII with a single SCSI disk (no stripe for the spool). ..."
(<396C78B5...@cnds.jhu.edu>)
(The same admin also says:)
"... We deliver about 1.5 million message/day on any given machine.
But, we don't push mail between 11am and 8pm (only 8pm to 11am)."
There are many other documented.
Someone should make a "DJB's slander (his word) against ..."
Jeremy C. Reed
http://www.reedmedia.net/
rag...@sysabend.org
:Pete Ehlke wrote:
:> On Wed, Mar 27, 2002 at 11:20:08PM -0800, Terry Lambert wrote:
:> >
:> > I still want to know where the link came from.
:> >
:> Dan posted it to the djbdns mailing list. The response there has been...
:> uhhh... predictable.
:
:Darn. I was hoping for a public rogue's gallery... defaced
:pictures, images of hanged effigies, that sort of thing. 8-).
Give him time.
Jamie Bowden
--
"It was half way to Rivendell when the drugs began to take hold"
Hunter S Tolkien "Fear and Loathing in Barad Dur"
Iain Bowen <ala...@alaric.org.uk>
kera...@ceid.upatras.gr
: On Thu, 28 Mar 2002, Terry Lambert wrote:
: :Darn. I was hoping for a public rogue's gallery... defaced
: :pictures, images of hanged effigies, that sort of thing. 8-).
:
: Give him time.
No, hell no. People with too much time in their hands tend to write code.
/me ducks and runs
- Giorgos
brad.k...@skynet.be
> I found the following:
> http://cr.yp.to/qmail/knowles.html (I assume the original comment here
> was tongue-in-cheek...)
> http://cr.yp.to/qmail/warfield.html
> http://cr.yp.to/qmail/jackson.html
> http://cr.yp.to/qmail/venema.html...
Cool! I rank up there with Wietse? Excellent!
--
Brad Knowles, <brad.k...@skynet.be>
Do you hate Microsoft? Do you hate Outlook? Then visit the Anti-Outlook
page at <http://www.rodos.net/outlook/> and see how much fun you can have.
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
t...@sleepy.wojomedia.com
freely distributable." 1.03 was released in 1998, I believe.
For those that care, Dan hasn't updated this page recently. He did
take Terry's suggestion and remove "against qmail/djbdns" on the
other pages (now just _Brad Knowles's Slander_, for example).
Tim
d...@cr.yp.to
per day'' was accurate when I wrote it several years ago. Of course, it
is out of date now.
I apologize for not labelling the comment with a date when I first wrote
the page. I hope nobody has been misled. I've fixed the page now.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
tlam...@mindspring.com
> My comment that ``The largest Exim host is doing a mere 50000 deliveries
> per day'' was accurate when I wrote it several years ago. Of course, it
> is out of date now.
>
> I apologize for not labelling the comment with a date when I first wrote
> the page. I hope nobody has been misled. I've fixed the page now.
Rough consensus and working code.
I don't think anyone really gives a hoot about the dates; they
are just looking for things to nit-pick. 8-).
-- Terry
rs...@online.fr
> > I found the following:
> > http://cr.yp.to/qmail/knowles.html (I assume the original comment here
> > was tongue-in-cheek...)
> > http://cr.yp.to/qmail/warfield.html
> > http://cr.yp.to/qmail/jackson.html
> > http://cr.yp.to/qmail/venema.html...
>
> Cool! I rank up there with Wietse? Excellent!
Actually, Wietse is linked from his main pages, I don't think you are
:)
Well, I use qmail and other DJB stuff myself, and like it. (No idea
about its security and performance and all, my needs are modest, but I
found it was easy to set up and extremely well documented.) I also
agree with him that if you accuse him, on a public mailing list, of
ignoring bug reports/security holes, you should say what they are.
The only one I'm aware of, which Wietse pointed out years ago and
continues to harp on, is the memory exhaustion thing, which in Dan's
opinion is the job of the operating system and not the MTA (though I
guess he should have fixed his docs to discuss the problem, at least).
And his license is a problem too, of course -- this was #17 on your
list of complaints. But he doesn't forbid redistribution of source
code and he doesn't forbid distribution of patches, so it's really a
problem only for binary distributors like Red Hat...
R
p...@ehlke.net
>
> agree with him that if you accuse him, on a public mailing list, of
> ignoring bug reports/security holes, you should say what they are.
OK, here's one. Dan's authoritative server, tinydns, is designed to only
respond to iterative queries. It is, by design, incapable of providing
recursion. It also, by design, does not serve hesiod or chaos class
records.
I identified a bug in tinydns related to how it responds to hesiod and
chaos queries. tinydns and dnscache (dan's recursive server) share the
code path that initializes query responses. The code initializes every
response with the RA and RD bits set, and tinydns resets those bits.
However, it resets them *after* validating the query class. The end
result is that tinydns incorrectly sets the RD and RA bits on
non-recursive queries in the hesiod and chaos classes.
Dan's response to this bug is that tinydns is only designed to serve
internet class records, and thus querying it for other classes is user
error.
This was a simple bug, easily fixed. It doesn't break anything, but the
error is clear, and fixing it would involve nothing more than admitting
that he had made a coding error. But Dan can't do that. He'd rather
insist that he *intends* to return bogus information than fix a trifling
little bug.
Note for QA folks: when the developer says "That's not a bug, you're using
it wrong", you are dealing with the worst sort of arrogant prima donna.
-Pete
--
"religious fanatics are not part of my desired user base."
- d...@cr.yp.to
To Unsubscribe: send mail to majo...@FreeBSD.org
tlam...@mindspring.com
> Note for QA folks: when the developer says "That's not a bug, you're using
> it wrong", you are dealing with the worst sort of arrogant prima donna.
I've spent a lot of time at one employer or another fixing things
that weren't problems because a Q/A person tried to use the product
to fulfill a role for which it was never designed, and for which
it was never intended to be marketed.
When doing Q/A, you need to make sure that what you are testing
falls within the set of use cases for the product, and isn't
some oddball configuration which can never happen unless you
give the end users more access to your box than they can normally
achieve using any combination of the permissable UIs (GUI, CLI,
initial configuration, "wizards", etc.).
You also have to realize that discovering a boundary condition
isn't really enough to prevent shipping the product:
"Eventually, a software comapny has to ship software."
-- Greg Haerr
Your best developer in any group of developers can probably tell
you dozens of degenerate cases that will cause your product to
perform badly and/or to fail outright. Some public tests (e.g.
"Polygraph") are *designed* to adaptively find the worst case
performance scenario for any product, and then exercise it.
Then you end up with assinine things like "random page replacement"
to become unpredictable to these tests, and get better numbers,
which are only better numbers on the benchmark, since they throw
out things that would optimize real world use of the product, like
locality of reference.
Some Q/A people also feel that they have failed at their job,
unless they have crashed the product. So they come up with
tests that can crash the product in 24 hours: using something
like an "Avalanche" or other purpose-built test equipment, over
a gigabit network, they crash a product after a little over 24
hours. In the real world, assuming that the problem is stress
related, rather than overload boundary related (a bad assumption),
this failure may happen once every 3 months, given real world load
generating capacity over a couple of OC3's is a hell of a lot less
than a colocated box built to do nothing but generate load.
So while it's true that it's stupid for someone to claim that
something is not a bug, in the case of manual configurations
at a root prompt, perhaps it's not a bug. And for boundary
conditions under unrealistic load on unrealistic configurations,
it may be a bug... but just because it is severity 1, doesn't
mean that it's priority 1: if a user will never see it, it has
zero priority, no matter what it does to the box.
In fact, if people take one lesson from this thread, it should
be this: severity is not the same things as importance, is not
the same thing as priority.
There's a process called "requirements tracking"; it keeps
people from implementing things customers aren't asking for,
and it keeps people from testing things in ways that are not
harmonious with how customers will actually use the product.
Dan was wrong to claim that it wasn't a bug (I can see his reasons
for wanting to make this claim, given his "posted reward" thing),
but it was equally wrong to expect the code to work in that
configuration for which it was never designed: I never expect my
car to work in the water, or my boat to work on the freeway, even
though both are vehicles...
At some point, you have to cut your losses, and say that "the user
is attempting to use the product for a purpose for which it was
never designed, Sorry".
-- Terry
rs...@online.fr
> Dan was wrong to claim that it wasn't a bug (I can see his reasons
> for wanting to make this claim, given his "posted reward" thing),
Um, that reward is specifically for security holes, not for any old
bug:
http://cr.yp.to/djbdns/guarantee.html
The same with qmail --
http://cr.yp.to/qmail/guarantee.html
benj...@macguire.net
> Terry Lambert wrote:
> > Dan was wrong to claim that it wasn't a bug (I can see his reasons
> > for wanting to make this claim, given his "posted reward" thing),
>
> Um, that reward is specifically for security holes, not for any old
> bug:
>
> http://cr.yp.to/djbdns/guarantee.html
>
> The same with qmail --
> http://cr.yp.to/qmail/guarantee.html
Its a charlatan's promise. He fails to define security, or bug, or anything
else really, and retains the right to define it at a later time (preferably
after you've already reported it). If a company were to offer to pay you for
your services in finding bugs, but not define bug or security, and after many
years nobody was ever able to get a successful claim out of them despite
getting many submissions, it would be called Fraud.
--
Benjamin Krueger
"Life is far too important a thing ever to talk seriously about."
- Oscar Wilde (1854 - 1900)
----------------------------------------------------------------
Send mail w/ subject 'send public key' or query for (0x251A4B18)
Fingerprint = A642 F299 C1C1 C828 F186 A851 CFF0 7711 251A 4B18
tlam...@mindspring.com
> Terry Lambert wrote:
> > Dan was wrong to claim that it wasn't a bug (I can see his reasons
> > for wanting to make this claim, given his "posted reward" thing),
>
> Um, that reward is specifically for security holes, not for any old
> bug:
>
> http://cr.yp.to/djbdns/guarantee.html
>
> The same with qmail --
> http://cr.yp.to/qmail/guarantee.html
IMO, such a guarantee is indicative of a philosophy that doesn't
admit error (sorry).
-- Terry
t...@sleepy.wojomedia.com
> At 8:02 PM -0600 2002/03/27, Tim wrote:
>
> > Having helped prolonged this thread, I feel obligated to at least
> > point out http://cr.yp.to/djbdns/knowles.html
>
> Given the lies we've seen from Dan in the past, I won't bother to
> waste my time with this page.
But somehow you found the time to publish an 18 point list
to freebsd-chat about qmail and djbdns...
Tim
benj...@macguire.net
> On Thu, Mar 28, 2002 at 04:25:06AM +0100, Brad Knowles wrote:
> > At 8:02 PM -0600 2002/03/27, Tim wrote:
> >
> > > Having helped prolonged this thread, I feel obligated to at least
> > > point out http://cr.yp.to/djbdns/knowles.html
> >
> > Given the lies we've seen from Dan in the past, I won't bother to
> > waste my time with this page.
>
> But somehow you found the time to publish an 18 point list
> to freebsd-chat about qmail and djbdns...
>
> Tim
Which he previously mentioned was pre-fabricated. This is getting a bit silly,
methinks.
--
Benjamin Krueger
"Life is far too important a thing ever to talk seriously about."
- Oscar Wilde (1854 - 1900)
----------------------------------------------------------------
Send mail w/ subject 'send public key' or query for (0x251A4B18)
Fingerprint = A642 F299 C1C1 C828 F186 A851 CFF0 7711 251A 4B18
To Unsubscribe: send mail to majo...@FreeBSD.org
t...@sleepy.wojomedia.com
> methinks.
First, this is -chat. We are allowed to be silly, I believe.
Second, he also said he welcomes factual corrections but then waives
his hand over all of Dan's response.
Third, so what if it was pre-fabricated?
Tim
brad.k...@skynet.be
>> Given the lies we've seen from Dan in the past, I won't bother to
>> waste my time with this page.
>
> But somehow you found the time to publish an 18 point list
> to freebsd-chat about qmail and djbdns...
I've had it for a while -- it was something I came up with as
part of my work for a book deal that never materialized. Indeed, the
complete list is now up to twenty-four (or something like that), but
I have not yet had an opportunity to integrate the newer issues with
the older list.
Cut-n-paste is not all that hard or time-consuming. ;-)
--
Brad Knowles, <brad.k...@skynet.be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
brad.k...@skynet.be
> Second, he also said he welcomes factual corrections but then waives
> his hand over all of Dan's response.
If *you* give me corrections, or someone else on this list gives
me corrections, I am likely to pay attention.
However, given what we know of Dan and his lies (including libel
and slander of his own) in the past, I am not inclined to try to wade
through his latest propaganda to see if there might be the smallest
tiny sub-atomic kernel of truth (surely accidental) in his claims.
--
Brad Knowles, <brad.k...@skynet.be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
t...@sleepy.wojomedia.com
> > Second, he also said he welcomes factual corrections but then waives
> > his hand over all of Dan's response.
>
> If *you* give me corrections, or someone else on this list gives
> me corrections, I am likely to pay attention.
Beep. You already told me that unless I can show experience
or talent similar to yours, you don't believe I would have anything
to add. Since I can never have your talent for obfuscation, I shall
respectifully bow out of this conversation.
Tim
brad.k...@skynet.be
>> If *you* give me corrections, or someone else on this list gives
>> me corrections, I am likely to pay attention.
>
> Beep. You already told me that unless I can show experience
> or talent similar to yours, you don't believe I would have anything
> to add.
Sufficient talent or experience is required if you want to try to
add something new to the topic as a whole. Providing corrections
does not necessarily require adding something new to the topic.
--
Brad Knowles, <brad.k...@skynet.be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
d...@cr.yp.to
> The only one I'm aware of, which Wietse pointed out years ago and
> continues to harp on, is the memory exhaustion thing, which in Dan's
> opinion is the job of the operating system and not the MTA
Yes, I think it's the OS's job. The OS itself agrees with me. The UNIX
kernel, with the cooperation of the standard shells, gives the sysadmin
configurable, easy-to-use per-process memory rlimits.
Reinevnting the same feature by adding separate code to every program to
impose artificial limits on every dynamically allocated structure for
network data is remarkably bad engineering.
Last November, years after I made these comments on my web pages,
someone discovered that Venema had forgotten to put an artificial limit
on Postfix's dynamically allocated session log. Consequently an attacker
could trivially convince Postfix's smtpd to use all available memory.
Did Venema scream that Postfix had ``A BUG'' that ``made'' systems
``vulnerable to memory exhaustion attacks''? Did he post an ``exploit''
for this Postfix ``BUG''? Did he try to have Postfix entries added to
vulnerability databases? Did he admit that his approach was vastly more
complicated and error-prone than system resource limits? No, he didn't.
I spend quite a bit of time analyzing system failures and investigating
how they could have been prevented by better programming practices---
preferably practices that also save time for the programmers. Frankly,
in this case, there's no contest.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
To Unsubscribe: send mail to majo...@FreeBSD.org
d...@cr.yp.to
> Its a charlatan's promise. He fails to define security, or bug, or anything
> else really, and retains the right to define it at a later time (preferably
> after you've already reported it). If a company were to offer to pay you for
> your services in finding bugs, but not define bug or security, and after many
> years nobody was ever able to get a successful claim out of them despite
> getting many submissions, it would be called Fraud.
There have been zero submissions for the qmail security guarantee. There
have been zero submissions for the djbdns security guarantee.
The documentation in the very first qmail release pointed out that there
are many remote denial-of-service attacks on Internet mail. Later, when
I offered a security guarantee, I quite clearly excluded those attacks.
(15 January 1997: ``Some holes that don't qualify: corrupting DNS data;
breaking TCP/IP; breaking NFS; denying service.'')
If you think that Venema submitted his ``attack,'' or that my comments
on the stupidity of his ``attack'' are the only reason that the security
guarantee remains unclaimed, you are massively confused.
Furthermore, I find it strange that you allude to the sentence ``My
judgment is final as to what constitutes a security hole in djbdns''
from http://cr.yp.to/djbdns/guarantee.html without even mentioning the
next sentence: ``Any disputes will be reported here.''
You also neglect to mention that my web page names four broad classes of
security holes, with three examples of specific BIND bugs (1998 IQUERY,
1999 NXT, 2001 TSIG) as illustrations. There are no disputed examples,
so there's no point in writing a more comprehensive definition.
p...@ehlke.net
>
> Did Venema scream that Postfix had ``A BUG'' that ``made'' systems
> ``vulnerable to memory exhaustion attacks''? Did he post an ``exploit''
> for this Postfix ``BUG''? Did he try to have Postfix entries added to
> vulnerability databases? Did he admit that his approach was vastly more
> complicated and error-prone than system resource limits? No, he didn't.
>
Exactly what part of self reporting this to bugtraq, and describing it
himself as a "stupid error" does not count as 'scream[ing] that Postfix had
``A BUG'' that ``made'' systems ``vulnerable to memory exhaustion
attacks'' '?
-Pete
--
"religious fanatics are not part of my desired user base."
- d...@cr.yp.to
To Unsubscribe: send mail to majo...@FreeBSD.org
m...@thales.memphis.edu
+news:<a7mjt6$1jk6$1...@FreeBSD.csie.NCTU.edu.tw>...
> Just try having a two-line configuration file for any other
> program on the planet.... Okay, any other general-purpose MTA. ;-)
rm /var/qmail/control/*
echo a.csi.hu > /var/qmail/control/me
echo a.csi.hu > /var/qmail/control/rcpthosts
kill -HUP qmail-send
Mate
--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
tlam...@mindspring.com
> > 1. By default, tinydns does not hand out referrals to questions it
> > is asked about zones it does not control. I believe that this
> > violates the spirt of the RFCs, if not the letter.
>
> If the sysadmin wants, she can simply change the data file on the fly
> for tinydns to give out (root) referrals.
>
> But what do self respecting clients do with referrals? Are they
> treated as trustworthy? What does BIND do with root referrals? Why?
In Japan, they charge you for sending packets, so there is
practically no such thing as an exterior forwarding name
server, of the type that you find at most ISPs in the US.
In fact, fi you are an NTT customer, you will be charged
a monthly fee for forwarding DNS requests through one of
their servers, or you will be firewalled from doing so.
So the answer to the question is "the self respecting client
then contacts the server directly, thus paying for their own
packets, since intermediary relays are few and far between".
Yes,, this violates the spirit of fault tolerance in the
design of the Internet, but, hey, it's not the U.S. that
can have most of its hosts dropped off by one or two well
places bombs, so who cares what they do to themselves in
the name of a strange revenue model?
> > 2. By default, tinydns does not support the use of TCP at all. This
> > most definitely violates the spirt of the RFCs, as well as the
> > letter (if a DNS query via UDP results in truncation, you're
> > supposed to re-do the query using TCP instead).
> >
> > Indeed, if you want to support TCP under tinydns, you have to
> > configure an optional program called "axfrdns", which was
> > intended to handle zone transfers, but also happens to share the
> > same database as tinydns, and can handle generic TCP queries.
>
> Note that no "MUST" rule is violated.
A violation of a "SHOULD" is almost worse than a violation of
a "MUST". A violation of a "MUST" has recourse: it's a bug.
A violation of a "SHOULD" has no recourse.
The problem with this is that it violates the Principle Of
Least Astonisment (POLA); specifically, it violates the
dictum that one should be generous in what one accepts, but
strict about what one generates, with regard to protocols.
Not accepting a "SHOULD" mandated request is hardly generous.
> And if the sysadmin needs DNS over TCP, she just looks at
The problem with this, as has been pointed out before, is
multiple bindings to the same port are not possible on the
same machine. For this to work in conjunction with other
services that are normally considered part of the DNS, you
must implement a MUX. It's possible to do this with the
djbdns code; it just hasn't been done yet by anyone.
> > 3. The suggested method for copying contents of DNS zones is rsync,
> > scp, or other remote copy tools. The DNS standard method of
> > zone transfers (query type "axfr") is only supported as an
> > additional, disrecommended method.
>
> Realizing the disadvantages of "axfr", the djbdns package allows the
> sysadmin to use other, more secure, reliable and readily available
> tools _in addition to_ "axfr". What is wrong with this flexibility?
Firewalls.
> > 5. Without a patch from a third party, tinydns does not support the
> > standard "NOTIFY" protocol of informing secondary nameservers
> > that the zone has been updated, and that they need to check the
> > SOA serial number and download a new copy (if they don't already
> > have it).
>
> Which rfc describing the DNS standards requires NOTIFY?
RFC 1996.
> Is it more reliable, better, secure, faster, than rsync over ssh?
yes. yes. depends. yes.
> Consider, for example, the fact that presently NOTIFY can alert
> clients only about SOA record changes, and hence even if only a single
> A record was added to the master's data, the client will have to
> download the whole zone. At least this is my reading of rfc1996.
>
> Using rsync, of course, makes it possible to do only incremental
> updates.
The issue isn't about the amount of data that has to be
transferred, it's about the stall barrier, when any data
has to be reloaded.
> I am not saying that, in case of a non-trusting slave, there might not
> be a need for a safe, reliable, etc way for a master server to
> initiate a data file update (instead of a polling by the slave), but
> this looks more like a problem that has nothing to do with the DNS
> protocol.
Here's my argument:
"All DNS data transfers should take place over the
DNS protocol."
> In case of a trusting slave, though, rsync will push the changes over
> to the slave as soon as they happen on the master.
Plus the notice latency on the master, as the changes are polled,
rather than event-triggered, plus the notice latency on the slave,
for the same reasons.
This is actually hidden in djbdns, because of the reopening
of the file each time. This reopening is another synchornization
barrier, due to POSIX time update requirements.
> > 7. You cannot set an alternative SOA contact address (other than
> > what is hard-coded within tinydns), if you do not have a patch
> > from a third party.
>
> Those who read the docs can see
I believe he's referring to additional data, rather than replacement
data, here...
> > 9. Because they are separate programs, you can't have both tinydns
> > and dnscache listening to the same IP address(es) on the same
> > server.
> >
> > While this is not the recommended mode of configuration, some
> > sites don't have the luxury of having separate
> > authoritative-only and caching/recursive-only server(s), and
> > need to mix them both on one machine (or set of machines). With
> > the BIND 9 "view" mechanism, this is relatively easy to do.
> > With djbdns, this is impossible.
>
> I wonder which sites need to run tinydns on one public IP and an
> external cache for their customers on another public IP, but cannot
> afford them. I would think most of these small companies would need
> the external cache for their private network, and then all they need
> is just a $30 network card. Not a high price to pay for the added
> security.
The answer to this is tied up in the complexity of configuring
the system from derived data.
Basically, any dialup gateway device will have these attributes,
since the interior exterior DNS needs to be secondary to an
externally transiently connected DNS server, whereas the interior
interior DNS needs to treat the exterior interior as a forwarder
(see the issue Brad raised in regard to this).
Basically, it doesn't map the entire problem space.
Examples of these devices include, but are not limited to:
Encanto
IBM (Whistle) InterJet
Microsoft Back Office Gateway
Cobalt Qube
etc. (Ricoh, NTT, DEuth Telekom, Nortel, Indigo, etc.).
I actually wrote three RFC Drafts on the problems of these
devices. Bind 9 addresses 2 of the 3 (admittely, in an incredibly
arcane way, in one case...).
> We are looking at two only, so they must be the major ones.
>
> > A. When an IQUERY is sent to a djbdns server, it will
> > respond with opcode set to QUERY. (it should simply
> > copy the opcode, not make something up).
>
> Which currently in use client sends IQUERY? What does the 01/2002 draft
>
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-obsolete-iquery-03.txt
>
> say about IQUERY?
Whatever it says is irrelevent, until it is Standards Track.
> > B. DNSCACHE (the caching server) does not respond to
> > queries with the RD bit clear in the query. (Instead
> > of simply answering from cache without recursing
> > the dns-tree).
>
> What does a client want from a recursive server when it sends such a
> query? Does BIND really answer from the cache?
In the case of the dial-on-demand gateway device, it wants to
forward requests for a zone for which it must interiorly act
as if it were authoritative, but for which an exterior DNS
querent finds that it is not (such devices, by their transiently
connected nature, are not permitted to be listed as authoritative).
A common case of this is the DSL connected server at a small
business; DSL connections are currently untrustworthy: they
are nothing to bet your business on. So certain externally
visible services (web hosting, secondary SMTP queue-only
services, DNS services, etc.) must be externally hosted.
The point is to make it work all the time.
Again, this is an issue of whether or not a given product
maps the entire problem domain, or only a subset. As a
consolation, no product maps the entire problem domain.
> > 11. Unfortunately, there is very little documentation available
> > for djbdns. Whereas for BIND you will discover at least four or
> > five separate books directly related to BIND on Unix (and one
> > for BIND on Windows NT), and at least sixteen different books
> > that are related to the DNS in general (not including books
> > where the DNS forms just a relatively small part of the whole),
> > there are no books available on djbdns.
>
> It indeed seem that an introductory book on DNS that would focus on
> the servers in the djbdns package would be welcome.
I think that this lack is based on a control-of-source issue.
The problem you have when writing a book about software that
you don't control is changes to the software that result in
the validity of your book being damaged.
Since it takes on the order of 2080 hours (a full man year)
to write a technical book of any depth, the result is that
things which change frequently don't get books written about
them, or if they dom the books are quickly outdated to the
point that they no longer sell.
The Sendmail books have fallen into this, as have most Linux
internals books of any reasonable depth. There hasn;t been
a decent FreeBSD internals book, since it's impossible to
even document the boot process, without somone saying "well,
yes, that is a problem; let me fix it", thus screwing your
book out of its subject matter, and making it incorrect.
> Is setting up and running djbdns so complicated that one needs to buy
> a $40 book?
Books legitimize products. We may bemoan that fact, but
doing so does nothing to make it any less of a fact.
> Where can I read about those people who decided the online docs and
> the mailing list were not enough, wanted commercial djbdns support and
> then got disappointed?
The mailing lists for other products? 8-) 8-).
-- Terry
p...@ehlke.net
>
> >
> > 1. By default, tinydns does not hand out referrals to questions it
> > is asked about zones it does not control. I believe that this
> > violates the spirt of the RFCs, if not the letter.
>
> If the sysadmin wants, she can simply change the data file on the fly
> for tinydns to give out (root) referrals.
tinydns drops queries for zones that is not configured to answer for.
The documentation mentions this, but fails to note that not configuring
NS records for . means that the server violates the requirement that
servers return either an answer, an error response, or a referral.
Consequently, virtually no tinydns installations other than Dan's are in
compliance with the requirement. This isn't strictly a problem with the
code; I'd point my finger more at the documentation. One has to read
Dan's mind fairly deeply at some places, and the fact that almost no
installations of his software get this one right is prima facea evidence
that the documentation is not sufficiently clear.
BIND yells at you if you fail to configure the root zone. tinydns just
goes on its merry way.
> But what do self respecting clients do with referrals? Are they
> treated as trustworthy? What does BIND do with root referrals? Why?
Bzzzzzt. Trick question. You don't get to ignore the RFC just because
you can't find the benefit in following it.
>
> > 2. By default, tinydns does not support the use of TCP at all. This
> Note that no "MUST" rule is violated. And if the sysadmin needs DNS
> over TCP, she just looks at
>
Again, the documentation is unclear on this point. Many people are, for
whatever reason, deluded into believing that TCP is only needed if one
needs to support AXFR. Any DNS query may be made over TCP, and those who
are not capable of responding are shooting themselves in the foot and
undermining the robustness of the global dns. The fact that Dan makes it
optional, and extra work, to support TCP queries contributes to a more
fragile dns.
> Realizing the disadvantages of "axfr", the djbdns package allows the
> sysadmin to use other, more secure, reliable and readily available
> tools _in addition to_ "axfr". What is wrong with this flexibility?
>
The problems with the out of band methods are: firewalls and key
management. If I'm an ISP or a hosting provider managing thousands of
zones for my customers, and I slave many of those zones off the
customer's servers (and this is not exactly uncommon, particularly for
in-addr.arpa), the morass of firewall ACLs and RSA keys that Dan's
scheme forces me into is a nightmare. Note that Dan seems to understand
the problems of key management when it comes to DNSSEC, but is blind to
the operational implications of asking providers to manage ACLs and keys
for hundreds of thousands of customer zones.
And how many djbdns installations can you point to that use axfr?
>
> Which rfc describing the DNS standards requires NOTIFY? Is it
>
That would be RFC 1996.
> Consider, for example, the fact that presently NOTIFY can alert
> clients only about SOA record changes, and hence even if only a single
> A record was added to the master's data, the client will have to
> download the whole zone. At least this is my reading of rfc1996.
Bzzzt again. Use IXFR.
> > A. When an IQUERY is sent to a djbdns server, it will
> > respond with opcode set to QUERY. (it should simply
> > copy the opcode, not make something up).
>
> Which currently in use client sends IQUERY? What does the 01/2002 draft
>
Doesn't matter. The RFC says that support for IQUERY is optional, but
servers must return a NOTIMP response if they choose not to support
IQUERY. Dan's coding practice led him to overlook the necessity of
setting an *appropriate* response to the query received instead of
simply returning a response to the set of queries he thinks one of his
servers *should* see.
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-obsolete-iquery-03.txt
> say about IQUERY?
>
Red Herring. It's a draft, and not Standards Track.
The basic problem with Dan's software, and djbdns in particular,
is that he long ago made a fundamental decision in his outlook to ignore
Postel's advice from RFC 973. Dan decides what, in the Ideal World Of
Dan, his servers *should* see, if everyone were benign, all
implementations were bug free, and everyone everywhere did things The
DJB Way. Then, at best he ignores everything else, and at his worst he
deliberately returns outright bogus data. This is not how one builds a
robust network, and it creates systems that are horribly bad at
interoperability.
-Pete
--
"religious fanatics are not part of my desired user base."
- d...@cr.yp.to
To Unsubscribe: send mail to majo...@FreeBSD.org