Slashdot Mirror

If bind is the preferred implementation, is

You can't use bind for this type of application; bind can't handle zones of these sizes.

try either: rbldnsd or rbldns.

there a standardized/automated way to build a configuration file with the data from blackholes.us?

blackholes.us already publishes their data via dns. just set your mta to check against, for example, brazil.blackholes.us or cn-kr.blackholes.us

Personally, I get anywhere between one thousand and one hundred thousand spams a week directed at my domain from some asshat in Brazil. They come addressed to user1@mydomain.com, user2@mydomain.com, etc., in alphabetical order. Tens of thousands of them. And that's just the Brazilian stuff. That doesn't include the mortgage ads, 419 scams, porn ads, and advertisements that will help me make my wife's penis larger.

Since I'm the only person who uses my domain, and I don't read Portuguese anyway, these are nothing but a drain on my bandwidth and resources, even if I were inclined to buy penis enlargement cream for my wife.

And since I use a hosting service I can't implement a connection-level block because I don't have root on the box. Implementing SpamAssassin on the hosting server brings their box to its knees (I know because I've done it and they shut down my account); instead, I have to dedicate one of my own boxes to scanning all this shit -after- downloading it. My box does virtually nothing else.

And since my domain is my last name, I can't exactly change it easily.

SMTP is broken. It has outlived its usefulness, and it is past time for it to die. Born in an era when the internet was a far safer place, patches and scanning placed on top of it to stop spam do nothing to put the burden of sending mail where it belongs: on the sender. While tools like SpamAssassin, SpamBouncer and RBLs help us to avoid seeing the crap in our inboxes, they remain kludges that still eat up our processor time, bandwidth, infrastructure and money.

But all my work in call centers has taught me that stupid people will always exist, and that some of them can never be taught to behave properly. This means that any schmuck with enough money and enough time and some basic Google literacy can set up a broken copy of $YOUR_FAVORITE_SMTPD on $YOUR_FAVORITE_OS and become the latest spew.

Proposals exist (Dr. Dan Bernstein's Internet Mail 2000 is one of several) to shift the burden of storage and processing from the receiver to the sender. All well and good, but nobody's bothered writing a bunch of cross-platform implementations that everybody will actually switch to, and that Microsoft won't be able to embrace and extend.

So where does that leave us mere mortals, except to use the hypersonic planet-smashing axe to kill the maggot-laying fly?

``He goes to St Petersburg and complains about the hotel''---C'mon, that's hardly a fair summary. You could at least mention the part where they pumped poison gas into my hotel room.

No it can't be read as that. Look at the reward page. Now tell me why hes so eager to exclused "programs outside of qmail?" The reason is simple, thats where many bugs have been found and while sendmail has many thousands of lines of code to work around them, qmail doesn't. Which is more secure? A program that works around a broken syscall in Linux or one that ignores it?

There are two very large dangers with qmail...that it will go off in a random direction no one agrees with

There is another theory which states that this has already happened.

and that the qmail maintainer will just stop releasing new versions

To quote the qmail web site: The latest published qmail package is qmail-1.03.tar.gz, which was released in June 1998. So again, this may have happened already.

Yeah, and he's right, we need a good alternative to BIND. Too bad djbdns is just Bernstein's tool for trying to shape the Internet to his liking.

It isn't RFC-compliant and DJB takes the typical attitude of the cocky security programmer. For instance, he doesn't really care about implementing such unnecessary protocol add-ons as notify or ixfr, but advocates rsync - with a straight face.

> I continue to use BIND because I don't like DJB's licence.

I call FUD. djb thinks licensing is a lot of nonsense.

Hence, my copy of Qmail doesn't even get shipped with a license.

There's a lot of crap talked about the "evil Qmail license", crap because no such thing exists unless you happen to ask djb to give you one. As djb puts it:

"If you think you need a license from the copyright holder, you've been bamboozled by Microsoft."

There hasn't been any significant security issue with BIND 9. Period.

So Dan's comments about BIND 9 having 672 bugs in its history up to 9.2.2rc1 in 2002/08/08 don't warrant attention? How can anything have 672 bugs in somethat that should be so simple and not one of them be a possible security issue? Granted some of the "bugs" are "added another root server" which is more like a request. #1318 "libbind: Remote buffer overrun"

Dan mentions Bug 1252 which is "Dig, host and nslookup were not checking the address the answer was coming from against the address it was sent to." I suppose that's not a security risk where someone could easily forge DNS replies. I see a race condition #1523

So? If he wanted a quality DNS server, he would have asked about DJBDNS.

Dan Bernstein might be an, uh, "colourful" character, but his software is fast, easy to use, easy to admin, and all around better than anything Vixie & crew could offer. Plus this guy's devotion to security is nothing less than astounding. I trust his internet tools wherever possible...shit, i even run an instance of his no frills HTTP server for images.

Bernstein is a certifiable loon. He regularly flames people on the bind9-users list, and if there was any doubt that he is a complete DWEEB, read this. He goes to St Petersburg and complains about the hotel and eats at Burger King. Whatever. The guy is a nut. A smart nut, but a nut.

His software also has onerous restrictions on it, and djbdns does not support as many record types and such as bind does. His rantings about bind are full tilt hysterical conspiracy theory level paranoia.

D. J. Bernstein has a few things to say about this Also see here And here

D. J. Bernstein has a few things to say about this Also see here And here

D. J. Bernstein has a few things to say about this Also see here And here

Exploits are not uncommon in BIND, even today. Take a look at their security alert page, especially the matrix at the bottom. Security problems abound!

It's not clear why people continue to use BIND. It's probably because it's just assumed that it's the only thing out there. But everything from security to configuration is poorly done in BIND. I use tinydns (part of djbdns) instead on all my servers. It's written by Daniel Bernstein, the same guy that wrote qmail. He's got a great track record -- no security holes in any of his software, AND he backs up that assertion with a $1000 prize to anyone that finds such a hole. He makes a better case than I do for tinydns/qmail vs. BIND/sendmail than I ever could.

If I were a starting programmer, I would try and find some great master to study under, the same way other artists do. My first choice would be Dan Bernstein.

Another way would be to go to India and work there for five years or so. Since that is where the global market value of programming seems to be set. If your expectations are any higher than that, then you are probably pricing yourself out of the market.

On the other hand, most programmers do very, very little, and take a very, very long time to do it, and complain a great deal in the process. If you were to be one of those rare, maybe even mythical, types that can write useful code and a commercially sensible timeframe, well, you should be paid whatever you want.

Secondary, off-site DNS doesn't gain you much if the real services (HTTP, SMTP, etc) aren't redundant as well. Read the section called "Erroneous arguments for third-party DNS service" in DJB's Costs and benefits of third-party DNS service.

On his site :)

IM2000

There is no shortcut. You need daemontools because it relies on "service" for monitoring, logging, and rudimentary host based access control where applicable. Just READ THIS and follow the instructions. Take the time to understand what the difference is between dns-cache and tinydns. Do yourself a favor and install axfrdns if you install tinydns. If you are going to do authoritative nameserving, read up on all the goodness HERE. I've taken the time to install the VegaDNS administration front end and it's pretty neat. The most useful patches so far that I've used for tinydns are the round-robin dns patch, the errno patch (to get the bastard to rpmbuild on ES 3.0 but I think debian is still using fred flintstone's glibc so you should be cool) and the patch for the new zone transfer method that BIND 9 uses. If you aren't needing to mess with authoritative domain hosting, you probably only need DNScache. It's awesome stuff. Good Luck!

