Slashdot Mirror

If you're going to so radically redesign email to thwart spammers, why not just redesign it so that the sender is responsible for message storage until the recipient elects to retrieve it? That will kill spammers dead. No one will retrieve their crap (except for the 0.001% that actually respond). Spammers will go over quota if they use their ISP's mail spool, and will have to pay for all their own storage if they use their own server farm. Open relays become a non-issue. If you allow people to promiscuously utilize your mail server you alone pay for the consequences, and no one else does.

Dan Bernstien, a somewhat famous eccentric programmer, has just such a proposal: Internet Mail 2000.

DJB claims that with this system bounce messages will be eliminated (if I read correctly).

From: schneier@counterpane.com (Bruce Schneir)
To: reader@slashdot.org (Nutcase)
Subject: Monthly Cryptogram newsletter

The February 2003 newsletter is out!

http://www.counterpane.com/crypto-gram-0302.html

1. Instead of blasting out 20K messages to all of the recipients at once, he blasts out a bunch of 1K messages, cutting down on his 95th percentile bandwidth. People will come back to read the articles, and when they do, web caching servers/software between users and his server will cache anything static. Eg: 5000 AOL users will get the article from the AOL caches instead of his site, but a bug in the HTML will get a 1x1 gif from his site directly.
   
2. Everyone sees exactly the same newsletter as Bruce intended to publish it (he probably doesn't make exceptions of Opera 7 ;^) instead of worrying about hoiw to accommodate HTML into everyone's broken mail reader.
   
3. It keeps from filling up countless mailboxes for something we'd probably go to his website for anyway.
   
4. If he has advertisers that want to post on his website, they get more eyeballs, and it's less annoying than being sent an ad as part of your mailbox. Conversely, like Slashdot, subscribers can pay Bruce not to put ads into the newsletter by giving him the annual subscription fee.
   
5. Bruce can tell exactly how many people read his article (web logs).
   

Dan J. Bernstein has written a fantastic, lightweight server that will serve files via either or both FTP and HTTP depending on how the client connects.

If you want to serve files to the public, this is the most secure way to do so. If you need to provide the files to only certain logins, use something else. If not, you can run this on very lightweight hardware and if it's the only server running, you won't get hacked. Period.

Dan J. Bernstein has written a fantastic, lightweight server that will serve files via either or both FTP and HTTP depending on how the client connects.

If you want to serve files to the public, this is the most secure way to do so. If you need to provide the files to only certain logins, use something else. If not, you can run this on very lightweight hardware and if it's the only server running, you won't get hacked. Period.

The DNS software isn't the problem here. What you're recommending is basically a flat DNS namespace, where 90% or more of the present-day DNS traffic is moved directly to the root servers. You're going to need to beef up those root servers several orders of magnitude in order for this scheme to work.

The catch of course is that it's no good your using it if nobody else does. However, if some such system does get a minimal support base today, I predict it will quickly become quite popular. By around 2007 spammers will make normal email almost unusable, unless something drastic is done before that.

Could explain the difference between "There is a message for you at im2000://$URL1 " and "Visit http://$URL2 "?
What's worse, you can't read your email off-line unless you prefetch your im2000 email, thus verifying the im2000 mailbox is read.

• Stuff the new capabilities into the original software anyplace they'll fit. This created Unix variants like Linux (and Solaris, and the others that are still maintained). The code may be a mishmash, but new features are provided, and direct backwards compatibility wasn't sacrificed.
  
• Toss out the old design and create something new which includes all the desired features from the beginning. This is what the elgance-minded inventors of Unix did, but the change was so drastic that it would've required legions of existing users to re-engineer their systems. Today, nobody uses the result.
  

For Gods sake, why would someone choose BSD over linux????

It seems that nothing is sacred anymore. First you get everybody and his brother trying to introduce alternate root zones, then you get morons like NewNet that go a step further and require a browser plugin. Now Verisign does this.

I understand that having non-ascii characters in host/domain names would be desirable, however if they can't do it without breaking the DNS protocol, then they should get their ass right back to the R&D lab and try harder.

This issue is extensively discussed on D.J. Bernstein's page, here.

Some alternatives to ant/make are

• cook (probably the best contender),
• Mk (which is like bitkeeper+make),
• Jam,
• cake (does anyone use this any more?), and
• the Plan 9 mk.

There's also something called Cons, but it needs perl to work. See this.

I haven't found a good alternative to autoconf yet. There used to be Metaconfig, but I don't know who maintains it any more (or where). It produces configure scripts similar to what you see when you configure perl. This guy uses some unreleased software package for his build systems that tend to work really well -- for C code under Unix.

Come to think of it, if someone ports/writes a build tool in C#, you'd be set.

DNS lookup is definitely more optimized. For some links.. you can use bind or djbdns to set up your own DNS server. djbdns also has components to install scaled back dns servers like Tinydns or setup a local workstation dns cache.

If anyone cares, in win2k the hosts just get added to the dns cache (try ipconfig /displaydns).

I seem to remember Macs having a 340k limit on the hosts file, but that's probably ancient history by now.

DNS lookup is definitely more optimized. For some links.. you can use bind or djbdns to set up your own DNS server. djbdns also has components to install scaled back dns servers like Tinydns or setup a local workstation dns cache.

If anyone cares, in win2k the hosts just get added to the dns cache (try ipconfig /displaydns).

I seem to remember Macs having a 340k limit on the hosts file, but that's probably ancient history by now.

That behind me, my thonghts on DNSSEC. The main problem with DNSSEC is that DNS itself has no concept of security; any attempt to add signatures has the issue of having to graft on signatures to a system not designed to have signatures. For example:

• A DNS packet can only be 512 bytes long; that really is not enough room to fit a signature.

• How do you sign the statement "this host name does not exist"? All of the solutions have a problem. We either have to put a private key on an internet connected computer, or we have to reveal all of the host names that exist in our network.

• Digital signatures add a good deal of workload to already overloaded recursive DNS servers.

- Sam

However, I feel that they should not have to. It's not that I think that blocking port 25 won't help stop spam. I just am against ISPs filtering service in any way. Once they start down the slippery slope of filtering, I doubt it will end.

Assuming competence on the part of the ISP, this is a good solution for spam. If customers want to send mail directly to other systems, enable it just for them. The ISP could make the customer sign a contract first, making them explicitly liable for sending spam. Lots of spam is sent from dialup and dynamic broadband accounts. Blocking these by IP (which is the best current reliable method for stopping spam) is difficult.

By forcing all mail to go through the ISP's mail server, that server can at least add a legitimate Received header. It could add an additional header identifying the user, such as AOL's X-Apparently-From. It might also rate limit for each user and automatically track possible abuse. If users want to send email via an authenticating SMTP server, it can be run on a different port (specifying the port of the server is no more difficult than specifying the SMTP authentication info).

This won't stop spam entirely, of course, but it will make it harder on spammers.

http://cr.yp.to/qmail/antispam.html

Unfortunately, it's only on OpenBSD so far. Can some one please port this to Linux by tomorrow?

http://cr.yp.to/ucspi-tcp/rblsmtpd.html

Hmmm, pretty new to DNS, I see. Trust me, the original DNS spec makes it trivial to poison caches; BIND, until about five years ago, allowed anyone on the internet with a domain to put any record they wanted to in your DNS cache.

DNS is, for the uninitiated, far worse than anyting you can possibly imagine. More information

- Sam

I have single-handendly written a working recursive DNS server without getting paid for my work. There is a reason why there are only three of us in the entire world; DNS is that bad. Actually, it is a good deal worse than you can imagine.

Let me put it this way. Writing a DNS client (or a non-recursive DNS server) is sort of like Highlander I. Entertaining, really. You think to youself "Hey! That was easy! A recursive server can't be too bad!"

Well, writing a working recursive DNS server is like watching Highlander II. Suddenly, just as Highlander II changes your outlook on the entire Highlander franchise, writing a recursive DNS server changes your outlook on the entire DNS protocol.

But, hey, don't take my word for it. Dan, one of the other three of us, feels the same way. Thomas, the last of us, has made no statements either for or against DNS. If we were to review recursive DNS the same way Rotten Tomatoes reviews movies, DNS would get a 0%; possibly a 33% if Thomas secretly loves DNS and hasn't told anyone. By any standard, that makes for a bomb that should have tanked at the box office.

Alas, it didn't. And so we are stuck with a horrible mess of a protocol today.

- Sam

Your punishment is very simple: You are to write a functioning recursive DNS server. This server has to resolve domains well enough to give an end-user a satisfactory web surfing experience.

After doing this, you will then post an essay to Slashdot concerning your opinion of the DNS spec and well-designed it is.

You will, I assure you, have an experience akin to seeing the movie Highlander II. You hopes for DNS being a decent protocol will become, rather quickly, a big dissapointment. But don't take my word for it. Don't take Dan Bernstein's word for it. Do it yourself and become an exclusive member of the club of People Crazy Enough to Actually Write a Recursive DNS Server. After all, we all know that people who log in as anonymous cowards and flame free software developers are the best programmers that the world has; I am sure you can do this in a week. Once you do this, you too will know why a number of DNS server projects die around the point when the potential DNS implementor in question looks at how recursive resolution is actually done.

If you continue to flame free software developers after doing this, your punishment will be escalated to having to write a recursive DNS server which recursively resolves names according to RFC 1034, while not having any security problems.

If you persist in your flaming ways after doing that, your next punsihment will be to write a C++ compiler which implements everything in the C++ spec, and release said compiler under the GPL.

And, if you continue to insist on flaming free software devlopers after that...well, you won't be, by this point. You'll be too busily getting flamed by anonymous cowards on Slashdot to do any flaming yourself.

- Sam

Given that, consider the possibility of the ISP or corporate data center intercepting any queries done (as if the end user were running a recursive DNS server instead of a basic resolver) and handle them through a local cache (within the ISP or corporate data center). It won't break normal use.

Wrong. I run my own local DNS resolver, dnscache. I don't trust my ISP to manage a DNS resolver properly. What if they are running a version of BIND vulnerable to poison or other issues? What if I am testing DNS resolution and need to flush the cache? (I do this routinely.) They also don't need to see every DNS query I make. If they want to sniff and parse packets, fine, but no need to make it any easier on them.

It won't break even if someone is running their own DNS (although they will get a cached response instead of an authoritative one).

That would be possible only if they were in fact intercepting every single DNS packet and rewriting it. It would make it impossible for me to perform diagnostic queries to DNS servers. And unless they were doing some very complex packet rewriting, it would break if an authoritative server was providing different information depending on the IP address that sent the query.

If you can't even get ISPs to perform egress filtering, why would they do something as stupid and broken as this? Egress filtering would do much more to stop these types of attacks.

Besides, how does this stop me if I am the ISP? There are plenty vulnerable machines that are on much better connections than dialup or broadband.

Given that, consider the possibility of the ISP or corporate data center intercepting any queries done (as if the end user were running a recursive DNS server instead of a basic resolver) and handle them through a local cache (within the ISP or corporate data center). It won't break normal use.

Wrong. I run my own local DNS resolver, dnscache. I don't trust my ISP to manage a DNS resolver properly. What if they are running a version of BIND vulnerable to poison or other issues? What if I am testing DNS resolution and need to flush the cache? (I do this routinely.) They also don't need to see every DNS query I make. If they want to sniff and parse packets, fine, but no need to make it any easier on them.

It won't break even if someone is running their own DNS (although they will get a cached response instead of an authoritative one).

That would be possible only if they were in fact intercepting every single DNS packet and rewriting it. It would make it impossible for me to perform diagnostic queries to DNS servers. And unless they were doing some very complex packet rewriting, it would break if an authoritative server was providing different information depending on the IP address that sent the query.

If you can't even get ISPs to perform egress filtering, why would they do something as stupid and broken as this? Egress filtering would do much more to stop these types of attacks.

Besides, how does this stop me if I am the ISP? There are plenty vulnerable machines that are on much better connections than dialup or broadband.

Given that, consider the possibility of the ISP or corporate data center intercepting any queries done (as if the end user were running a recursive DNS server instead of a basic resolver) and handle them through a local cache (within the ISP or corporate data center). It won't break normal use.

Wrong. I run my own local DNS resolver, dnscache. I don't trust my ISP to manage a DNS resolver properly. What if they are running a version of BIND vulnerable to poison or other issues? What if I am testing DNS resolution and need to flush the cache? (I do this routinely.) They also don't need to see every DNS query I make. If they want to sniff and parse packets, fine, but no need to make it any easier on them.

It won't break even if someone is running their own DNS (although they will get a cached response instead of an authoritative one).

That would be possible only if they were in fact intercepting every single DNS packet and rewriting it. It would make it impossible for me to perform diagnostic queries to DNS servers. And unless they were doing some very complex packet rewriting, it would break if an authoritative server was providing different information depending on the IP address that sent the query.

If you can't even get ISPs to perform egress filtering, why would they do something as stupid and broken as this? Egress filtering would do much more to stop these types of attacks.

Besides, how does this stop me if I am the ISP? There are plenty vulnerable machines that are on much better connections than dialup or broadband.

Now, the author seems much more worried about attackts against Top Level Domains, because of reasons related to the nature of the information that TLD servers have, and he suggests a few techniques that they could use. What he doesn't say is what techniques the TLD's are using currently, and how secure they are.

http://cr.yp.to/djbdns/forgery.html

Your favorite Linux distribution and djbdns. Tinydns doesn't need many resources.

postfix exploit

Found this by typing, "postfix local exploit" on google. Seems there were tons of other hits on this too (about 6,900).

I think you mean this.

Good Software is not about more features! Good Software is about doing it safely, reliably and securely. Good software is about doing it well, not doing more.

Adding more features will only make the software worse. More bloat, less easy to understand and use, needs more hardware, and the documentation usually lags behind as well.

Writing software is an art form. It is an exercise in restraint and thinking before you do it, not in gluttony or adding more crap to already crappy software. The world is full of bad software with hundreds of little understood and under-documented features. I'd rather have small, well-documented and reliable software, thank you very much.

Most of the predictions were "more of the same". I seriously doubt we'll be seeing "a major Cyberterrorism event" though -- I usually expect to hear this from sensationalists, not legitimate security experts. Think Steve Gibson. In fact, the theorized cause of these massive DDoS attacks is supposed to be windows systems, and the Raw Sockets are Evil thread is brought back to mind.

One big unforgivable mistake in the article: there was no bug in DNS -- there was a bug with BIND. Anyone using nameservers or libraries that were not part of BIND were unaffected. The fact that he assumes BIND is the only DNS server in the world is a big mistake, and one of the reasons DJBDNS doesn't get enough airtime.

Overall, I didn't see anything in the article that I didn't already see a hundred other places.

Personally, I'd like to hear what the authors of Hacking Linux Exposed have to say. Their book has a lot more grit and less soft-shoeing over the topics. Real World Linux Security has always been too full of stories and not enough answers for me. (Of course I bought the 2nd edition anyway.)

Mail storage should be the responsibility of the sender . The sender only actually sends email notifications.

Mail notifications should include a digital signature of some sort. Users can choose which signing authorities to trust. Signing authorities may require a deposit before issuing a signature certificate and may gain trust from potential recipients by offering to split the deposit 50-50 with the first person to receive spam from the account.

So it boils down to a whitelist of ISPs. If you want to send legitimate mail, you need to use an ISP that other people trust to enforce the spam rules.

How will spammers get around that? The only thing I can think of is by forging certificates, but preventing certificate forgeries is something that I assume has already been solved.

If you can come up with a protocol that solves spam and works as well as SMTP, write an RFC and get some code out there.

Has anyone checked out Dan Bernstein's IM2000 idea? The first time I heard about it was a Slashdot post a few days ago, and I'm extremely impressed. I think switching to a system like this WOULD be do-able. Not overnight, of course, but get a few ISPs on board and we'll get there. Seems like it would solve the spam problem pretty nicely.

You may include a timestamp on each line. If ttl is nonzero (or omitted), the timestamp is a starting time for the information in the line; the line will be ignored before that time. If ttl is zero, the timestamp is an ending time (``time to die'') for the information in the line; tinydns dynamically adjusts ttl so that the line's DNS records are not cached for more than a few seconds past the ending time. A timestamp is an external TAI64 timestamp, printed as 16 lowercase hexadecimal characters. For example, the lines

+www.heaven.af.mil:1.2.3.4:0:4000000038af1379
+ww w.heaven.af.mil:1.2.3.7::4000000038af1379

specify that www.heaven.af.mil will have address 1.2.3.4 until time 4000000038af1379 (2000-02-19 22:04:31 UTC) and will then switch to IP address 1.2.3.7.

If I was stuck, behind a firewall that blocked NTP, I would look into using clockspeed to keep the time accurate without constantly resetting to an external source.

You would have to get clockspeed 3 or 4 deltas from another clock over the first few months you use it, but you might be able to borrow a laptop, sync it with a good clock, and use it as a local ntp server to obtain these few deltas to calibrate your system. (with a very short time between when the laptop was synced, and when clockspeed gets it's delta from the laptop).

he wasn't interested in loaner or donated hardware to do the work on

Hmm. now why didn't he say "Because SMP is insanely hard to do right and I'm not motivated enough or smart enough to get it done without making the system even more unstable. And besides we get more publicity if we encrypt swap"?

The OpenBSD project seems filled with people who need to prove their masculinity and grab attention rather than people who want to make sound design decisions. And in addition to making technical decisions, they also follow suit politically. For example, oh, such as holding an OpenSSH vulnerability hostage to promote adoption of their privilege separation patch.

OpenBSD has plenty of stability problems. See Dan Bernstein's downtime reports. And Bernstein is someone who wants to believe in OpenBSD but is losing patience.

OpenBSD receives plenty of attention thanks to its loudmouthed egomaniacs. Fortunately, FreeBSD is a better, more rationally designed system. Of course the FreeBSD developers are a little resentful of Linux's attention and the GPL and have made system changes out of spite, but it's nothing as bad as what OpenBSD does on a regular basis.

I really did want to like OpenBSD. Don't believe the hype.

Although it's nice to see people attempting to improve one of the more regularly broken unix core services, I still think that the whole syslog design of a monolithic central multiplexed logging daemon is the Wrong Design.

Dan Bernstein's multilog, from his daemontools package, is, in my opinion, a good example of the correct way to do logging: a single process logs the stdout and stderr of each daemon, goes to great lengths to ensure that no data is lost, and handles logfile rollover automatically. With this tcpserver/tcpclient utilities from his ucspi-tcp package, it can be simply done over a network as well.

Of course, DJB's code, while source-available, is not in any way Free Software, and daemontools in particular currently is inextricably linked into his extraordinarily dubious "slashpackage" system, making it a potentially annoying choice for anyone reselling or distributing systems based on it. Cronolog, which was originally created to manage apache logs, looks like a promising GPLed replacement for multilog, but despite lots of grumbling along those lines, nobody has written a gpl/bsd replacement for daemontools...yet.

Although it's nice to see people attempting to improve one of the more regularly broken unix core services, I still think that the whole syslog design of a monolithic central multiplexed logging daemon is the Wrong Design.

Dan Bernstein's multilog, from his daemontools package, is, in my opinion, a good example of the correct way to do logging: a single process logs the stdout and stderr of each daemon, goes to great lengths to ensure that no data is lost, and handles logfile rollover automatically. With this tcpserver/tcpclient utilities from his ucspi-tcp package, it can be simply done over a network as well.

Of course, DJB's code, while source-available, is not in any way Free Software, and daemontools in particular currently is inextricably linked into his extraordinarily dubious "slashpackage" system, making it a potentially annoying choice for anyone reselling or distributing systems based on it. Cronolog, which was originally created to manage apache logs, looks like a promising GPLed replacement for multilog, but despite lots of grumbling along those lines, nobody has written a gpl/bsd replacement for daemontools...yet.

If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval.
(from here)

I agree that that may be a pain, but I don't know, and am not in a position to find out, whether someone bothered to ask Bernstein or not (and yes, I do understand his reasons for being picky). I haven't yet had a chance to actually look through the package info of the qmail port from that site, but does anyone know if it is patched too much that Bernstein wouldn't allow it?

A new (secure) protocol?

http://cr.yp.to/im2000.html

Very stable, performs really, really well on old machines we have here, makes my admin live plenty easy, and never had any security problems with it.

Enough said ;-)

here. It's built for security, but I think it serves up only straight HTML, no CGI or SSL. I haven't personally used it, but I thought it'd be a useful link to pass along.

• It requires the intervention of a large, government-sponsored, Big Brother company (or the government itself) to enforce.
• It erodes civil liberties and privacy.
• It purports to charge for something which has previously been obtained freely, and still can be with zero effort.
• It won't stop spam, because spammers will pass the cost of sending email along to their sponsors, whose marketing departments will gladly pay it as a cost of doing business (it's even tax deductible).

