Slashdot Mirror

Is there a technical solution?

Spam is an abuse of the email sysem. The collective opinion is that some characteristics of the emails are bad - otherwise there isn't much to distinguish it from legitimate mail. Because it is a social problem, laws are needed to combat it.

D. J. Bernstein has an excellent solution to spam and many of the other problems of email: Internet Mail 2000

Essentially, with IM2000, mail is stored on the sender's machine, rather than on the recipient's, much like with HTTP. Spam is still possible, but it makes it much easier to identify the sender and to block it.

Is there a technical solution?

Spam is an abuse of the email sysem. The collective opinion is that some characteristics of the emails are bad - otherwise there isn't much to distinguish it from legitimate mail. Because it is a social problem, laws are needed to combat it.

D. J. Bernstein has an excellent solution to spam and many of the other problems of email: Internet Mail 2000

Essentially, with IM2000, mail is stored on the sender's machine, rather than on the recipient's, much like with HTTP. Spam is still possible, but it makes it much easier to identify the sender and to block it.

Is there a technical solution?

Spam is an abuse of the email sysem. The collective opinion is that some characteristics of the emails are bad - otherwise there isn't much to distinguish it from legitimate mail. Because it is a social problem, laws are needed to combat it.

D. J. Bernstein has an excellent solution to spam and many of the other problems of email: Internet Mail 2000

Essentially, with IM2000, mail is stored on the sender's machine, rather than on the recipient's, much like with HTTP. Spam is still possible, but it makes it much easier to identify the sender and to block it.

Here's a very interesting article about license agreements.

What we really need is a new mail system that is inherently spam-unfriendly, where the sender bears the burden of storing the message until the recipient chooses to come pick it up. Dan Bernstein is working on such a system, which he calls Internet Mail 2000. Check it out.

What is DJB's packaging system?

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

In general I agree that bugs are a fact of life, like death and taxes. However, there are coding styles that can minimize the number of buffer overflows in code:

• One can create a special string library which is resistant to buffer overflows (strings being structures which a "maximum length" value). For example, my DNS server uses such code to minimize buffer overflows (the string library is documented in man pages).
• One can write code in a style where the possibility of the code being placed in an "unknown state" is minimized.
• One can avoid strings wherever possible

It is possible, with today's knowledge of security issues, to code in a style which makes these kinds of security holes very unlikely. Look at Dan Bernstien's code. Look at Chris Ferret's VsFtpd.

This is why I feel that Solaris is slowly dying: Becuase Solaris has, for whatever reason, lost the motivation to replace their codebase with the features that a modern Linux system has. Some Solaris administrators are so afraid of change that they don't want to replace the Solaris userspace with the vastly superior Linux userspace. Like Eric Raymond said to the idiots that think making Python a requirment to build the kernel is a bad thing, progress happens.

- Sam

Perhaps use sftp and publicfile like a sane person? http://cr.yp.to/publicfile.html

proftpd has had its share of holes. You shouldn't be using ftp for uploads anyway.

While this argument is old and what matters is the number of cycles an instruction takes to be executed (together with the length of the pipeline of the CPU etc), I think one would actually have to finish his homework instead of just assuming that a PowerPC can actually perform a high number of instructions executed per clock cycle.

I was recently exposed to an old PowerPC machine (a PowerMac 9500/180MP), liked it a lot (despite it being slow) and thought about buying a new Mac for me (perhaps an iBook?). But since they are not even comparable in price to other architectures here in Brazil, I decided to learn more about it to see if the applications were making good use of the processor and if compiler support (read: GCC) were mature (which is important for me, since I am a grad Computer Science student).

Well, it seems that that's not the case. While Apple may have a good GCC for Darwin (whose patches are supposed to be incorportated upstream in GCC in the future), some posts from debian-powerpc and other places in the Web suggest that as a development platform (especially for intensive calculations), it may not be as good as a cheap, underpriced PC platform.

Of special weight for me is the opinion of Dan Bernstein, whose opinions I always respect a lot, given his background. In particular an article about G4s and an advice about purchasing computers.

Despite his opinions having a great weight on my decisions, I'm already convinced that the Apple products are reasonably good (and I've already played a tiny bit with their OS X, which has the coolness factor).

On the other hand, while the competition is so much cheaper (a strong point), with higher performance and better support, I'm still evaluating if purchasing, say, an iBook would be a good move (read: I'm still undecided), especially in the light of Dan Bernstein's revelations.

While this argument is old and what matters is the number of cycles an instruction takes to be executed (together with the length of the pipeline of the CPU etc), I think one would actually have to finish his homework instead of just assuming that a PowerPC can actually perform a high number of instructions executed per clock cycle.

I was recently exposed to an old PowerPC machine (a PowerMac 9500/180MP), liked it a lot (despite it being slow) and thought about buying a new Mac for me (perhaps an iBook?). But since they are not even comparable in price to other architectures here in Brazil, I decided to learn more about it to see if the applications were making good use of the processor and if compiler support (read: GCC) were mature (which is important for me, since I am a grad Computer Science student).

Well, it seems that that's not the case. While Apple may have a good GCC for Darwin (whose patches are supposed to be incorportated upstream in GCC in the future), some posts from debian-powerpc and other places in the Web suggest that as a development platform (especially for intensive calculations), it may not be as good as a cheap, underpriced PC platform.

Of special weight for me is the opinion of Dan Bernstein, whose opinions I always respect a lot, given his background. In particular an article about G4s and an advice about purchasing computers.

Despite his opinions having a great weight on my decisions, I'm already convinced that the Apple products are reasonably good (and I've already played a tiny bit with their OS X, which has the coolness factor).

On the other hand, while the competition is so much cheaper (a strong point), with higher performance and better support, I'm still evaluating if purchasing, say, an iBook would be a good move (read: I'm still undecided), especially in the light of Dan Bernstein's revelations.

Choose a bare-bones http server, with no bells and whistles. Both IIS and Apache are out. Maybe thttpd?

publicfile is a good choice for both http and ftp.