I read sci.crypt regularly, even if I don't post there. Granted, Tom comes forward as someone who has certain attitude problems (yes, I'm willing to go on record saying this) but the library is still a marvelous piece of work. It's not like we haven't seen controversial personalities in this field before. Also, LTC is nothing but a simple building block, and you can actually verify its functionality and integrity by running the algorithms against any known and verifiable test vector sets. (Locating these is left as an exercise for those interested.) Memory checkers such as valgrind and NJAMD can be used to ascertain that the library routines themselves work without memory flaws. (Especially dangerous when working with crypto, we wouldn't want to overwrite wrong data...)

The API is consistent, even if at times the need to return error codes means that the amount of bytes processed is written to a passed argument. And indeed, as another poster said, LTC is damn pretty and easy-to-use crypto library. Most of all, it's trivial to use only the parts you need and embed those to any program you're writing.

People here are always bitching about U.S. censorship gone awry, do you have any examples of such?

This case springs to mind. The government has prommised to stop thier harrassment for the moment, but until there is an actual ruling on this issue, I'm pretty sure that this pafrticular area of US govt. censorship is not quite dead yet.

Sounds like a modest proposal for reducing Internet traffic.

Except ... DJB has more of a point (heh) since svg is usually gzipped as opposed to plain-text smtp (so bandwidth gains are nil). Even for the more general case of xml transferred of http, you have Transfer-Encoding: gzip.

Show me some numbers on how this encoding saves orders of time in parsing and I'll listen. If all it does is encode tags as sequences of bits, it's just performing a weak form of dictionary compression and doesn't help at all with the real issue of data extraction (indexing specific points in the file). However, I can't find any numbers, nor any information whatsoever about the ebxml you describe after five minutes on google (everything points to "electronic business using XML", even along with terms like "wap" and "soap"). So perhaps ebxml isn't the Next Big Thing.

I read through your post and you give absolutely zero reasons why ebxml would be better than regular text-based xml:

1. Instead of the verbose tags and the tedious brackets

   What a minute, you're reading the XML text yourself or generating XML text from a script? You shouldn't do that. You see, generating XML using standard APIs in the "long term will save you from some headaches."

2. Ebxml can be parsed very efficiently (after all xml is nothing but a simple tree representation)

   After all, text-based XML and ebxml are nothing but simple tree representations.

   If you think about what ebxml does (dictionary compression on tags from what you describe), you'll see it saves absolutely no time whatsoever in parsing but merely removes the task of lexing. Lexing (symbol recognition) takes no time at all.

3. If you construct xml using an api rather than output text to some stream (which in the long term will save you from some headaches), ebxml makes no difference at all.

   Except that it's more difficult to "to read, debug and generate from scripts".

If you really want to cut bandwidth, you will note that so much of what we send over the Internet is plain text; therefore, we can ensure that Dave and Virginia go to college if we simply adopt some simple spelling reforms to cut the redundancy of English.

We've been hearing that for years. The best C security coders in the world are the OpenBSD team and guess what, they make mistakes. They fail to validate input sometimes. They have had exploitable bugs in their code.

Funny, then why have the qmail and djbdns security guarantees never been claimed? Perhaps because it really is possible to write secure code in C?

We've been hearing that for years. The best C security coders in the world are the OpenBSD team and guess what, they make mistakes. They fail to validate input sometimes. They have had exploitable bugs in their code.

Funny, then why have the qmail and djbdns security guarantees never been claimed? Perhaps because it really is possible to write secure code in C?

"How many pieces of software can you name that have NEVER had a buffer overflow exploit?"

ALL of Daniel J. Bernstein's software.

ALL written in C.

Put that in your pipe and smoke it.

OpenBSD and BSD/OS have one (bsd_auth) that exec()s small helper programs which implement the actual auth methods. These helpers speak a little protocol to the library via stdio.

That sounds very similar to the checkpassword program and interface. Is that a coincidence?

Yes, it is cool. Check out Dan Bernstein work on package management at http://cr.yp.to/slashpackage.html

My understanding is that he's working on qmail 2.0 right now. He was a little distracted, because he wanted to write the dns software, djbdns, first (lots of the software in djbdns will be reused in qmail).

He's taking time-off from teaching to write more software, and taking donations to help with the process.

The link you provide gives the answer: it's patched by Matt Simerson. DJB doesn't allow distribution of modified versions of qmail without his approval, but he does allow distribution of patches (not explicitly, but he claims that under copyright law you can't forbid distribution of patches, though others disagree). His strange licensing is the main reason qmail never became more popular and has gradually been losing mindshare to postfix, though qmail was there first and was clearly the best at the time. You can download a thing called netqmail from www.qmail.org, which is DJB's 1997 qmail-1.0.3 tarball plus patches that will automatically be applied; if he can allow that (or claim that he can't forbid that), I don't see why he can't allow distribution of modified binaries.

The link you provide gives the answer: it's patched by Matt Simerson. DJB doesn't allow distribution of modified versions of qmail without his approval, but he does allow distribution of patches (not explicitly, but he claims that under copyright law you can't forbid distribution of patches, though others disagree). His strange licensing is the main reason qmail never became more popular and has gradually been losing mindshare to postfix, though qmail was there first and was clearly the best at the time. You can download a thing called netqmail from www.qmail.org, which is DJB's 1997 qmail-1.0.3 tarball plus patches that will automatically be applied; if he can allow that (or claim that he can't forbid that), I don't see why he can't allow distribution of modified binaries.

Sure, this substitution means that the T40 is not officially a Centrino, but who cares? The OS uses the two antennas built into the laptop; it doesn't need a PCMCIA wireless card; it simply works.

Instead of messages being immediately sent to the recipient's server, send the recipient a very tiny message saying that a message with this subject is waiting on the sender's computer for the recipient to pick up.

Sounds like Internet Mail 2000.

Very recently, I've been writing some low-level code. There was a long while I'd thought this was out of my league. Then I realized several things:

• I was not happy with several characteristics of the low-level code other people had written and I was depending on.
• I had done some more low-level stuff long ago - like a couple simple but legitimately useful assembly programs in DOS, and even a patch that added a sort of capability system to the OpenBSD kernel. (I never polished up the patch enough to send it in to them or anything, but the point is that it essentially worked, and I wasn't afraid to take it on.)
• When I'd done those things back in the day, I wasn't anywhere near as good a coder as I am now.
• The only reason I'd been unable to do these things more recently is an attitude that I'm not good enough, not a reality. (It's an attitude a lot of people in low-level code promote, I think. They so much don't want to waste their time with people who really are bad that they probably don't mind scaring off a few people who are in fact good but don't realize it. Also, I think there's ego involved - it's an exclusive club, why not let it stay that way.)

So I think the moral of the story is to just be fearless/persistent. If you're not confident, there are plenty of ways you can improve without even involving anyone else:

• Read the code. It sounds obvious, but there's a lot of code I'd stayed away from even looking at because of intimidation.
• Try experiments. Make a change, set a hypothesis about what it will do, and run it. Then see why you were wrong, if you were. Then try it again. Even just getting in the habit of running the build system will help, and setting up experiments like this will help your debugging.
• Find something lacking and try to fix it.

And then, if you're still not comfortable talking on the linux-kernel list, I think you have at least another couple choices:

• If you're lucky, you're friendly with someone more skilled and can use him/her to screen questions.
• There's a couple lists like kernel-janitors and kernel-newbies to dip your feet in the water.
• Sometimes in the process of writing an eloquent question through email you'll figure out the answer yourself. (Did you see the teddy bear anecdote in the debugging link above?)

As for myself, I'm taking my own advice to make sigsafe - an alternate set of system call wrappers (libc level) that eliminate a couple race conditions involving signals, without a performance penalty. It's going well - the code works, and I have a race condition checker and microbenchmark to prove it. I just released my first version. Now I'm working on the documentation; it still needs a lot of work. (I could use plenty of help with this project! If you want to try low-level programming, it's a great way. It requires writing assembly for each combination of operating system and architecture. I've only written it for two systems. There are plenty left, and public systems to do it on if you don't have access to exotic machines of your own. Plus, you can hopefully gain some low-level understanding by proof-reading and helping me write the documentation.)

Once I have that polished, I've got a couple projects I might try in the Linux kernel (and/or other kernels):

• implementing a couple of system calls - the nonblocking_read(2) and nonblocking_write(2) that djb mentions.
• implementing SO_RCVTIMEO and SO_SNDTIMEO under Linux. Assuming no one has yet; I haven't checked, so the manpage could just be out of date. Which brings m

You're thinking of qmail. TeX was put into the public domain; it's even been included in many commercial products. See TUG for more information.

I wouldn't say everything, at least when the hacking has to be done over a network. The chance of having a vulnerability increases with the complexity of the program and the functionality it exposes. But some programs written with security and minimalism in mind have faired very well against hacking attempts.

qmail security guarantee

SELinux I've heard adds finer grained security features to limit each program's access to exactly what it needs, on top of the user level security, to further limit the damage that can be done by breaking a single program.

Actually, I do have a partial solution to spam, but in involves changing the email protocol to require the SENDER to store the email, rather than the receiver.

Congratulations. Maybe you and Mr. Bernstein could get together and discuss it?

This guy found a crash in qmail, too. I don't think he showed it was exploitable, so he doesn't win DJB's security guarantee prize. In fact I'm not sure DJB reacted to the news at all.

Yes, the NGMP implementation is here. NGMP is an implementation of Dan Bernstein's IM2000 concept using the XMPP protocol. It uses XMPP to notify you when you receive a new message. Notifications are sent via XMPP so it will also integrate with XMPP based instant messaging (aka Jabber).

dig NS .

I'm torn between the cushy redundancy offered by decentralization, and the cushy security of having most of the servers in a stable, well-protected country.

Fuirst of all, Germany is what most knowlegable people would call a "stable, well protected country".

Second, that in and of itself does not affect the security or reliability of DNS as it is designed very much, and has even less signifigance now that anycast is proven to be a reliable technique for increasing redundancy.

D. J. Bernstein has provided some good introductory about the workings of DNS, including security.

There's a chapter on DNS security from "DNS and BIND" available at the O'reilly website as well.

The biggest dispute about DNS security (and internet security in general) is between those who prefer centralized, single point solutions, and those who prefer distributed, autonomous security measures. IMHO, centralized security creates weakness in most (all?) cases by creating a single point of failure, and is an approach that is most often motivated by the desire to exert control over internet usage in hopes of personal gain (re: VeriSign), and to establish an authority because of a misguided belief that there need be one.

The internet's basic strength is due to it's lack of dependance on centralized authorities in order to work. Any proposals that change that basic assumption are either poorly thought out or suspect.

I'm torn between the cushy redundancy offered by decentralization, and the cushy security of having most of the servers in a stable, well-protected country.

Fuirst of all, Germany is what most knowlegable people would call a "stable, well protected country".

Second, that in and of itself does not affect the security or reliability of DNS as it is designed very much, and has even less signifigance now that anycast is proven to be a reliable technique for increasing redundancy.

D. J. Bernstein has provided some good introductory about the workings of DNS, including security.

There's a chapter on DNS security from "DNS and BIND" available at the O'reilly website as well.

The biggest dispute about DNS security (and internet security in general) is between those who prefer centralized, single point solutions, and those who prefer distributed, autonomous security measures. IMHO, centralized security creates weakness in most (all?) cases by creating a single point of failure, and is an approach that is most often motivated by the desire to exert control over internet usage in hopes of personal gain (re: VeriSign), and to establish an authority because of a misguided belief that there need be one.

The internet's basic strength is due to it's lack of dependance on centralized authorities in order to work. Any proposals that change that basic assumption are either poorly thought out or suspect.

I'm torn between the cushy redundancy offered by decentralization, and the cushy security of having most of the servers in a stable, well-protected country.

Fuirst of all, Germany is what most knowlegable people would call a "stable, well protected country".

Second, that in and of itself does not affect the security or reliability of DNS as it is designed very much, and has even less signifigance now that anycast is proven to be a reliable technique for increasing redundancy.

D. J. Bernstein has provided some good introductory about the workings of DNS, including security.

There's a chapter on DNS security from "DNS and BIND" available at the O'reilly website as well.

The biggest dispute about DNS security (and internet security in general) is between those who prefer centralized, single point solutions, and those who prefer distributed, autonomous security measures. IMHO, centralized security creates weakness in most (all?) cases by creating a single point of failure, and is an approach that is most often motivated by the desire to exert control over internet usage in hopes of personal gain (re: VeriSign), and to establish an authority because of a misguided belief that there need be one.

The internet's basic strength is due to it's lack of dependance on centralized authorities in order to work. Any proposals that change that basic assumption are either poorly thought out or suspect.

I'm torn between the cushy redundancy offered by decentralization, and the cushy security of having most of the servers in a stable, well-protected country.

Fuirst of all, Germany is what most knowlegable people would call a "stable, well protected country".

Second, that in and of itself does not affect the security or reliability of DNS as it is designed very much, and has even less signifigance now that anycast is proven to be a reliable technique for increasing redundancy.

D. J. Bernstein has provided some good introductory about the workings of DNS, including security.

There's a chapter on DNS security from "DNS and BIND" available at the O'reilly website as well.

The biggest dispute about DNS security (and internet security in general) is between those who prefer centralized, single point solutions, and those who prefer distributed, autonomous security measures. IMHO, centralized security creates weakness in most (all?) cases by creating a single point of failure, and is an approach that is most often motivated by the desire to exert control over internet usage in hopes of personal gain (re: VeriSign), and to establish an authority because of a misguided belief that there need be one.

The internet's basic strength is due to it's lack of dependance on centralized authorities in order to work. Any proposals that change that basic assumption are either poorly thought out or suspect.

what they are talking about for a change.

The recent flurry of articles giving the impression that VeriSign is somehow "in charge" of DNS has been rather irritating, when in fact, it is not difficult to configure your DNS server to ignore VeriSign operated root servers. (If you're using bind, dont include thier roots in your roots.cache zone file. I'm sure there's an equivalent trick for djbdns.)

I wish all of those who are about to continue the current flood of "what difference does it make?" and "VeriSign controls DNS anyway." posts would kindly read this article and this one as well for a breif tutorial on DNS from that programmer who writes good shit but everyone says they hate him anyway, D. J. Bernstein.

If you like the subject, maybe you should go out and buy a copy of DNS and BIND so you'll have something interesting to talk about at the coffee house this weekend.

The truth is that DNS is a distributed system that is rather well designed to be redundant. The anycast implementation mentioned in the article is a good and needed way (it's the right way[tm]) to increase the redundancy that is already inherent in the system, making DNS much more secure and resistant to DDOS attacks and other attempts to disrupt DNS service. VeriSign showing off thier "secure" sites, and blowing thier own horn about how "important" they in particular are to the internet is a load of sh*t that should not be given a second thought unless you are in the habit of educating our lawmakers about related issues. Not an especially good habit, it will make you enemies (but only if you're right).

what they are talking about for a change.

The recent flurry of articles giving the impression that VeriSign is somehow "in charge" of DNS has been rather irritating, when in fact, it is not difficult to configure your DNS server to ignore VeriSign operated root servers. (If you're using bind, dont include thier roots in your roots.cache zone file. I'm sure there's an equivalent trick for djbdns.)

I wish all of those who are about to continue the current flood of "what difference does it make?" and "VeriSign controls DNS anyway." posts would kindly read this article and this one as well for a breif tutorial on DNS from that programmer who writes good shit but everyone says they hate him anyway, D. J. Bernstein.

If you like the subject, maybe you should go out and buy a copy of DNS and BIND so you'll have something interesting to talk about at the coffee house this weekend.

The truth is that DNS is a distributed system that is rather well designed to be redundant. The anycast implementation mentioned in the article is a good and needed way (it's the right way[tm]) to increase the redundancy that is already inherent in the system, making DNS much more secure and resistant to DDOS attacks and other attempts to disrupt DNS service. VeriSign showing off thier "secure" sites, and blowing thier own horn about how "important" they in particular are to the internet is a load of sh*t that should not be given a second thought unless you are in the habit of educating our lawmakers about related issues. Not an especially good habit, it will make you enemies (but only if you're right).

what they are talking about for a change.

The recent flurry of articles giving the impression that VeriSign is somehow "in charge" of DNS has been rather irritating, when in fact, it is not difficult to configure your DNS server to ignore VeriSign operated root servers. (If you're using bind, dont include thier roots in your roots.cache zone file. I'm sure there's an equivalent trick for djbdns.)

I wish all of those who are about to continue the current flood of "what difference does it make?" and "VeriSign controls DNS anyway." posts would kindly read this article and this one as well for a breif tutorial on DNS from that programmer who writes good shit but everyone says they hate him anyway, D. J. Bernstein.

If you like the subject, maybe you should go out and buy a copy of DNS and BIND so you'll have something interesting to talk about at the coffee house this weekend.

The truth is that DNS is a distributed system that is rather well designed to be redundant. The anycast implementation mentioned in the article is a good and needed way (it's the right way[tm]) to increase the redundancy that is already inherent in the system, making DNS much more secure and resistant to DDOS attacks and other attempts to disrupt DNS service. VeriSign showing off thier "secure" sites, and blowing thier own horn about how "important" they in particular are to the internet is a load of sh*t that should not be given a second thought unless you are in the habit of educating our lawmakers about related issues. Not an especially good habit, it will make you enemies (but only if you're right).

In the bad old days you and you alone were in control of name resolution. For those of you without receding and/or grey hairlines who may not know or remember this, you had a file called hosts.txt that contained all the mappings of names to IPs. That, obviously, didn't scale and DNS was developed and was widely deployed by about 86 or so.

The one big gotcha with DNS is it takes control out of your hands. That is, you may have your own DNS server locally, but you traditionally refer to other servers that serve up the root zone that tells your DNS server where all the TLD servers are. Somewhere along the line the decision was made to use other machines, not your own, for this.

This is wrong for many reasons:

1. It's slower than if you have your own local copy of the root zone
   
2. it's a point of failure you can live without - a DDOS on the legacy roots shouldn't take you down
3. it provides a political point of capture - he who controls the root controls all the DNS namespace, and it's currently under the aegis of the trademark lobby under the guise of an incompetant and gutless wonder we jokingly refer to as "ICANN".

But there are ways around this. The easiest if is you static route the 13 root server IPs to your own nameserver. Then you can run an unmodified copt of the legacy root zone on your own nameserver and the US government root servers can be backhoed or DDOS'd and you wouldn't even notice. ISP's are starting to figure this out, especiallly ones with expensive longhaul connections.

Or, you can modify your nameserver to declare youtself primary for the root zone (which you've dutifully downloaded) and edit out the declarations for "." in the legacy root zone.

Or you can use the ORSC root zone. If it's good enough for two ICANN board members, it's good enough for you.

Whatever you do, for God's sake dump bind and use DJBDNS. It really is so much better it's just not funny.

>I still fail to see a huge problem here

Okay. Let me detail it then:

Sending email from your ISPs account: Free, and an internet standard.

Sending email from another ISPs account: Not Free. Internet standard, but becoming a difficulty with ISPs blocking ports.

Catch the drift?

>If you don't want to pay, use an account on your ISP's servers.

Why should one when standards dictate that's not necessary? That sucks. Anything that cripples internet functions just to get rid of spammers smacks of zealotry. It's killing the patient to cure the disease.

>Either SMTP will change or it will get replaced by a protocol that works better, and if you think this minor change is bad I can guarantee you won't like SMTP's replacement.

You mean DJBs idea? Nahhh, that'd be cool with me. I already run qmail, it'd be a smooth upgrade. As long as people don't castrate standards through their own petty bickering over the "right" implementation.

The idea behind Internet Mail 2000 is obviously correct. Why waste time on DNS-based approaches when we COULD be developing the Solution?

I've been using daemontools for years to start up all my system processes in parallel. My start-up times are great (plus, I don't have to wait for timeouts on failed drivers before I get a login).

Back in the good old days when her serene highness the Dalai Lauren worked there and Dave Holtzman was still VP I took the e-ticket tour. The facility is in a nondescript industrial mall a few miles from the NSI mothership.

"oh, you'll want to see this"

"what is it"

"A-ROOT"

"THAT tiny little thing?"

"Yup. Go ahead and touch it, everybody that comes here wants to do that. See where the paint has worn off the case?".

"Uh, ok"

"You use this thing Dave"

"Nah, I download the root zone from you".

"Cool, for that you can buy me lunch".

"Good idea. Thai okay?"

NSI was fun once and there's lots of good stories. When the FNCAC made the NSF tell NSI to start charging for domain names none of the freaks working at NSI could believe you could charge for this and lots of checks were just pinned up to a bulletin board in a "wait and see" holding pattern for a few months. There weren't so many domains back then.

Karl Aurbach also downloads the root zone from me and you should too. Or use OpenNIC's root or even *cough*ICANNs*cough* (ftp://internic.net/domain/root.zone.gz, or any root.zone you want but if you know what's good for you you won't rely any anybody but yourself to serve up the root zone so your computer can find pointers to the various TLD servers: primary the root for yourself and don't worry about DOS attacks on other peoples computers taking your machine off the air.

That really was the dumbest part of the change from hosts.txt to the DNS - it changed the paradigm from your computer knowing where everything was to making your computer rely on the "." zone to be able to find the computers that know where all names can be found and there's really no reason for it.

Certainly it does not scale for everybody to grab a copy of the root from one place, and Dan Bernstein has suggested a cryptographically signed root be distributed via usenet. To this end I've created news:alt.root.orsc and will begin doing just that this quarter.