Date: Wed, 03 Apr 2002 13:47:12 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: mw-public@csi.hu Cc: freebsd-chat@freebsd.org Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <3CAB7860.EB8DF505@mindspring.com> References: <20020403144539.A11798@thales.memphis.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > 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 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?3CAB7860.EB8DF505>