But qmail has always been secure. Postfix has not. Who knows if it has any holes? When it was first released, it had a major design flaw that DJB immediately recognized. And it was covered up by the Postfix author, as that page points out.

I have been looking at the Courier mail suite lately. It has a lot of nice features, is easy to setup and is well integrated with each other. Unfortunately, I haven't seen anything relating to it's security or performance, but that could be a good thing.

There are solid competitors for all of these.

ftpd: Proftpd wins, hands down. Configuration is like Apache except less crufty. It's modular, and pretty secure too (I can't remember hearing of any major security holes). Some people who use it: ftp.gnu.org, download.sourceforge.net. Enough said. www.proftpd.org.

bind: bind 9? I can't really think of a replacement except DNScache, and I've never used it. I have no idea if it's better or worse or just weaker.

sendmail: I hear qmail is extremely good, if you don't mind DJB's bizarre lack of license (also applies to DNScache). Qmail purportedly runs Yahoo! Mail among others. Otherwise, the only other alternative I can think of is exim, which is designed to be easier to configure and simpler IIRC.

Next time, post some links or something. Sheesh.

Daniel

There are solid competitors for all of these.

ftpd: Proftpd wins, hands down. Configuration is like Apache except less crufty. It's modular, and pretty secure too (I can't remember hearing of any major security holes). Some people who use it: ftp.gnu.org, download.sourceforge.net. Enough said. www.proftpd.org.

bind: bind 9? I can't really think of a replacement except DNScache, and I've never used it. I have no idea if it's better or worse or just weaker.

sendmail: I hear qmail is extremely good, if you don't mind DJB's bizarre lack of license (also applies to DNScache). Qmail purportedly runs Yahoo! Mail among others. Otherwise, the only other alternative I can think of is exim, which is designed to be easier to configure and simpler IIRC.

Next time, post some links or something. Sheesh.

Daniel

• For anonymous ftp, I'd recommend looking at publicfiles by D.J Bernstein. I haven't used it, but he's serious about security.
  
• For file transfer amongst a community where you can enforce client choice, use scp/sftp, as provided by OpenSSH (or commercial SSH, I guess - ssh inc. has a nice windows ssh/sftp client if you need that, and it works with the free OpenSSH server).
  
• If you must use an ftpd with non anonymous logins (not recommended in a time of freely available packet sniffers), I'd look long and hard to find anything BUT wu-ftpd.
  

Or use a read-only, anonymous ftpd like publicfile and avoid getting owned.

We have things like sftp-server for authentication and uploads. There are very few legitimate reasons to keep using ftp for uploads. Are you still using telnetd too?

Since the EULA is neither presented nor signed at the time of purchase, it doesn't have bearing on the transaction.

This is not truly relevant, and there are legal counter-examples already. For example, you buy a plane ticket. Now, that ticket comes with a whole bunch of restrictions written on the back that you could not access in detail at the point of purchase. Yet you are bound by them nonetheless.

Case law on EULAs is still a little muddled, but at least one synopsis page is up at Dan Bernstein's site

Perhaps it would be a good idea after reading this article to examine publicfile.

It was written by a very security conscious programmer who realises that your private files can easily get out onto the web. That is why publicfile has no concept of content protection (eg, Deny from evilh4x0r.com or .htaccess) and will only serve up files that are publically readable.

From the features page:

• publicfile doesn't let users log in. Intruders can't use publicfile to check your usernames and passwords.
• publicfile refuses to supply files that are unreadable to owner, unreadable to group, or unreadable to world.

A good healthy does of paranoia would do people good.

You can patch the program, just not release the patches applied.

I am under the opinion that anyone can patch any program for any non-DMCA covered purpose without permission from the copyright holder (under fair use). DJB is also of that same opinion.

In any case, you can release the patches applied, you just can't release the patches applied along with the software itself. As mentioned in the link above, see "Galoob v. Nintendo, 780 F. Supp 1283 (N.D. Cal. 1991), affirmed, 22 U.S.P.Q.2d 1587 (9th Cir. 1992). and Foresight v. Pfortmiller, 719 F. Supp 1006 (D. Kan. 1989)."

Qmail is not "free software" only because you do not have permission to create and distribute a patched programs. (Also I believe you are not permitted to distribute unmodified copies electronically, though distributing them as CDs that you have burned directly from your download would be legal under first sale). As for being able to change the license at any time, this is only true for new downloads, once you have obtained a copy legally, your fair use and first sale rights apply.

The main reason I prefer "free software", as defined by RMS, is because I want the ability to create patches and be assured that the patched program is always available to third parties. This would require me to either download and burn a few million CDs with the current version, or rely on DJB to always offer the original free for download to those third parties.

He didn't say he is against porting GNOME to proprietary systems. He explicitly said, lots of times, there can be Free Software running on proprietary systems and it'll still be Free.

On the other hand, I can see him disapproving of efforts like Wine, which have the potential of turning systems that already are 100% Free into less-than-100% Free. "Hey, MS Office runs in Linux now? Let's stop using KOffice!"

GNOME on the Mac, on the other hand, is exactly the opposite - it takes a 100% proprietary system and turns it into something part Free, part proprietary. This is a good thing, and I'll bet RMS would agree. A beachhead if you will.

Another interesting tidbit from RMS's responses is:

From time to time I face the ticklish task of asking a complete stranger to change the license of his software package. Making this request is like waking up a dragon to ask to borrow its hoard: the developer is likely to find the request impertinent and could easily get angry. Nonetheless, I succeed most of the time.

I wonder if he's had the opportunity to tackle Dan J. Bernstein yet. Although his terms seem to meet the Free Software criteria for me, I hear all the time that Qmail isn't free software.

(This would not work with sites that rely on HTTP1.1 to tell them the name of the site, so that many sites can be hosted on a single IP, but that is less widely used than it might be.)

Also, you can put the IP address in the hosts file; then, everything will work fine. Or just run your own DNS daemon locally (djbdns is good for this), which is easy on *nix platforms, and you won't even notice the site being "censored" :-)

