Date: Wed, 3 Apr 2002 15:31:40 -0800 From: Pete Ehlke <pde@ehlke.net> To: freebsd-chat@FreeBSD.ORG Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <20020403153140.G20012@ehlke.net> In-Reply-To: <20020403144539.A11798@thales.memphis.edu>; from mw@thales.memphis.edu on Wed, Apr 03, 2002 at 02:45:39PM -0600 References: <20020403144539.A11798@thales.memphis.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 03, 2002 at 02:45:39PM -0600, Mate Wierdl wrote: > > > > > 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." - djb@cr.yp.to To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020403153140.G20012>