The worse spam gets, the more people will look to alternatives. Maybe it's time to set up some infrastructure for Internet Mail 2000.

I don't quite follow what scanrand does that a normal SYN-based scanner does not except that it is broken into two parts so that potentially a different system could be used to receive the packets sent by the first system. Why would this be useful?

I guess he refers to embedding a code in each packet sent out to validate that only "real" packets are accepted by the receiver as "Inverse SYN Cookie". I don't understand why this is important, tho.

Because it allows much faster scanning than can be done with a traditional scanner. You need to understand SYN cookies:

http://cr.yp.to/syncookies.html

Instead of sending a SYN and waiting for the response, as a normal scanner has to do, scanrand sends thousands of SYN packets at once, without tracking them. It determines the port based on the ``inverse SYN cookie'' that the response contains.

1. describes the usual file-copying mechanisms, such as scp;
   
2. says ``Zone transfers are an archaic alternative mechanism for copying DNS information'' and explains the problems with zone transfers;
   
3. says ``There has been some work on improving the zone-transfer protocol'' and describes that work; and
   
4. concludes with a comparison table showing eleven disadvantages of (improved) zone transfers.
   

• quotes #2 out of context and claims, incorrectly, that I'm ignoring the work on improving the zone-transfer protocol;
  
• claims, incorrectly, that BIND's implementation of the experimental IXFR mechanism works (and has worked ``for years'') with hand-modified zone files;
  