Of course, if too many people do this, the govt might grow a brain and try a more effect means of censorship; on the plus side, one-way air tickets are quite cheap these days...

The alternative is /package /doc and /command from DJB: Unix

Gee, thanks for offending me as a systems administrator, thanks! Here's what djb has to say about this known *nix problem, which I think is very sound:

compatibility

look under FS layout

Gee, thanks for offending me as a systems administrator, thanks! Here's what djb has to say about this known *nix problem, which I think is very sound:

compatibility

look under FS layout

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

it's not perfect, but it divides the filesystem (mostly) by maintainer - similarly to how packages are already deployed. but beyond that, it creates symlinks into one directory (in his example: /command) to keep $PATH sane.

package management _still_ makes my life easier- i don't like to hunt around packages manually. but if the filesystem mimicks the packages, we have solved the three biggest problems with package management at the same time:

• incorrect dependancy names (moot: all other packages have a formed-name)
• deleting too much (packages are stacked into seperate directories)
• what happens when the package database goes "poof"

i'm not saying don't use package management. i'm not saying don't use rpm. i'm actually agreeing with the topic for once and suggesting that we actually do need to change the filesystem.

One point is that Qmail's author issued a Cash Reward for the first person to find a security hole in qmail- That was in march 1997 and it still has not been claimed.

compare this to sendmail, where there's a security hole fix in EVERY release.

Qmail is also AWESOME at handling high amounts of email sanely, is absolutely simple to configure, has a large and very supportive user base, and again, it was designed with security in mind.

Apart from that, ezmlm is EASY to configure, and if you get the "qmailadmin" program, you also have an easy web-based configuration interface, if you prefer that. (though, I myself prefer the commandline tools.)

The one thing you'll have to get used to is the 'Maildir' format, which applies to anyone using a shell on the qmail server to check / receive email- mutt has builtin maildir support, there's a patch available for pine.

qmail's home location is http://cr.yp.to/qmail.html and it's supporting community is at http://www.qmail.org

One point is that Qmail's author issued a Cash Reward for the first person to find a security hole in qmail- That was in march 1997 and it still has not been claimed.

compare this to sendmail, where there's a security hole fix in EVERY release.

Qmail is also AWESOME at handling high amounts of email sanely, is absolutely simple to configure, has a large and very supportive user base, and again, it was designed with security in mind.

Apart from that, ezmlm is EASY to configure, and if you get the "qmailadmin" program, you also have an easy web-based configuration interface, if you prefer that. (though, I myself prefer the commandline tools.)

The one thing you'll have to get used to is the 'Maildir' format, which applies to anyone using a shell on the qmail server to check / receive email- mutt has builtin maildir support, there's a patch available for pine.

qmail's home location is http://cr.yp.to/qmail.html and it's supporting community is at http://www.qmail.org

I don't want to get used to sendmail's configuration syntax. I don't want to keep one thing untouched, while editing other thing and regenerating one from the other. This is silly. I've got better things to do.

As of October 2001, 717000 SMTP servers used qmail. Read Dan's surveys. Qmail is second Unix MTA in the Internet. Don't you think this (17%) IS a reasonable percentage? Read the Red Hat case somewhere on cr.yp.to. I've also switched from sendmail (installed by default on my distro), to qmail, and observe a great performance gain.
What is Dan's license? You can download, compile, and run his software for free. What else do you need?

I agree in one point: we all have the choice.

I've read qmail's sources. I believe it's secure. There were NO security holes found in qmail.
One more thing: it's quite possible you'll never need to contact qmail-users list (or read Life with Qmail). Qmail is extremely easy to set up. And once it's up, you simply don't need to upgrade it. It just goes and goes...
Security hole is a bug, right? BIND is buggy.

False. If you have a lot of data in your zone files, BIND 9 will take quite a while to read that data into memory. All queries for not-yet-read data will fail.

``The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed.''

False. With tinydns, a syntax error will not be copied to the slaves. In fact, the master will continue supplying the previous data, unlike BIND, where the master starts responding SERVFAIL to all queries in that zone.

``Without a third party patch, tinydns does not support standard SRV records.''

False. See newtypes.html.

``Without a patch from a third party, tinydns does not listen to more than one IP address. ... Like tinydns, dnscache will not bind to more than one IP address without a third party patch.''

False on both counts. Adding another cache IP address, for example, is a simple matter of running dnscache-conf. Even better, on SMP machines, traffic to the second IP address is automatically handled by a separate CPU.

``By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt [sic] of the RFCs, as well as the letter.''

False. See faq/tinydns.html#tcp for an explanation of when you need to set up TCP service. The RFCs do not require TCP service. (On the other hand, if you follow my instructions to upgrade from BIND, you'll have TCP service.)

``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).''

IQUERY support has never been required. The BIND company admits that IQUERY is unused and obsolete. The handling of IQUERY has no effect on DNS interoperability.

``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).''

This is a security feature. It has no effect on DNS interoperability.

``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.''

Anyone who understands DNS knows that all such referrals are discarded by clients, and in fact must be discarded for security reasons. Omitting these referrals simplifies server configuration. It has no effect on DNS interoperability.

``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).''

This is an entirely optional standard. Omitting it has no effect on DNS interoperability. See faq/axfrdns.html#what for further discussion.

``Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.''

The DNS and BIND book, in the security section, tells BIND users to keep servers and caches separate. My instructions for upgrading from BIND explain how you can achieve this separation with a minimum of fuss.

``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).''

Notice how Knowles focuses on buzzwords rather than features. My users already have zero-outage database updates. My users already protect their networks with general-purpose tools such as ssh and IPSEC, so they don't need ad-hoc DNS-specific tools such as TSIG; Knowles is making a fool of himself when he suggests that TSIG helps ``VPNs based on IPSec.'' As for DNSSEC, see forgery.html. ``Strongly opposed'' is a complete misrepresentation of the situation.

``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.''

This is typical Knowles slander; notice the lack of details. As for my security guarantee, read the last sentence on the page.

