Date: Wed, 3 Apr 2002 14:45:39 -0600 From: Mate Wierdl <mw@thales.memphis.edu> To: freebsd-chat@freebsd.org Subject: Re: qmail (Was: Maintaining Access Control Lists ) Message-ID: <20020403144539.A11798@thales.memphis.edu>
next in thread | raw e-mail | index | archive | help
brad.knowles@skynet.be wrote in message news:<p05101519b8c51042d9db__10.0.1.8_@ns.sol.net>... > 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: Initially, I thought this message was a pre April first joke. It certainly reads as if the author is impersonating a politician trying to explain his views on technical people's business. Indeed, why else would anybody write a message so heavy with inaccuracies, and downright errors other than to amuse the reader? Why else would anybody write, for example, that one cannot set an alternative SOA contact address for tinydns (the authoritative-only server of the djbdns package) when a single mouse click on the URL http://cr.yp.to/djbdns/tinydns-data.html can prove him wrong? Or why else would anybody write that the best published benchmark for tinydns shows "at least 500 queries per second, but that is the highest number reported" when the reader can just point her mouse at http://marc.theaimsgroup.com/?l=djbdns&m=101414695223959&w=2 and http://marc.theaimsgroup.com/?l=bind-users&m=99315975627678&w=2 to see that he is wrong? Not only that, but the reader can click on http://marc.theaimsgroup.com/?l=bind-users&m=99316718716342&w=2 and see that the very first response arriving at the BIND-users mailing list is from Mr Knowles himself. Actually, this was the point when I realized that the message was not for amusement, and started to suspect that I was facing a post by an author with a curious case of forgetfulness. This suspicion got confirmed when I noticed that this is not the first time Mr Knowles published a list of his amusing objections to the servers in the djbdns package: the reader can just click on http://slashdot.org/articles/01/11/14/0031238.shtml and search for brad to read Mr Knowles's 11/14/2001 article which already contains twelve of his 19 problems with djbdns (19 because there are two labeled by 11). The very first response to Mr Knowles's slashdot article points out, among other things, that the claim of tinydns not supporting SRV records is false; amazingly enough, Mr Knowles repeats this claim as one of his 19 points, and even adds the claim about SOA records. Reading the post, I thought a few more reminders to the available facts cannot hurt, and it may even help in the future. For example: > > 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? > 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. And if the sysadmin needs DNS over TCP, she just looks at $ axfrdns-conf axfrdns-conf: usage: axfrdns-conf acct logacct /axfrdns /tinydns myip and runs the command axfrdns-conf dns dnslog /etc/axfrdns /etc/tinydns 1.1.1.1 to configure axfrdns to run on IP 1.1.1.1 and serve records from tinydns's datafile. Does not seem like a high price to pay for the added flexibility. > 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? > > 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. True. But the sysadmin can run the command for i in `cat -`; do tinydns-conf dns dnslog /etc/tinydns.$i $i echo /etc/tinydns.1.1.1.1/root > /etc/tinydns.$i/env/ROOT ln -s /etc/tinydns.$i /service done to configure and run tinydns on every IP given to its input, and share the the data file with the tinydns running on 1.1.1.1. Equally easily, these tinydns could serve data from their own datafile: just omit the `echo' line above. > 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? Is it more reliable, better, secure, faster, than rsync over ssh? 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. 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. In case of a trusting slave, though, rsync will push the changes over to the slave as soon as they happen on the master. > > 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). Those who read the docs can see :fqdn:n:rdata:ttl:timestamp:lo Generic record for fqdn. tinydns-data creates a record of type n for fqdn showing rdata. n must be an integer between 1 and 65535. The proper format of rdata depends on n. You may use octal \nnn codes to include arbitrary bytes inside rdata. at http://cr.yp.to/djbdns/tinydns-data.html. So which record type is not supported by tinydns? > 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 Zfqdn:mname:rname:ser:ref:ret:exp:min:ttl:timestamp:lo SOA record for fqdn showing mname as the primary name server, rname (with the first . converted to @) as the contact address, ser as the serial number, ref as the refresh time, ret as the retry time, exp as the expire time, and min as the minimum time. ser, ref, ret, exp, and min may be omitted; they default to, respectively, the modification time of the data file, 16384 seconds, 2048 seconds, 1048576 seconds, and 2560 seconds. at http://cr.yp.to/djbdns/tinydns-data.html. > 8. Like tinydns, dnscache will not bind to more than one IP address > without a third party patch. True, but a command similar to the case of tinydns enables the sysadmin to run dnscache on any given set of IPs. > 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. > 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: 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? > > 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? > > 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 wonder though what info is not available from the online docs at http://cr.yp.to/djbdns.html (which is complete with an intro to DNS and a FAQ) and from the djbdns mailing list? Is setting up and running djbdns so complicated that one needs to buy a $40 book? Please do not forget that, under tinydns, accepting the delegation for the zone c.d and giving authority to a.ns.c.d = 1.1.1.1 is as much as running the command add-ns c.d 1.1.1.1 and it results in the single line .c.d:1.1.1.1:a:259200 in the data file. > 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. It is indeed sad if a person wants to set up a name server but does not have access to the Internet. Sysadmins who think they might get into trouble in the future can download http://cr.yp.to/djbdns/doc.tar.gz ahead of time. > > 12. Commercial support for djbdns is also questionable. [...] This section is first theorizing about the competence and DNS experience of the available commercial support groups for djbdns. Then there is a long ad for Nominum. Interestingly this section is complete with URLs, while they are completely missing from the technical sections. 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? But I think I do understand the spirit of the section: the Microsoft developers combined programming experience can be measured only in millions of years. So a responsible party should never consider an OS like FreeBSD with all these young (hence inexperienced!) developers and with so few books under its belt. This also describes reality at my university... > > 13. Training for djbdns is minimal or non-existent. [ long detailed ad for John Steinbeck's training camp and friends' snipped... ] Not much room for argument here. With time, though, training for djbdns is expected to be more widespread. Until then, those who would send their sysadmins to a training camp with a knee-jerk and thousands of bucks will perhaps pause, and see if the available online resources are more than enough and of better value. > 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. Well, at ftp://ftp.cup.hp.com/dist/networking/briefs/cc3300_dns_server_results.txt Rick Jones shows us 7,223 q/s for 9.2 in a lab environment (complete with Gigabit Ethernet links). In ftp://ftp.cup.hp.com/dist/networking/briefs/i2000_dns_server_results.txt RJ reports 3,840q/s for 9.2.0rc8---again, in a lab environment. > The best benchmarks available for tinydns > indicate that it can handle at least 500 queries per second, but > that is the highest number reported. Make that "at least 6,000" in a _production_ environment with stock tinydns (only MAXUDP changed), and read http://marc.theaimsgroup.com/?l=djbdns&m=101414695223959&w=2 > 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). In the 09/11/2001(!) article at http://www.faqts.com/knowledge_base/view.phtml/aid/11438/fid/699 I read Dnscache stats as of yesterday: 200MB cache full (198123519 bytes). In 5 days of uptime it has processed 1.9 billion (1951598982) queries which averages out to 4500 queries per second. The dnscache process consistently chews up 45% of one CPU and multilog (-*) eats up 10% of another CPU. > 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. I think the reference is to (I am not always sure when is Mr Knowles talking about cache performance and when authoritative-only server performance) http://marc.theaimsgroup.com/?l=bind-users&m=99315975627678&w=2 and there the highest numbers I see are Bind8 5,041 qps dnscache 4,096 Bind9 2,850 Not bad, but the above numbers reflect a few seconds load by handling 65,536 queries, and both BINDs crashed when they had to handle 16711680 queries. > > 15. One of the recommended features of dnscache is the ability to > limit the amount of memory that the nameserver will use. Before reading on, I again remind myself what happened in reality to BIND when it was subjected to sustained high load, so I reread http://marc.theaimsgroup.com/?l=bind-users&m=99315975627678&w=2 After that, I see a hypothetical description of what might happen under high loads to various caching servers. > 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. For a dnscache admin, it is an easy to exercise to figure out the cache activity of dnscache on my home computer from the lines 2002-03-29 15:35:17.527491500 stats 10 428 1 0 2002-03-29 15:35:17.981290500 stats 10 557 1 0 2002-03-29 15:35:18.191180500 stats 10 722 1 0 2002-03-30 21:32:06.601683500 stats 12 1091 1 0 2002-03-30 21:32:06.831232500 stats 12 1205 1 0 2002-03-30 21:32:07.302361500 stats 13 1519 1 0 Hint: http://cr.yp.to/djbdns/faq.html Mate --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis 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?20020403144539.A11798>