• claims, incorrectly, that the DNSSEC architecture works without centralized key management;
  
• claims, incorrectly, that scp et al. are proprietary;
  
• claims, incorrectly, that TSIG is ``compatible'' and IPSEC isn't; and
  
• says that some of the disadvantages of zone transfers aren't issues for him, as if this meant that they don't matter to anybody.
  

1. describes the usual file-copying mechanisms, such as scp;
   
2. says ``Zone transfers are an archaic alternative mechanism for copying DNS information'' and explains the problems with zone transfers;
   
3. says ``There has been some work on improving the zone-transfer protocol'' and describes that work; and
   
4. concludes with a comparison table showing eleven disadvantages of (improved) zone transfers.
   

• quotes #2 out of context and claims, incorrectly, that I'm ignoring the work on improving the zone-transfer protocol;
  
• claims, incorrectly, that BIND's implementation of the experimental IXFR mechanism works (and has worked ``for years'') with hand-modified zone files;
  
• claims, incorrectly, that the DNSSEC architecture works without centralized key management;
  
• claims, incorrectly, that scp et al. are proprietary;
  
• claims, incorrectly, that TSIG is ``compatible'' and IPSEC isn't; and
  
• says that some of the disadvantages of zone transfers aren't issues for him, as if this meant that they don't matter to anybody.
  