``Benchmarks published by Rick Jones [hp.com] have clearly shown that BIND can scale up to at least 12,000 DNS queries per second... The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second.''

This is a ridiculous comparison:

• The 12000 is a maximum: a test load pumped as high as possible until BIND choked (on a big machine, by the way).
• The 500 is not a maximum: it is a real load for a production site, far below the maximum that tinydns could handle.
  

By the way, that production site is now part of Namezero, the largest domain-hosting company on the Internet, publishing more than two million second-level domains with tinydns.

False. If you have a lot of data in your zone files, BIND 9 will take quite a while to read that data into memory. All queries for not-yet-read data will fail.

``The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed.''

False. With tinydns, a syntax error will not be copied to the slaves. In fact, the master will continue supplying the previous data, unlike BIND, where the master starts responding SERVFAIL to all queries in that zone.

``Without a third party patch, tinydns does not support standard SRV records.''

False. See newtypes.html.

``Without a patch from a third party, tinydns does not listen to more than one IP address. ... Like tinydns, dnscache will not bind to more than one IP address without a third party patch.''

False on both counts. Adding another cache IP address, for example, is a simple matter of running dnscache-conf. Even better, on SMP machines, traffic to the second IP address is automatically handled by a separate CPU.

``By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt [sic] of the RFCs, as well as the letter.''

False. See faq/tinydns.html#tcp for an explanation of when you need to set up TCP service. The RFCs do not require TCP service. (On the other hand, if you follow my instructions to upgrade from BIND, you'll have TCP service.)

``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).''

IQUERY support has never been required. The BIND company admits that IQUERY is unused and obsolete. The handling of IQUERY has no effect on DNS interoperability.

``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).''

This is a security feature. It has no effect on DNS interoperability.

``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.''

Anyone who understands DNS knows that all such referrals are discarded by clients, and in fact must be discarded for security reasons. Omitting these referrals simplifies server configuration. It has no effect on DNS interoperability.

``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).''

This is an entirely optional standard. Omitting it has no effect on DNS interoperability. See faq/axfrdns.html#what for further discussion.

``Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.''

The DNS and BIND book, in the security section, tells BIND users to keep servers and caches separate. My instructions for upgrading from BIND explain how you can achieve this separation with a minimum of fuss.

``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).''

Notice how Knowles focuses on buzzwords rather than features. My users already have zero-outage database updates. My users already protect their networks with general-purpose tools such as ssh and IPSEC, so they don't need ad-hoc DNS-specific tools such as TSIG; Knowles is making a fool of himself when he suggests that TSIG helps ``VPNs based on IPSec.'' As for DNSSEC, see forgery.html. ``Strongly opposed'' is a complete misrepresentation of the situation.

``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.''

This is typical Knowles slander; notice the lack of details. As for my security guarantee, read the last sentence on the page.

``Benchmarks published by Rick Jones [hp.com] have clearly shown that BIND can scale up to at least 12,000 DNS queries per second... The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second.''

This is a ridiculous comparison:

• The 12000 is a maximum: a test load pumped as high as possible until BIND choked (on a big machine, by the way).
• The 500 is not a maximum: it is a real load for a production site, far below the maximum that tinydns could handle.
  

By the way, that production site is now part of Namezero, the largest domain-hosting company on the Internet, publishing more than two million second-level domains with tinydns.

False. If you have a lot of data in your zone files, BIND 9 will take quite a while to read that data into memory. All queries for not-yet-read data will fail.

``The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed.''

False. With tinydns, a syntax error will not be copied to the slaves. In fact, the master will continue supplying the previous data, unlike BIND, where the master starts responding SERVFAIL to all queries in that zone.

``Without a third party patch, tinydns does not support standard SRV records.''

False. See newtypes.html.

``Without a patch from a third party, tinydns does not listen to more than one IP address. ... Like tinydns, dnscache will not bind to more than one IP address without a third party patch.''

False on both counts. Adding another cache IP address, for example, is a simple matter of running dnscache-conf. Even better, on SMP machines, traffic to the second IP address is automatically handled by a separate CPU.

``By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt [sic] of the RFCs, as well as the letter.''

False. See faq/tinydns.html#tcp for an explanation of when you need to set up TCP service. The RFCs do not require TCP service. (On the other hand, if you follow my instructions to upgrade from BIND, you'll have TCP service.)

``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).''

IQUERY support has never been required. The BIND company admits that IQUERY is unused and obsolete. The handling of IQUERY has no effect on DNS interoperability.

``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).''

This is a security feature. It has no effect on DNS interoperability.

``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.''

Anyone who understands DNS knows that all such referrals are discarded by clients, and in fact must be discarded for security reasons. Omitting these referrals simplifies server configuration. It has no effect on DNS interoperability.

``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).''

This is an entirely optional standard. Omitting it has no effect on DNS interoperability. See faq/axfrdns.html#what for further discussion.

``Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.''

The DNS and BIND book, in the security section, tells BIND users to keep servers and caches separate. My instructions for upgrading from BIND explain how you can achieve this separation with a minimum of fuss.

``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).''

Notice how Knowles focuses on buzzwords rather than features. My users already have zero-outage database updates. My users already protect their networks with general-purpose tools such as ssh and IPSEC, so they don't need ad-hoc DNS-specific tools such as TSIG; Knowles is making a fool of himself when he suggests that TSIG helps ``VPNs based on IPSec.'' As for DNSSEC, see forgery.html. ``Strongly opposed'' is a complete misrepresentation of the situation.

``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.''

This is typical Knowles slander; notice the lack of details. As for my security guarantee, read the last sentence on the page.

``Benchmarks published by Rick Jones [hp.com] have clearly shown that BIND can scale up to at least 12,000 DNS queries per second... The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second.''

This is a ridiculous comparison:

• The 12000 is a maximum: a test load pumped as high as possible until BIND choked (on a big machine, by the way).
• The 500 is not a maximum: it is a real load for a production site, far below the maximum that tinydns could handle.
  

