Try Googling for "Scalable E-mail Systems" and "Scalable IMAP services". Of course, I'm biased since most of the top hits are from the slides from the presentations that I've done at LISA 2000, LISA 2002, etc....
Whereas I post with my own slashdot account, and don't try to hide behind an AC.
I have said that I would remove all comments in my blog which are posted with bogus e-mail addresses, and I have done that. What you haven't seen is the comments in my blog which were favourable to my view, but which were also posted with bogus e-mail addresses, and which were also deleted. I will continue my policy regarding the deletion of comments posted to my blog which have bogus e-mail addresses, and if someone wants to post a rebuttal comment with a valid e-mail address, then I will leave it.
I have no problem with the creation of a "lightweight" time server, but the problem is that the NTPv3 and NTPv4 protocols are, by their very nature, quite heavy -- you simply cannot escape that fact. If you want something "lightweight", then you have to give up NTPv3 and/or NTPv4, and instead go with SNTP.
Please note that there is a "lightweight" SNTP server included in the "Reference Implementation" tarball, known as "msntp". This is the same SNTP server as used on m0n0wall. If you want a lightweight SNTP server implementation, you should check it out.
The real problem is that the PR/marketing campaign by Theo and Henning has been that OpenNTPd is a complete fully functional replacement for the Reference Implementation, which even casual inspection shows to be patently false. Now, if they wanted to change the name of the project to OpenSNTPd and change the PR/marketing to match, I wouldn't have a leg to stand on. I challenge Theo or Henning to do this. At least, they'd be able to make me shut up.
With regards to my blog on OpenNTPd, I contacted Henning, and had several conversations with him regarding the project and where he saw things going. I tried very, very hard to give them every possible benefit of the doubt. When it became clear that he and Theo considered the project to be essentially finished (at what I would consider the 0.0.1 stage), and they were already looking for other things to work on, that's when I took the material I had been working on for a long time, and did a final "publication" of it.
I tried very, very hard to be as objective as possible, and to do everything I could to avoid flame wars, while still keeping what I considered to be constructive criticism. Needless to say, I've been underwhelmed by some of the responses, especially from some of the slashdot crowd.
Meanwhile, if people want to check out "slander" or "libel", try asking yourself why something qualifies under these terms when I say it, but qualifies as "fact" when Dan says the exact same thing. There's someone using a double-standard here, but it's not me.
SJG is a bad example here. I have personal, first-hand knowledge that they divulged classified information in one of their gaming supplements. I know, because I reported the incident to the security office of the agency I was working for at the time (this was a little while after Operation Sun Devil).
This information was not just classified, but used in the precisely correct manner for the material in question, and by an author who used to have clearance and who damn well should have known better.
It is entirely possible that they found out a few months before I did, and created Operation Sun Devil to go find out just exactly who did what when, and if there was any other classified information they had on hand that they might be about to release in other forms.
What do you think Sun's involvement is in this survey? Are you confusing "Sun" with "SANS"?
In the field of system administration, there are no more professional organizations than SANS and SAGE. SAGE is actively working to make itself more relevant to system administrators, and serve their needs and desires even better.
You can either believe me, or go to the SAGE web page at www.sage.org and see for yourself. If you think they're not doing something right, I encourage you to volunteer to help fix whatever you think is wrong.
Disclaimer: I am a member of SAGE and trying to do what I can to help make it a better organization.
...Try shorting their stock. It's currently around $9.75. If you short ten shares to $0.01, that won't even cost you $100 (the stock is unlikely to ever go back above $10, certainly not within your short window).
One person doing this isn't really going to hurt them. Millions of Linux users around the world doing this would bury the company.
Of course, one person in a different thread said that they worked at a brokerage and SCO was one of the companies they weren't allowed to short, due to lack of liquidity of the shares. So, you might have to go looking for a place that would let you place a short, but you should still be able to do it.
I am an American citizen, living in Belgium. I brought over with me the Pioneer DVD/LD player I had bought a long time ago, and I can continue to play DVDs that are bought for my by friends & family living in the US.
However, I also recently bought a local DVD player because of all the local DVDs I've wanted to buy or rent, but couldn't see because they were not only region-2 encoded, but because they are in PAL format and my DVD/LP player is NTSC-only.
My advice would be to do the same in reverse for your situation -- buy a DVD player in the Netherlands or the UK that can either accept a region mod or is already region switchable. Make sure that it can output both NTSC and PAL format, because TVs in the US are NTSC-only. If you can't get a European DVD player that can output both NTSC and PAL, then you'll need to get a European TV that can handle both NTSC and PAL input that you take with you (with any luck, your existing TV will be able to handle both NTSC and PAL input).
Just keep in mind that you'll probably need a 240VAC@50Hz/120VAC@60Hz voltage/frequency converter to handle any European video equipment that you bring over with you. Make sure you get a high-quality model, not one that does only the voltage side and skips the the frequency conversion part, because that will be likely to fry your sensitive eletronic equipment. I've found good ones over here in Belgium (they tend to work both ways), but they are hard to find and expensive.
If you're going to use simple front-end caches to back-end servers, then why not just pull the database directly to the front-end caches and eliminate the back-end servers?
The reality of it is that acting as a secondary/slave nameserver for the root zone (or any other zone) is a simple task, and can (and should) be done on such a stripped-down box. However, regardless of how you build that stripped-down box, there are still going to be security vulnerabilities in the OS of the machine.
Trading one set of security vulnerabilities for exactly the same set of security vulnerabilities on a different set of machines amounts to no benefit in my book.
Now, when you talk about using clustering solutions, you should first find out what is already being used on the root nameservers. Yes, there are thirteen IP addresses listed as root nameservers, but each of those installations is currently front-ended by a load-balancing device of some sort, with at least two machines behind it.
So, they're already doing clustering or standard high-availability solutions. Indeed, since they're using a variety of different methods at different sites, they have security-through-diversity at that level as well.
The root nameservers are not operated by Network Solutions. They are operated by a group of volunteers that some people loosely refer to as the Root Server Operators Group.
Network Solutions does operate the gTLD nameservers, which are responsible for.com,.net,.org, etc.... However, these machines also use a version of BIND (based on 8.1.2), to which NSI has applied some internal proprietary hacks.
Before making sweeping comments such as this, it would pay to do some research on what OSes are currently in use by the various root nameservers.
The reality of it is that the thing that helps us most is diversity. This is why some of the machines are running AIX, some are running FreeBSD, some are running SunOS, some are running Solaris, some are running HP-UX, some are running other OSes, and in and amongst that mix are some machines running Linux.
However, by having the most diverse mix possible of different OSes, if there is a bug found in any one of them, the result is that the fewest possible number of root servers may be potentially compromised.
Linux is not a panacea. Linux will not solve all your problems. Linux will not walk your dog, empty the cat litter box, clean the toilet, or any of a bazillion other things in this world.
Do not attempt to apply *ANY* solution without at least making some minimal attempt to first understand the problem.
Uh, yeah. Right. The first of what I'm sure will be many people to recommend djbdns. I've got a long list of reasons why djbdns is inherently bad, and I'll share some of them with you:
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.
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.
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.
Without a patch from a third party, tinydns does not listen to more than one IP address. If you have a multi-homed server, you have to apply a patch from someone other than they author, before you can get it to listen on more than one address/interface.
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).
Without a third party patch, tinydns does not support standard SRV records (which are intended to ultimately replace MX records, as well as perform similar functions for services other than mail).
Like tinydns, dnscache will not bind to more than one IP address without a third party patch.
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.
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.
There are a number of things that djbdns does which I believe to be outright bugs. However, the author of this package simply refuses to accept that his code could be anything less than 100% perfect, and while he claims to have a "bounty" that he will pay for any bug that is found, in reality he is the one that gets to define what he accepts as a "bug", and has repeatedly demonstrated a tendancy to openly refuse to accept some purported bug, but then to quietly fix the code with future releases.
So, let's look at some of these bugs:
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).
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).
One argument frequently used to support the use of djbdns over BIND is performance. Upon further investigation, this claim simply does not hold water.
Benchmarks published by Rick Jones have clearly shown that BIND can scale up to at least 12,000 DNS queries per second, and there is every indication that BIND 9.2 will be able to go considerably higher. The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second, but that is the highest number reported. Other people on the bind-users mailing list have indicated that they have performed their own (as yet unpublished) benchmarks of tinydns, and that it had notable performance problems that BIND did not suffer.
The best published benchmarks from the author for dnscache report a query handling rate of less than one million records over a 4.5 hour period of time, which works out to an average of less than sixty-two queries per second. Even if you look at numbers of queries per CPU second, the best numbers they can provide are 13.7 million queries over a four week period of time with 128 minutes of CPU time used (an average of slightly less than 1784 queries per CPU second).
Compare this with the requirement from RFC 2010 "Operational Criteriafor Root Name Servers" (since obsoleted by RFC 2870 "Root Name Server Operational Requirements") is that the machine and software in question be able to handle at least 2000 queries per second, and be scalable to levels higher than that. Indeed, recent reports have indicated that a.root-servers.net (considered by many to be the "primary" root nameserver) is currently handling around 12,000 DNS queries per second at peak.
Preliminary benchmarks published on the bind-users mailing list have indicated that, on the same hardware, there is little or no performance benefit to using dnscache as opposed to BIND 9.1.2, and when these tests are re-run with BIND 9.2, I'm sure that it will come out even faster.
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.
For example, he makes a big point of tinydns being better than BIND, because while the process is starting up, it still answers queries. While previous versions of BIND would not answer queries during startup, this is no longer a problem with BIND 9.
Dan also makes a great deal of the fact that the djbdns tools run as a user other than root, and in chroot() environments. While the "monolithic setuid root" situation was an issue with older versions of BIND, even more recent releases of BIND 8 could be easily run as a non-priviledged user in a chroot() environment, and this is the preferred method of running BIND 9.
Contrariwise, one of the legitimate big complaints about older versions of BIND is that they implemented zone transfers in a separate program. If the database was large, then the fork()/exec() overhead was large, and the system could seriously thrash itself to death as it copied all those pages (for systems without copy-on-write), only to immediately throw them away again when it fired up the named-xfer program. With BIND 9, this problem is solved by having a separate thread inside the server handling zone transfers, and no fork()/exec() is done. However, tinydns/axfrdns goes back to the fork()/exec() model that was so greatly despised.
And this doesn't even begin to get to the more core philosophical issues that Dan gives for running djbdns instead of BIND. I can easily rip him apart in these areas as well, but this takes more space than I think that I should devote here.
Suffice it to say that there is absolutely nothing that djbdns does that I believe can't be done at least as well (or considerably better) with BIND, and there are no security benefits it provides that cannot be provided at least as well (or much better) by a proper installation of a modern version of BIND.
I believe in the "security through diversity" scheme as much as anyone, but I'd take root nameservers running a program written in Bourne shell over djbdns. Hell, I'd rather fall back to using HOSTS.TXT than use djbdns.
Unfortunately, the other alternative of DENTS is also unsuitable for use as a production nameserver.
Show me something that is sufficiently better than BIND (and open source), and I'm sure that everyone will quickly gravitate towards it. Until then, BIND is the best we've got.
Post your code. Let people rip it apart. BIND has gotten where it is today because it is still the best open-source solution for the job.
Yes, there are independantly coded closed-source solutions which perform better and presumably are better all around (Nominum has written a program that they use as the basis for their Global Name Service, which does not contain any code from BIND).
However, these are closed-source implementations, and the folks who operate the various root servers are doing so on a volunteer basis, and are not interested in just handing everything over to some company who operates a "black box" -- regardless of who that company is.
Indeed, it's the root server operators that have really spared us from the worst of the damage that ICANN has tried to inflict upon us. For the stupidest things, the root server operators simply said "Not only NO, but HELL NO!", and ICANN was forced to back down.
Really, it now has full Linux compatibity (so anything compiled for Linux/SPARC should just run without complaint), plus it has full support from the NetBSD project (which has been ported to more different platforms than any other OS on the planet), and all the other nice features of modern BSD.
Sorry, I used to work at AOL. You obviously have no earthly clue what actually goes on there behind the scenes.
They get away with 99.9999999% of whatever crap they want, and could get away with more if they didn't flub the implementation so often (can you say "Black Tuesday"? I knew you could).
No, the AOL/Time-Warner merger *IS* something to be worried about, right along with them swallowing Netscape and dozens of other companies you've never even heard about. Sadly, many of these companies effectively get killed and those products never see the light of day ever again -- anybody recall WAIS? --
Brad Knowles
HP Jornada 680/690 only...
on
Palmtop NetBSD
·
· Score: 1
The 720 & 820 models use StrongArm processors, not SH3.
Please mention this sort of thing in future articles -- we wouldn't want people to get confused and rush out and buy the wrong device, right? --
Brad Knowles
At this point, I wouldn't consider doing anything without checking with Nominum (the company responsible for writing and maintaining BIND version 9).
These guys offer a service whereby they provide either primary or secondary nameservice for your domain, across their distributed cluster of redundant, fault-tolerant servers. Heck, the secondary service is even free (in all the various senses of the word).
I just wish they had a Dynamic DNS service, so that we could all kiss DynDNS.org and GraniteCanyon.com farewell for their incredibly crappy service. --
Brad Knowles
But will NetBSD install on an older PCI PowerMacintosh, such as the 7200/90?
I've got an old machine laying around pretty much unused (but stuffed with RAM), and I'd like to be able to use it for some good purpose. I haven't done anything with it up until now, because I was under the impression that NetBSD wouldn't install on it, and none of the various Linux distributions really interested me (although LinuxPPC came closest). --
Brad Knowles
Consider that USENET has been around something like twenty years. Currently, a full non-binary feed is running something around 2GB/day.
If you take an extremely conservative straight-line growth approximation, then this would be something like 7.3TB of disk storage over that period of time, or more than 23 of these devices.
However, a full binary feed today is running something like 130GB/day. A straight line growth approximation for that would be about 465TB, or about 1500 of these devices.
Of course, the real growth is exponential and not straight-line, so while the disk space required to store all the historical articles would be much smaller, the space required to be able to store another X years worth of articles would be far, far larger, and I'm sure would more than compensate for the difference. --
Brad Knowles
I worked on classified government projects. There used to be an ancient 1950s/1960s style mainframe system for doing most classified military command & control systems called WWMCCS -- World Wide Military Command and Control System.
Basically, all the real security in this system was controlling physical access to the terminals (the terminal room was guarded by a door with an electronic or mechanical push button lock and you had to know the access code to get in), and controlling access to the removable media (it had to be locked in a safe when not being used).
.
Anybody who wanted to could pack up as much classified information as they wanted into their briefcase, and walk out the front door with it. The security guards were there to prevent people without badges from getting in without being on the regular hourly tour, and without having their bags (purses, backpacks, etc...) pass through the scanner. There wasn't anybody there to help ensure that you didn't take classified stuff out of the building -- you were on the honor system.
In addition, if you had a badge, you just sailed right through the security checkpoints, without ever passing through the scanner or having your bags scanned. You could be bringing in C4 plastique by the briefcase full, and they'd never know -- Well, at least not until a quarter of the building was blown up.;-)
.
When I left, the only reason that my badges got turned back in was because I didn't want the damn things, and I hand-carried them and all the paperwork around to make sure that I got rid of anything that could potentially allow me to get back into the building as if I were an employee.
Speaking of which, the badges were a joke. I could have printed up better-looking ones off my ink-jet printer and laminated them myself. It sure would have been trivially easy to make some fake ones this way. Jeez, Louise....
.
Later, when they started work on replacing the WWMCCS systems, they named the new project GCCS -- Global Command and Control System, and called it "geeks". Originally, they were going to use/etc/hosts files to control name to IP address translation, but as the Domain Technical Point of Contact for DISA.MIL, I managed to convince them that they should use the DNS instead. Sigh...
Oh, and it was all built on top of Solaris 2.2 (wanna make me puke?) running on original Sun SPARC 10 and SPARC 20 computers.
.
Granted, with WWMCCS, these guys had what amounted to newsgroups and mailing lists years and decades before anyone else, and with the new GCCS systems each desktop machine was far more powerful than the old Honeywell mainframes they were replacing, but their mindsets never changed -- all real security comes from controlling physical access to the machines and the computers that can access them.
.
Wanna hear something funny? When I went to Assistant Security Monitor training, they told me that Top Secret stuff had to be assumed to be in the hands of the enemy within six months of it being generated. Stuff classified Secret took only one to two months, and stuff classified Confidential had to be assumed to be in their hands as soon as it was produced. --
Brad Knowles
I have two words for you -- Script Kiddies. The people writing rootkits and script-kiddie toolkits will surely migrate to writing full-blown viruses, and even virus toolkits (so that the script kiddies can "write" their own viruses).
It's just a matter of time. Meanwhile, you damn well better hope that your OS is secure.
If you're using Linux, you should check out Bastille Linux. If you're a BSD fan, I recommend you look at OpenBSD, although hopefully FreeBSD will catch up soon thanks to the FreeBSD Audit Project. -- Brad Knowles
Unfortunately there are some age-old personality clashes that have left very deep wounds (like serious threats of physical bodily harm), and the problems underlying are not likely to go away any time soon.
I anticipate that there will be increased overlap between FreeBSD and the other members of the BSD family, as the folks at BSD, Inc. go out of their way to work closely with developers in each of the other camps -- to the benefit of everyone involved.
Whether Theo will ever come in out of the cold is another question entirely, however. -- Brad Knowles
Slashdot Mirror
My slides relevant to this discussion can be found at http://www.shub-internet.org/brad/papers/dihses/ and http://www.shub-internet.org/brad/papers/sistpni/.
And yes, Nick Christenson has been a long-time friend and co-author of mine.
Feel free to contact me directly if you want some referrals.
I have said that I would remove all comments in my blog which are posted with bogus e-mail addresses, and I have done that. What you haven't seen is the comments in my blog which were favourable to my view, but which were also posted with bogus e-mail addresses, and which were also deleted. I will continue my policy regarding the deletion of comments posted to my blog which have bogus e-mail addresses, and if someone wants to post a rebuttal comment with a valid e-mail address, then I will leave it.
I have no problem with the creation of a "lightweight" time server, but the problem is that the NTPv3 and NTPv4 protocols are, by their very nature, quite heavy -- you simply cannot escape that fact. If you want something "lightweight", then you have to give up NTPv3 and/or NTPv4, and instead go with SNTP.
Please note that there is a "lightweight" SNTP server included in the "Reference Implementation" tarball, known as "msntp". This is the same SNTP server as used on m0n0wall. If you want a lightweight SNTP server implementation, you should check it out.
The real problem is that the PR/marketing campaign by Theo and Henning has been that OpenNTPd is a complete fully functional replacement for the Reference Implementation, which even casual inspection shows to be patently false. Now, if they wanted to change the name of the project to OpenSNTPd and change the PR/marketing to match, I wouldn't have a leg to stand on. I challenge Theo or Henning to do this. At least, they'd be able to make me shut up.
With regards to my blog on OpenNTPd, I contacted Henning, and had several conversations with him regarding the project and where he saw things going. I tried very, very hard to give them every possible benefit of the doubt. When it became clear that he and Theo considered the project to be essentially finished (at what I would consider the 0.0.1 stage), and they were already looking for other things to work on, that's when I took the material I had been working on for a long time, and did a final "publication" of it.
I tried very, very hard to be as objective as possible, and to do everything I could to avoid flame wars, while still keeping what I considered to be constructive criticism. Needless to say, I've been underwhelmed by some of the responses, especially from some of the slashdot crowd.
Meanwhile, if people want to check out "slander" or "libel", try asking yourself why something qualifies under these terms when I say it, but qualifies as "fact" when Dan says the exact same thing. There's someone using a double-standard here, but it's not me.
SJG is a bad example here. I have personal, first-hand knowledge that they divulged classified information in one of their gaming supplements. I know, because I reported the incident to the security office of the agency I was working for at the time (this was a little while after Operation Sun Devil).
This information was not just classified, but used in the precisely correct manner for the material in question, and by an author who used to have clearance and who damn well should have known better.
It is entirely possible that they found out a few months before I did, and created Operation Sun Devil to go find out just exactly who did what when, and if there was any other classified information they had on hand that they might be about to release in other forms.
So, SJG is a bad example to compare with.
In the field of system administration, there are no more professional organizations than SANS and SAGE. SAGE is actively working to make itself more relevant to system administrators, and serve their needs and desires even better.
You can either believe me, or go to the SAGE web page at www.sage.org and see for yourself. If you think they're not doing something right, I encourage you to volunteer to help fix whatever you think is wrong.
Disclaimer: I am a member of SAGE and trying to do what I can to help make it a better organization.
...Try shorting their stock. It's currently around $9.75. If you short ten shares to $0.01, that won't even cost you $100 (the stock is unlikely to ever go back above $10, certainly not within your short window).
One person doing this isn't really going to hurt them. Millions of Linux users around the world doing this would bury the company.
Of course, one person in a different thread said that they worked at a brokerage and SCO was one of the companies they weren't allowed to short, due to lack of liquidity of the shares. So, you might have to go looking for a place that would let you place a short, but you should still be able to do it.
However, I also recently bought a local DVD player because of all the local DVDs I've wanted to buy or rent, but couldn't see because they were not only region-2 encoded, but because they are in PAL format and my DVD/LP player is NTSC-only.
My advice would be to do the same in reverse for your situation -- buy a DVD player in the Netherlands or the UK that can either accept a region mod or is already region switchable. Make sure that it can output both NTSC and PAL format, because TVs in the US are NTSC-only. If you can't get a European DVD player that can output both NTSC and PAL, then you'll need to get a European TV that can handle both NTSC and PAL input that you take with you (with any luck, your existing TV will be able to handle both NTSC and PAL input).
Just keep in mind that you'll probably need a 240VAC@50Hz/120VAC@60Hz voltage/frequency converter to handle any European video equipment that you bring over with you. Make sure you get a high-quality model, not one that does only the voltage side and skips the the frequency conversion part, because that will be likely to fry your sensitive eletronic equipment. I've found good ones over here in Belgium (they tend to work both ways), but they are hard to find and expensive.
The Yahoo page requires cookies and other junk in order to be able to be displayed, while Randall's own archive does not.
The reality of it is that acting as a secondary/slave nameserver for the root zone (or any other zone) is a simple task, and can (and should) be done on such a stripped-down box. However, regardless of how you build that stripped-down box, there are still going to be security vulnerabilities in the OS of the machine.
Trading one set of security vulnerabilities for exactly the same set of security vulnerabilities on a different set of machines amounts to no benefit in my book.
Now, when you talk about using clustering solutions, you should first find out what is already being used on the root nameservers. Yes, there are thirteen IP addresses listed as root nameservers, but each of those installations is currently front-ended by a load-balancing device of some sort, with at least two machines behind it.
So, they're already doing clustering or standard high-availability solutions. Indeed, since they're using a variety of different methods at different sites, they have security-through-diversity at that level as well.
Network Solutions does operate the gTLD nameservers, which are responsible for .com, .net, .org, etc.... However, these machines also use a version of BIND (based on 8.1.2), to which NSI has applied some internal proprietary hacks.
The reality of it is that the thing that helps us most is diversity. This is why some of the machines are running AIX, some are running FreeBSD, some are running SunOS, some are running Solaris, some are running HP-UX, some are running other OSes, and in and amongst that mix are some machines running Linux.
However, by having the most diverse mix possible of different OSes, if there is a bug found in any one of them, the result is that the fewest possible number of root servers may be potentially compromised.
Linux is not a panacea. Linux will not solve all your problems. Linux will not walk your dog, empty the cat litter box, clean the toilet, or any of a bazillion other things in this world.
Do not attempt to apply *ANY* solution without at least making some minimal attempt to first understand the problem.
-
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.
-
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).
-
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.
-
Without a patch from a third party, tinydns does not listen to more than one IP address. If you have a multi-homed server, you have to apply a patch from someone other than they author, before you can get it to listen on more than one address/interface.
-
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).
-
Without a third party patch, tinydns does not support standard SRV records (which are intended to ultimately replace MX records, as well as perform similar functions for services other than mail).
-
Like tinydns, dnscache will not bind to more than one IP address without a third party patch.
-
Because they are separate programs, you can't have both tinydns and dnscache listening to the same IP address(es) on the same server.
-
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).
-
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.
-
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).
-
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).
-
One argument frequently used to support the use of djbdns over BIND is performance. Upon further investigation, this claim simply does not hold water.
-
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.
And this doesn't even begin to get to the more core philosophical issues that Dan gives for running djbdns instead of BIND. I can easily rip him apart in these areas as well, but this takes more space than I think that I should devote here.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.
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.
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.
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.
So, let's look at some of these bugs:
Benchmarks published by Rick Jones have clearly shown that BIND can scale up to at least 12,000 DNS queries per second, and there is every indication that BIND 9.2 will be able to go considerably higher. The best benchmarks available for tinydns indicate that it can handle at least 500 queries per second, but that is the highest number reported. Other people on the bind-users mailing list have indicated that they have performed their own (as yet unpublished) benchmarks of tinydns, and that it had notable performance problems that BIND did not suffer.
The best published benchmarks from the author for dnscache report a query handling rate of less than one million records over a 4.5 hour period of time, which works out to an average of less than sixty-two queries per second. Even if you look at numbers of queries per CPU second, the best numbers they can provide are 13.7 million queries over a four week period of time with 128 minutes of CPU time used (an average of slightly less than 1784 queries per CPU second).
Compare this with the requirement from RFC 2010 "Operational Criteriafor Root Name Servers" (since obsoleted by RFC 2870 "Root Name Server Operational Requirements") is that the machine and software in question be able to handle at least 2000 queries per second, and be scalable to levels higher than that. Indeed, recent reports have indicated that a.root-servers.net (considered by many to be the "primary" root nameserver) is currently handling around 12,000 DNS queries per second at peak.
Preliminary benchmarks published on the bind-users mailing list have indicated that, on the same hardware, there is little or no performance benefit to using dnscache as opposed to BIND 9.1.2, and when these tests are re-run with BIND 9.2, I'm sure that it will come out even faster.
For example, he makes a big point of tinydns being better than BIND, because while the process is starting up, it still answers queries. While previous versions of BIND would not answer queries during startup, this is no longer a problem with BIND 9.
Dan also makes a great deal of the fact that the djbdns tools run as a user other than root, and in chroot() environments. While the "monolithic setuid root" situation was an issue with older versions of BIND, even more recent releases of BIND 8 could be easily run as a non-priviledged user in a chroot() environment, and this is the preferred method of running BIND 9.
Contrariwise, one of the legitimate big complaints about older versions of BIND is that they implemented zone transfers in a separate program. If the database was large, then the fork()/exec() overhead was large, and the system could seriously thrash itself to death as it copied all those pages (for systems without copy-on-write), only to immediately throw them away again when it fired up the named-xfer program. With BIND 9, this problem is solved by having a separate thread inside the server handling zone transfers, and no fork()/exec() is done. However, tinydns/axfrdns goes back to the fork()/exec() model that was so greatly despised.
Suffice it to say that there is absolutely nothing that djbdns does that I believe can't be done at least as well (or considerably better) with BIND, and there are no security benefits it provides that cannot be provided at least as well (or much better) by a proper installation of a modern version of BIND.
I believe in the "security through diversity" scheme as much as anyone, but I'd take root nameservers running a program written in Bourne shell over djbdns. Hell, I'd rather fall back to using HOSTS.TXT than use djbdns.
Unfortunately, the other alternative of DENTS is also unsuitable for use as a production nameserver.
Show me something that is sufficiently better than BIND (and open source), and I'm sure that everyone will quickly gravitate towards it. Until then, BIND is the best we've got.
Yes, there are independantly coded closed-source solutions which perform better and presumably are better all around (Nominum has written a program that they use as the basis for their Global Name Service, which does not contain any code from BIND).
However, these are closed-source implementations, and the folks who operate the various root servers are doing so on a volunteer basis, and are not interested in just handing everything over to some company who operates a "black box" -- regardless of who that company is.
Indeed, it's the root server operators that have really spared us from the worst of the damage that ICANN has tried to inflict upon us. For the stupidest things, the root server operators simply said "Not only NO, but HELL NO!", and ICANN was forced to back down.
NetBSD.
Really, it now has full Linux compatibity (so anything compiled for Linux/SPARC should just run without complaint), plus it has full support from the NetBSD project (which has been ported to more different platforms than any other OS on the planet), and all the other nice features of modern BSD.
Recommended.
--
Brad Knowles
They get away with 99.9999999% of whatever crap they want, and could get away with more if they didn't flub the implementation so often (can you say "Black Tuesday"? I knew you could).
No, the AOL/Time-Warner merger *IS* something to be worried about, right along with them swallowing Netscape and dozens of other companies you've never even heard about. Sadly, many of these companies effectively get killed and those products never see the light of day ever again -- anybody recall WAIS?
--
Brad Knowles
Please mention this sort of thing in future articles -- we wouldn't want people to get confused and rush out and buy the wrong device, right?
--
Brad Knowles
At this point, I wouldn't consider doing anything without checking with Nominum (the company responsible for writing and maintaining BIND version 9).
These guys offer a service whereby they provide either primary or secondary nameservice for your domain, across their distributed cluster of redundant, fault-tolerant servers. Heck, the secondary service is even free (in all the various senses of the word).
I just wish they had a Dynamic DNS service, so that we could all kiss DynDNS.org and GraniteCanyon.com farewell for their incredibly crappy service.
--
Brad Knowles
I've got an old machine laying around pretty much unused (but stuffed with RAM), and I'd like to be able to use it for some good purpose. I haven't done anything with it up until now, because I was under the impression that NetBSD wouldn't install on it, and none of the various Linux distributions really interested me (although LinuxPPC came closest).
--
Brad Knowles
If you take an extremely conservative straight-line growth approximation, then this would be something like 7.3TB of disk storage over that period of time, or more than 23 of these devices.
However, a full binary feed today is running something like 130GB/day. A straight line growth approximation for that would be about 465TB, or about 1500 of these devices.
Of course, the real growth is exponential and not straight-line, so while the disk space required to store all the historical articles would be much smaller, the space required to be able to store another X years worth of articles would be far, far larger, and I'm sure would more than compensate for the difference.
--
Brad Knowles
Basically, all the real security in this system was controlling physical access to the terminals (the terminal room was guarded by a door with an electronic or mechanical push button lock and you had to know the access code to get in), and controlling access to the removable media (it had to be locked in a safe when not being used).
.
Anybody who wanted to could pack up as much classified information as they wanted into their briefcase, and walk out the front door with it. The security guards were there to prevent people without badges from getting in without being on the regular hourly tour, and without having their bags (purses, backpacks, etc...) pass through the scanner. There wasn't anybody there to help ensure that you didn't take classified stuff out of the building -- you were on the honor system.
In addition, if you had a badge, you just sailed right through the security checkpoints, without ever passing through the scanner or having your bags scanned. You could be bringing in C4 plastique by the briefcase full, and they'd never know -- Well, at least not until a quarter of the building was blown up. ;-)
.
When I left, the only reason that my badges got turned back in was because I didn't want the damn things, and I hand-carried them and all the paperwork around to make sure that I got rid of anything that could potentially allow me to get back into the building as if I were an employee.
Speaking of which, the badges were a joke. I could have printed up better-looking ones off my ink-jet printer and laminated them myself. It sure would have been trivially easy to make some fake ones this way. Jeez, Louise....
.
Later, when they started work on replacing the WWMCCS systems, they named the new project GCCS -- Global Command and Control System, and called it "geeks". Originally, they were going to use /etc/hosts files to control name to IP address translation, but as the Domain Technical Point of Contact for DISA.MIL, I managed to convince them that they should use the DNS instead. Sigh...
Oh, and it was all built on top of Solaris 2.2 (wanna make me puke?) running on original Sun SPARC 10 and SPARC 20 computers.
.
Granted, with WWMCCS, these guys had what amounted to newsgroups and mailing lists years and decades before anyone else, and with the new GCCS systems each desktop machine was far more powerful than the old Honeywell mainframes they were replacing, but their mindsets never changed -- all real security comes from controlling physical access to the machines and the computers that can access them.
.
Wanna hear something funny? When I went to Assistant Security Monitor training, they told me that Top Secret stuff had to be assumed to be in the hands of the enemy within six months of it being generated. Stuff classified Secret took only one to two months, and stuff classified Confidential had to be assumed to be in their hands as soon as it was produced.
--
Brad Knowles
It's just a matter of time. Meanwhile, you damn well better hope that your OS is secure.
If you're using Linux, you should check out Bastille Linux. If you're a BSD fan, I recommend you look at OpenBSD, although hopefully FreeBSD will catch up soon thanks to the FreeBSD Audit Project.
--
Brad Knowles
And my mirror can be found at http://www.shub-internet.org/cp4/cp4 break.html.
--
Brad Knowles
I have put up a mirror at http://www.shub-internet.org/cp4/cp4 break.html.
--
Brad Knowles
My mirror is at http://www.shub-internet.org/cp4/cp4 break.html.
--
Brad Knowles
My mirror is available at http://www.shub-internet.org/cp4/cp4 break.html.
--
Brad Knowles
Unfortunately there are some age-old personality clashes that have left very deep wounds (like serious threats of physical bodily harm), and the problems underlying are not likely to go away any time soon.
I anticipate that there will be increased overlap between FreeBSD and the other members of the BSD family, as the folks at BSD, Inc. go out of their way to work closely with developers in each of the other camps -- to the benefit of everyone involved.
Whether Theo will ever come in out of the cold is another question entirely, however.
--
Brad Knowles