Think about it: what would happen to one of those message transfer agents if its own network connection failed? Answer: It would bounce every message in the queue! People who claim that it's a disaster for servers to be reachable less than 100.0000000000% of the time are forgetting that client connections are nowhere near that level of reliability.

This is just one of the issues discussed in my cost-benefit analysis of third-party DNS servers. Note that my page doesn't say that third-party DNS servers are always bad; it analyzes the costs and benefits in detail, so you can see whether you're in the rare situation where the benefits outweigh the costs.

Moen is also completely incorrect when he claims that my web page ``argues against the very notion of backup nameservers.'' On the contrary. The page clearly states, both in its title and in its introduction, that it is discussing the costs and benefits of third-party DNS servers.

In contrast, backup DNS servers are useful at many sites, just like backup HTTP servers, and my documentation specifically recommends DNS service replication at large sites. If your company has identical HTTP servers in New York and Paris, obviously you should put identical DNS servers at the same locations.

Think about it: what would happen to one of those message transfer agents if its own network connection failed? Answer: It would bounce every message in the queue! People who claim that it's a disaster for servers to be reachable less than 100.0000000000% of the time are forgetting that client connections are nowhere near that level of reliability.

This is just one of the issues discussed in my cost-benefit analysis of third-party DNS servers. Note that my page doesn't say that third-party DNS servers are always bad; it analyzes the costs and benefits in detail, so you can see whether you're in the rare situation where the benefits outweigh the costs.