By the way, that production site is now part of Namezero, the largest domain-hosting company on the Internet, publishing more than two million second-level domains with tinydns.

False. If you have a lot of data in your zone files, BIND 9 will take quite a while to read that data into memory. All queries for not-yet-read data will fail.

``The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed.''

False. With tinydns, a syntax error will not be copied to the slaves. In fact, the master will continue supplying the previous data, unlike BIND, where the master starts responding SERVFAIL to all queries in that zone.

``Without a third party patch, tinydns does not support standard SRV records.''

False. See newtypes.html.

``Without a patch from a third party, tinydns does not listen to more than one IP address. ... Like tinydns, dnscache will not bind to more than one IP address without a third party patch.''

False on both counts. Adding another cache IP address, for example, is a simple matter of running dnscache-conf. Even better, on SMP machines, traffic to the second IP address is automatically handled by a separate CPU.

``By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt [sic] of the RFCs, as well as the letter.''

False. See faq/tinydns.html#tcp for an explanation of when you need to set up TCP service. The RFCs do not require TCP service. (On the other hand, if you follow my instructions to upgrade from BIND, you'll have TCP service.)

``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).''

IQUERY support has never been required. The BIND company admits that IQUERY is unused and obsolete. The handling of IQUERY has no effect on DNS interoperability.

``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).''

This is a security feature. It has no effect on DNS interoperability.

``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.''

Anyone who understands DNS knows that all such referrals are discarded by clients, and in fact must be discarded for security reasons. Omitting these referrals simplifies server configuration. It has no effect on DNS interoperability.

``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).''

This is an entirely optional standard. Omitting it has no effect on DNS interoperability. See faq/axfrdns.html#what for further discussion.

``Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.''

The DNS and BIND book, in the security section, tells BIND users to keep servers and caches separate. My instructions for upgrading from BIND explain how you can achieve this separation with a minimum of fuss.

``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).''

Notice how Knowles focuses on buzzwords rather than features. My users already have zero-outage database updates. My users already protect their networks with general-purpose tools such as ssh and IPSEC, so they don't need ad-hoc DNS-specific tools such as TSIG; Knowles is making a fool of himself when he suggests that TSIG helps ``VPNs based on IPSec.'' As for DNSSEC, see forgery.html. ``Strongly opposed'' is a complete misrepresentation of the situation.

``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.''

This is typical Knowles slander; notice the lack of details. As for my security guarantee, read the last sentence on the page.

``Benchmarks published by Rick Jones [hp.com] have clearly shown that BIND can scale up to at least 12,000 DNS queries per second... The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second.''

This is a ridiculous comparison:

• The 12000 is a maximum: a test load pumped as high as possible until BIND choked (on a big machine, by the way).
• The 500 is not a maximum: it is a real load for a production site, far below the maximum that tinydns could handle.
  

By the way, that production site is now part of Namezero, the largest domain-hosting company on the Internet, publishing more than two million second-level domains with tinydns.

False. If you have a lot of data in your zone files, BIND 9 will take quite a while to read that data into memory. All queries for not-yet-read data will fail.

``The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed.''

False. With tinydns, a syntax error will not be copied to the slaves. In fact, the master will continue supplying the previous data, unlike BIND, where the master starts responding SERVFAIL to all queries in that zone.

``Without a third party patch, tinydns does not support standard SRV records.''

False. See newtypes.html.

``Without a patch from a third party, tinydns does not listen to more than one IP address. ... Like tinydns, dnscache will not bind to more than one IP address without a third party patch.''

False on both counts. Adding another cache IP address, for example, is a simple matter of running dnscache-conf. Even better, on SMP machines, traffic to the second IP address is automatically handled by a separate CPU.

``By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt [sic] of the RFCs, as well as the letter.''

False. See faq/tinydns.html#tcp for an explanation of when you need to set up TCP service. The RFCs do not require TCP service. (On the other hand, if you follow my instructions to upgrade from BIND, you'll have TCP service.)

``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).''

IQUERY support has never been required. The BIND company admits that IQUERY is unused and obsolete. The handling of IQUERY has no effect on DNS interoperability.

``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).''

This is a security feature. It has no effect on DNS interoperability.

``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.''

Anyone who understands DNS knows that all such referrals are discarded by clients, and in fact must be discarded for security reasons. Omitting these referrals simplifies server configuration. It has no effect on DNS interoperability.

``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).''

This is an entirely optional standard. Omitting it has no effect on DNS interoperability. See faq/axfrdns.html#what for further discussion.

``Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.''

The DNS and BIND book, in the security section, tells BIND users to keep servers and caches separate. My instructions for upgrading from BIND explain how you can achieve this separation with a minimum of fuss.

``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).''

Notice how Knowles focuses on buzzwords rather than features. My users already have zero-outage database updates. My users already protect their networks with general-purpose tools such as ssh and IPSEC, so they don't need ad-hoc DNS-specific tools such as TSIG; Knowles is making a fool of himself when he suggests that TSIG helps ``VPNs based on IPSec.'' As for DNSSEC, see forgery.html. ``Strongly opposed'' is a complete misrepresentation of the situation.

``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.''

This is typical Knowles slander; notice the lack of details. As for my security guarantee, read the last sentence on the page.

``Benchmarks published by Rick Jones [hp.com] have clearly shown that BIND can scale up to at least 12,000 DNS queries per second... The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second.''

This is a ridiculous comparison:

• The 12000 is a maximum: a test load pumped as high as possible until BIND choked (on a big machine, by the way).
• The 500 is not a maximum: it is a real load for a production site, far below the maximum that tinydns could handle.
  

By the way, that production site is now part of Namezero, the largest domain-hosting company on the Internet, publishing more than two million second-level domains with tinydns.

False. If you have a lot of data in your zone files, BIND 9 will take quite a while to read that data into memory. All queries for not-yet-read data will fail.

``The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed.''

False. With tinydns, a syntax error will not be copied to the slaves. In fact, the master will continue supplying the previous data, unlike BIND, where the master starts responding SERVFAIL to all queries in that zone.