Moen is also completely incorrect when he claims that my web page ``argues against the very notion of backup nameservers.'' On the contrary. The page clearly states, both in its title and in its introduction, that it is discussing the costs and benefits of third-party DNS servers.

In contrast, backup DNS servers are useful at many sites, just like backup HTTP servers, and my documentation specifically recommends DNS service replication at large sites. If your company has identical HTTP servers in New York and Paris, obviously you should put identical DNS servers at the same locations.

Or support zone transfers rather than telling to go away and rsync your gibberish-zone-files behind the scenes.

Tim, to clarify, Prof. Bernstein talks about rsync/ssh or scp just as examples of alternate approaches that can be used to mirror zonefiles, without use of outgoing AXFR, not to mention TSIG and IXFR. And I suppose that, in fairness, that's worth considering (when you don't want/need to interoperate with other people's nameservers that do the standard zone-transfer protocols). You might be able to efficiently and reliably do pull-distribution of zonefiles in one of the ways Bernstein speaks of. It's worth trying, in some circumstances. (On the other hand, I don't see offhand how you could do push-distribution that way, without creating a security hazard.)

But Prof. Bernstein didn't merely content himself with issuing a nameserver that doesn't fully support zone-transfer protocols he deprecates and say "Hey, that's how it is. Use it if you like the design, or don't." No, he had to justify that using one of the most wacko Web pages I've ever seen, where he argues against the very notion of backup nameservers (which in DJBware jargon are termed "third-party DNS service"). That just floors me, but, yes, the man actually does say that.

On that page, you'll find a great deal of logic-chopping that presents facts that seem to support the conclusion he desires while omitting crucial ones that don't. Example: Bernstein says you needn't worry about inbound SMTP mail bouncing when your on-site DNS becomes unreachable (with no backup DNS elsewhere) because "Mail transfer agents defer delivery attempts when DNS servers are unreachable". Well, yes, but not past the expiration of any cached DNS values -- which is exactly the problem that offsite backup nameservers address.

Example #2: Bernstein says having offsite backup nameservers won't stop the mail from bouncing during an extended outage because "the SMTP servers aren't reachable either". That is, of course, a non-sequitur: You would of course have offsite backup MX hosts, in addition to your offsite backup nameservice, to ensure that "the SMTP servers are reachable".

Building up that sort of wacko justification for why offsite backup nameservers aren't useful (when clearly they are essential), just because his software supports that functionality in only a partial and eccentric fashion, is certainly the most bizarre move I've seen from the DJB camp, to date.

The pity of it is that Bernstein has a number of excellent points he's made, that people really should heed, e.g., modular design, attention to trust relationships, eschewing featuritis, careful coding to prevent buffer overflows, and not mindlessly enshrining protocols into RFCs for little reason other than BIND already doing them. If not for his unexcelled talent at pissing people off, and for wacko post-hoc rationalising like the foregoing, those important lessons would surely be more widely understood.

Rick Moen
rick@linuxmafia.com

``Have zone files which someone might be able to read and make any sense of.'' No sane human-interface designer would choose BIND's

4.3.2.1.in-addr.arpa. 86400 IN PTR lion.heaven.af.mil.
lion.heaven.af.mil. 86400 IN A 1.2.3.4

(even worse, in two separate files!) over the tinydns-data equivalent:

=lion.heaven.af.mil:1.2.3.4

See the upgrade-from-BIND page, under Administration, for a list of ten time-saving features in the data format.

Even more important is that the data format is easy for programs to read and write. There are tinydns management tools supporting several different administrative tastes: MySQL, LDAP, a web interface, etc. Development of these tools was faster for tinydns than for BIND, and will remain faster, because I'm not throwing artificial barriers in the way of implementors.