``Without a third party patch, tinydns does not support standard SRV records.''

False. See newtypes.html.

``Without a patch from a third party, tinydns does not listen to more than one IP address. ... Like tinydns, dnscache will not bind to more than one IP address without a third party patch.''

False on both counts. Adding another cache IP address, for example, is a simple matter of running dnscache-conf. Even better, on SMP machines, traffic to the second IP address is automatically handled by a separate CPU.

``By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt [sic] of the RFCs, as well as the letter.''

False. See faq/tinydns.html#tcp for an explanation of when you need to set up TCP service. The RFCs do not require TCP service. (On the other hand, if you follow my instructions to upgrade from BIND, you'll have TCP service.)

``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).''

IQUERY support has never been required. The BIND company admits that IQUERY is unused and obsolete. The handling of IQUERY has no effect on DNS interoperability.

``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).''

This is a security feature. It has no effect on DNS interoperability.

``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.''

Anyone who understands DNS knows that all such referrals are discarded by clients, and in fact must be discarded for security reasons. Omitting these referrals simplifies server configuration. It has no effect on DNS interoperability.

``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).''

This is an entirely optional standard. Omitting it has no effect on DNS interoperability. See faq/axfrdns.html#what for further discussion.

``Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.''

The DNS and BIND book, in the security section, tells BIND users to keep servers and caches separate. My instructions for upgrading from BIND explain how you can achieve this separation with a minimum of fuss.

``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).''

Notice how Knowles focuses on buzzwords rather than features. My users already have zero-outage database updates. My users already protect their networks with general-purpose tools such as ssh and IPSEC, so they don't need ad-hoc DNS-specific tools such as TSIG; Knowles is making a fool of himself when he suggests that TSIG helps ``VPNs based on IPSec.'' As for DNSSEC, see forgery.html. ``Strongly opposed'' is a complete misrepresentation of the situation.

``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.''

This is typical Knowles slander; notice the lack of details. As for my security guarantee, read the last sentence on the page.

``Benchmarks published by Rick Jones [hp.com] have clearly shown that BIND can scale up to at least 12,000 DNS queries per second... The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second.''

This is a ridiculous comparison:

• The 12000 is a maximum: a test load pumped as high as possible until BIND choked (on a big machine, by the way).
• The 500 is not a maximum: it is a real load for a production site, far below the maximum that tinydns could handle.
  

By the way, that production site is now part of Namezero, the largest domain-hosting company on the Internet, publishing more than two million second-level domains with tinydns.

False. If you have a lot of data in your zone files, BIND 9 will take quite a while to read that data into memory. All queries for not-yet-read data will fail.

``The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed.''

False. With tinydns, a syntax error will not be copied to the slaves. In fact, the master will continue supplying the previous data, unlike BIND, where the master starts responding SERVFAIL to all queries in that zone.

``Without a third party patch, tinydns does not support standard SRV records.''

False. See newtypes.html.

``Without a patch from a third party, tinydns does not listen to more than one IP address. ... Like tinydns, dnscache will not bind to more than one IP address without a third party patch.''

False on both counts. Adding another cache IP address, for example, is a simple matter of running dnscache-conf. Even better, on SMP machines, traffic to the second IP address is automatically handled by a separate CPU.

``By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt [sic] of the RFCs, as well as the letter.''

False. See faq/tinydns.html#tcp for an explanation of when you need to set up TCP service. The RFCs do not require TCP service. (On the other hand, if you follow my instructions to upgrade from BIND, you'll have TCP service.)

``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).''

IQUERY support has never been required. The BIND company admits that IQUERY is unused and obsolete. The handling of IQUERY has no effect on DNS interoperability.

``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).''

This is a security feature. It has no effect on DNS interoperability.

``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.''

Anyone who understands DNS knows that all such referrals are discarded by clients, and in fact must be discarded for security reasons. Omitting these referrals simplifies server configuration. It has no effect on DNS interoperability.

``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).''

This is an entirely optional standard. Omitting it has no effect on DNS interoperability. See faq/axfrdns.html#what for further discussion.

``Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.''

The DNS and BIND book, in the security section, tells BIND users to keep servers and caches separate. My instructions for upgrading from BIND explain how you can achieve this separation with a minimum of fuss.

``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).''

Notice how Knowles focuses on buzzwords rather than features. My users already have zero-outage database updates. My users already protect their networks with general-purpose tools such as ssh and IPSEC, so they don't need ad-hoc DNS-specific tools such as TSIG; Knowles is making a fool of himself when he suggests that TSIG helps ``VPNs based on IPSec.'' As for DNSSEC, see forgery.html. ``Strongly opposed'' is a complete misrepresentation of the situation.

``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.''

This is typical Knowles slander; notice the lack of details. As for my security guarantee, read the last sentence on the page.

``Benchmarks published by Rick Jones [hp.com] have clearly shown that BIND can scale up to at least 12,000 DNS queries per second... The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second.''

This is a ridiculous comparison:

• The 12000 is a maximum: a test load pumped as high as possible until BIND choked (on a big machine, by the way).
• The 500 is not a maximum: it is a real load for a production site, far below the maximum that tinydns could handle.
  

By the way, that production site is now part of Namezero, the largest domain-hosting company on the Internet, publishing more than two million second-level domains with tinydns.

False. If you have a lot of data in your zone files, BIND 9 will take quite a while to read that data into memory. All queries for not-yet-read data will fail.

``The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed.''

False. With tinydns, a syntax error will not be copied to the slaves. In fact, the master will continue supplying the previous data, unlike BIND, where the master starts responding SERVFAIL to all queries in that zone.

``Without a third party patch, tinydns does not support standard SRV records.''

False. See newtypes.html.

``Without a patch from a third party, tinydns does not listen to more than one IP address. ... Like tinydns, dnscache will not bind to more than one IP address without a third party patch.''

False on both counts. Adding another cache IP address, for example, is a simple matter of running dnscache-conf. Even better, on SMP machines, traffic to the second IP address is automatically handled by a separate CPU.

``By default, tinydns does not support the use of TCP at all. This most definitely violates the spirt [sic] of the RFCs, as well as the letter.''

False. See faq/tinydns.html#tcp for an explanation of when you need to set up TCP service. The RFCs do not require TCP service. (On the other hand, if you follow my instructions to upgrade from BIND, you'll have TCP service.)

``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).''

IQUERY support has never been required. The BIND company admits that IQUERY is unused and obsolete. The handling of IQUERY has no effect on DNS interoperability.

``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).''

This is a security feature. It has no effect on DNS interoperability.

``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.''

Anyone who understands DNS knows that all such referrals are discarded by clients, and in fact must be discarded for security reasons. Omitting these referrals simplifies server configuration. It has no effect on DNS interoperability.

``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).''

This is an entirely optional standard. Omitting it has no effect on DNS interoperability. See faq/axfrdns.html#what for further discussion.

``Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.''

The DNS and BIND book, in the security section, tells BIND users to keep servers and caches separate. My instructions for upgrading from BIND explain how you can achieve this separation with a minimum of fuss.

``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).''

Notice how Knowles focuses on buzzwords rather than features. My users already have zero-outage database updates. My users already protect their networks with general-purpose tools such as ssh and IPSEC, so they don't need ad-hoc DNS-specific tools such as TSIG; Knowles is making a fool of himself when he suggests that TSIG helps ``VPNs based on IPSec.'' As for DNSSEC, see forgery.html. ``Strongly opposed'' is a complete misrepresentation of the situation.

``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.''

This is typical Knowles slander; notice the lack of details. As for my security guarantee, read the last sentence on the page.

``Benchmarks published by Rick Jones [hp.com] have clearly shown that BIND can scale up to at least 12,000 DNS queries per second... The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second.''

This is a ridiculous comparison:

• The 12000 is a maximum: a test load pumped as high as possible until BIND choked (on a big machine, by the way).
• The 500 is not a maximum: it is a real load for a production site, far below the maximum that tinydns could handle.
  

By the way, that production site is now part of Namezero, the largest domain-hosting company on the Internet, publishing more than two million second-level domains with tinydns.

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.

Right, there's another tool for that, dnscache. It isn't monolithic like BIND, in the spirit of unix.

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.

What's your proof of this? DNS is designed to use UDP. No data should be longer than what fits in a normal UDP response.

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. The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed. Contrariwise, if you use the standard zone transfer mechanism, then the zone transfer should fail if the master is munged, and the slaves should keep a good working copy for a while and give you time to notice that the master is munged and needs to be fixed.

If you read his comments on this, then it makes perfect sense. There are already existing, secure tools that do the job better. No need to invent another bloated and potentially buggy and insecure protocol. How often do you corrupt the database, or mess up an rsync or rcp? In any case, when do you not have a backup of your zone files?

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).

If you use the (better) transfer method that he recommends, this isn't a problem.

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.

So run put two IP addresses on the machine, and run them on different IP's.

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.

If you read his page about DNS forgery, then you'd see why he is against it.

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.

What code doesn't have bugs? Is he supposed to test it indefinitely, and never release for fear of there being some obscure bug that didn't affect him when testing? There is a difference between bugs and security holes. As far as I know, none of his code has ever had security holes. He clearly seems to know what he is doing, and has right to gripe about programs like BIND and Sendmail being buggy. His guarantee is for security holes. I don't see other software making any sort of guarantee. If Microsoft offered $500 for every security hole, would they still be in business? If you check securityfocus.com, the only problem ever reported is a DoS attack against qmail on something that the OS should provide (resource limits).

One argument frequently used to support the use of djbdns over BIND is performance.

So there aren't any real published benchmarks? We don't have nearly that kind of traffic, so I can't say anything about it personally. Also, tinydns is not a cache, so it should not be used for heavily loaded servers. That is what dnscache is for. If you read the blurbs, you'll see someone who found that dnscache outperforms BIND 9. If you use his tools the way they are designed to be used, you'll find they work quite well.

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.

BIND 9 was not out when djbdns was written, so it makes sense that he would address issues that existed when it was written. Perhaps they actually addressed some of these in BIND 9 due to djbdns? It is very likely that BIND 9 will have the same types of bugs that all the other versions do. Read his papaper for more details. BIND is huge, and takes up a lot of resources. We have servers running BIND that take minutes to load, and use 40-80 megs of ram.

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.

Right, there's another tool for that, dnscache. It isn't monolithic like BIND, in the spirit of unix.

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.

What's your proof of this? DNS is designed to use UDP. No data should be longer than what fits in a normal UDP response.

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. The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed. Contrariwise, if you use the standard zone transfer mechanism, then the zone transfer should fail if the master is munged, and the slaves should keep a good working copy for a while and give you time to notice that the master is munged and needs to be fixed.

If you read his comments on this, then it makes perfect sense. There are already existing, secure tools that do the job better. No need to invent another bloated and potentially buggy and insecure protocol. How often do you corrupt the database, or mess up an rsync or rcp? In any case, when do you not have a backup of your zone files?

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).

If you use the (better) transfer method that he recommends, this isn't a problem.

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.

So run put two IP addresses on the machine, and run them on different IP's.

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.

If you read his page about DNS forgery, then you'd see why he is against it.

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.

What code doesn't have bugs? Is he supposed to test it indefinitely, and never release for fear of there being some obscure bug that didn't affect him when testing? There is a difference between bugs and security holes. As far as I know, none of his code has ever had security holes. He clearly seems to know what he is doing, and has right to gripe about programs like BIND and Sendmail being buggy. His guarantee is for security holes. I don't see other software making any sort of guarantee. If Microsoft offered $500 for every security hole, would they still be in business? If you check securityfocus.com, the only problem ever reported is a DoS attack against qmail on something that the OS should provide (resource limits).

One argument frequently used to support the use of djbdns over BIND is performance.

So there aren't any real published benchmarks? We don't have nearly that kind of traffic, so I can't say anything about it personally. Also, tinydns is not a cache, so it should not be used for heavily loaded servers. That is what dnscache is for. If you read the blurbs, you'll see someone who found that dnscache outperforms BIND 9. If you use his tools the way they are designed to be used, you'll find they work quite well.

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.

BIND 9 was not out when djbdns was written, so it makes sense that he would address issues that existed when it was written. Perhaps they actually addressed some of these in BIND 9 due to djbdns? It is very likely that BIND 9 will have the same types of bugs that all the other versions do. Read his papaper for more details. BIND is huge, and takes up a lot of resources. We have servers running BIND that take minutes to load, and use 40-80 megs of ram.

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.

Right, there's another tool for that, dnscache. It isn't monolithic like BIND, in the spirit of unix.

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.

What's your proof of this? DNS is designed to use UDP. No data should be longer than what fits in a normal UDP response.

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. The problem is that if you make a mistake and munge the database and then rsync or rcp that to the backup servers, you're totally hosed. Contrariwise, if you use the standard zone transfer mechanism, then the zone transfer should fail if the master is munged, and the slaves should keep a good working copy for a while and give you time to notice that the master is munged and needs to be fixed.

If you read his comments on this, then it makes perfect sense. There are already existing, secure tools that do the job better. No need to invent another bloated and potentially buggy and insecure protocol. How often do you corrupt the database, or mess up an rsync or rcp? In any case, when do you not have a backup of your zone files?

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).

If you use the (better) transfer method that he recommends, this isn't a problem.

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.

So run put two IP addresses on the machine, and run them on different IP's.

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.

If you read his page about DNS forgery, then you'd see why he is against it.

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.

What code doesn't have bugs? Is he supposed to test it indefinitely, and never release for fear of there being some obscure bug that didn't affect him when testing? There is a difference between bugs and security holes. As far as I know, none of his code has ever had security holes. He clearly seems to know what he is doing, and has right to gripe about programs like BIND and Sendmail being buggy. His guarantee is for security holes. I don't see other software making any sort of guarantee. If Microsoft offered $500 for every security hole, would they still be in business? If you check securityfocus.com, the only problem ever reported is a DoS attack against qmail on something that the OS should provide (resource limits).

One argument frequently used to support the use of djbdns over BIND is performance.

So there aren't any real published benchmarks? We don't have nearly that kind of traffic, so I can't say anything about it personally. Also, tinydns is not a cache, so it should not be used for heavily loaded servers. That is what dnscache is for. If you read the blurbs, you'll see someone who found that dnscache outperforms BIND 9. If you use his tools the way they are designed to be used, you'll find they work quite well.

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.

BIND 9 was not out when djbdns was written, so it makes sense that he would address issues that existed when it was written. Perhaps they actually addressed some of these in BIND 9 due to djbdns? It is very likely that BIND 9 will have the same types of bugs that all the other versions do. Read his papaper for more details. BIND is huge, and takes up a lot of resources. We have servers running BIND that take minutes to load, and use 40-80 megs of ram.

Not a fair criticism, since the standard was written to BIND's implementation, not the other way around. BIND's zone file format is in the RFCs, as part of the standard. Any DNS server that uses a SQL backend is non-compliant on this count alone.

But even BIND deviates from the standard written to it's implementation in many places. See http://cr.yp.to/djbdns/notes.html for some examples.

There is no license along with his programs, and absent a license you have NO RIGHT to share, study, or change Bernstein's code!

You didn't supply a license with your post, so may I presume your attorneys will be contacting me for quoting part of your silly diatribe?

Come on! Open your mind! Apache is ok but both Sendmail and BIND are evil. Sendmail is buggy and slow. Sendmail is full of security holes.
BIND, in turn, is buggy and slow. BIND is full of security holes.
They've both been like that since the very beginning. Dan's alternatives are fast, secure, and easy to set up. That's why qmail version of Bat Book would have 50 pages :) There is a mailing list for both djbdns and qmail, where you can get help for any problem you encounter.
I don't believe in "complete rewrites". Read the ChangeLogs. There are lots of BIG bugs in BIND 9. Or even better - look from Dan's point of view.

See here. kthx.

djbdns (and qmail, etc) are NOT under a restrictive license as you like to argue. In fact, they are under no license. DJB simply doesn't believe that software licenses are valid, so he doesn't grant one. His "license" page that you refer to simply reiterates his right of first distribution, as well as waiving some of his right to first distribution under certain circumstances. Read this for more background on why DJB doesn't issue licenses.

The only appearance of the word license on that page is in a quote from a RedHat employee, not DJB. It would seem impossible to me to grant a license without specifically stating that you are granting a license.

The inability to change pathnames is a bunch of hooey. I've seen packages included with a major distribution that could have been modified to use paths that make more sense, but have been packaged with the author's defaults instead.

xjosh

Lots of people have:

DJB DNS

Custom DNS

MaraDNS

Posadis (though I've no experience with it yet)

The list goes on and on.. hit Freshmeat.net for some possibilties.

I guess thses must be typos...

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

http://cr.yp.to/djbdns/faq/axfrdns.html#config

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

http://cr.yp.to/djbdns/axfr-get.html

Please... learn to have an *informed* opinion.

I guess thses must be typos...

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

http://cr.yp.to/djbdns/faq/axfrdns.html#config

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

http://cr.yp.to/djbdns/axfr-get.html

Please... learn to have an *informed* opinion.

I guess thses must be typos...

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

http://cr.yp.to/djbdns/faq/axfrdns.html#config

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

http://cr.yp.to/djbdns/axfr-get.html

Please... learn to have an *informed* opinion.

I guess thses must be typos...

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

http://cr.yp.to/djbdns/faq/axfrdns.html#config

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

http://cr.yp.to/djbdns/axfr-get.html

Please... learn to have an *informed* opinion.

If he was cracked several times, he should change the named, not the whole OS...

Djbdns site has good information how to upgrade to djbdns from bind.

Since you enjoy reading him state he'll give you cash, read the limits to your rights with djbdns/qmail.