Slashback: Bindery, Locality, Gruviness

Much has happened in the world, some of it even worth reading about. For instance ... More on BIND and where it's headed regarding openness, licensing and other things; an update on Protozilla, and what is undoubtably not the final word on Linuxgruven, SAIR and company.

Why is there a lizard in my hard drive? chromatic writes: "The Protozilla team has responded to the earlier Slashdot article with answers to some common questions." This helps explain a lot of the questions raised in comments about why anyone would want or need to run CGI processes locally.Yet another win for documentation!

The ties that BIND make great cable-holders, too. fredpasteck writes: "LinuxSecurity.com has a FAQ from Paul Vixie that helps to explain some of the controversy and misunderstanding surrounding the ISCs creation of a 'members-only' mailing list. Perhaps the community was a bit quick in their assessment of what's going to happen?"

Do you feel reading Bugtrak makes it easier to talk to people? Speaking of BIND, to dispel any misconceptions which may have entered the minds of readers of this story (which cited the reaction of several Big Names to recent moves to restrict certain information about BIND), Kurt Seifried of Securityportal wrote to clarify:

I actually interviewed Vince/Theo/Dragos/Greg via phone/email seperately, they didn't post those things to Bugtraq. Although they are all Bugtraq users ... hehehehe. (that makes it sound like we're all shooting up heroin or something).

Let it not be said that Bugtraq is a controlled substance.

Stop kicking, stop kicking! A nameless shirker writes: "More 'clarifications' from Linuxgruven CEO Matthew Porter can be found during a recent discussion on the Kansas Linux and Unix Users Association(KULUA) mailing list. His answers were very evasive to what were considered very straightforward (if direct) questions. The beginning of his involvement in the discussion can be found here with follow-ups linked from that message. Other discussion on this topic before and after Porter's response can be found near near the bottom of the following archive thread page.

Just wanted to make sure everyone could see how "clear" Porter makes things in his "responses" to the questions he is asked."

Comments

LinuxGruven.

[smack_attack]

So, does this mean we are going to see some more posts by sequential user ids? It was really quite amusing to see them do damage control (which seemed to cause more problems)

Re:Secret Mailing lists are still evil.

[wfaulk]

Well, aren't the implicit rules for reporting security bugs to report it to the vendor and give them a while to fix it and then report it to the community? If so, this is the same thing. If it were just a mailing list totally internal to ISC, say, their developers list, no one would know, and nothing else would be different. I'm sure that if the guys internal to ISC find a big hole, the first thing they try to do is fix it, not let every script kiddie out there know. Now they're just letting some external developers know as well; plus you might be able to be privy, too.

As to the matter of money == evil, I'll not argue, regardless of my stance, but simply point out that the development of BIND9 has already been ``funded'' by a large group of corporations. I don't think that that funding goes simply for disks to write the source to.... ;)

Re:This secret mailing list is a good thing

[Anonymous Coward]

this is bullshit. so what youre suggesting is that the information be kept *secret* to a few vendors and their employees who have to pay for this info. what prevents any of them from leaking it in secret to their script kiddie friends and taking over the net ? i'd rather see free flow of information thats this critical than let some vendor r00t my system WITHOUT my knowledge.

Re:Secret Mailing lists are still evil.

[j-pimp]

Uh, some people auctually read diffs before running patch and eventually it would be figured out. Anyway, If they just wrote good code they wouldn't have to worry about their reputation. Granted bind, sendmail and the like were originally designed during less security conscience times and developers are stuck with the code base. Although I'll try and other implementation besides Microsofts NT implementation, unless of course I was forced to use NT, then I'd take MS DNS over bind any day.

Re:Secret Mailing lists are still evil.

[OmniFool]

Did you miss the point? The key "out" statement is that they'll notify Bugtrak and then their members only list - If bugtrak chooses to delay the announcement then that's bugtrak's issue - talk to them.

On a personal basis, I'm more than happy to get the root servers and TLD servers upgraded before an official security notice out - these things are critical to the operation of the whole internet - no root servers, no internet.

Re:Secret Mailing lists are still evil.

[lamontg]

1) you are a religious zealot

2) the world runs off of money. since nobody seems to be interested in doing the work for free, someone will have to be hired and paid to maintain this mailng list.

3) it is common practice to keep vulnerabilities "secret" for a time in order to give the vendor a headstart in fixing the problem (e.g. RFPolicy). this list facilitates that, and presumably will shorten the time between discovery of a security bug in bind and release to the public.

4) write your own OpenBind if you don't like ISC / Paul Vixie. quit yer bitchin.

Re:Secret Mailing lists are still evil.

[Bingo Foo]

They are supposed to develop Open Source software for the Interent. Money corrupts that.

What do you mean they are "supposed to?" Are they "supposed to" work for free? Who enforces the rule about what they are "supposed to" do?

KTB:Lover, Poet, Artiste, Aesthete, Programmer. There is no contradiction.

Uh.... Is it a contradiction that a self-described poet and programmer can't spell "internet?"

Bingo Foo

---

Re:This secret mailing list is a good thing

[The NT Christ]

Releasing the information about a BIND fault creates a race condition : the sysadmins try to apply the patch before the script kiddies try to gain access.

Now, the funny thing about this race condition, is that it happens regardless of when the information was privately discovered. It depends only on when the information is publically released. However, anyone who knows the knowledge before public release has an advantage - they can patch their systems and never worry about the race condition.

So keeping this information secret neither helps nor hinders the average sysadmin in his security task. The race condition always exists at the moment of public announcement, regardless.

However, buying this information early gives you a distinct advantage - you get a system which is less likely to be attacked.

So let's face facts: this is a ploy to raise capital, based on the unarguable market value of early information. It is not in the interests of the average sysadmin. It is in the interests of the seller and the buyer alone.

Re:Secret Mailing lists are still evil.

[j-pimp]

I believe I smell a reimplementation from scratch ala qmail.

Re:This secret mailing list is a good thing

[prizog]

Now, if a bug is found in BIND, do you really want every script kitty trying to make a name for himself to HACK ROOT on the ROOT NAMESERVERS for the ENTIRE INTERNET? Does this sound like a good plan to you? Wouldn't you rather, since the entire internet depends on them, that they get a chance to be patched up first?

Has it happened yet? No. So, what's wrong with the current model?

Re:This secret mailing list is a good thing

[Ben Hutchings]

This is in the interests of everyone who uses the root and top-level servers, i.e. virtually everyone using the Internet.

Calm down, dude.

[Lish]

1. I say, Dominant != Best. They are in fact saying, we think since we are dominant we must have the best product and don't need to learn from anyone else. Of course they should learn from any other product. Where did I say they shouldn't?

2. Yes, the bug notification through CERT will still happen. But not everyone who needs and deserves the information gets it at the same time. That's the whole point of having the "in-group". They've decided that some providers are more important than others, and that they have the right to make that determination, and to charge money for the information. I disagree.

3. As for arrogance, read the answer to the second question under "Member Selectivity". "We're real sorry if you lose a ton of money because you didn't know about a vulnerability. But it's not our fault that you're not important enough!"

I stand by my post. They're brushing us off like the criticisms don't matter without even considering them seriously. That bothers me more than the fact that I don't agree with the answers. I don't like their policies or attitude towards a community that has supported them in the past, and thus will not use their product. If you disagree, hey, what you run on your machine is your business.

Uhh, you didn't read the FAQ at all.

[pelrun]

I don't know where you get the "moving to a security-through-obscurity model" from. The FAQ makes it absolutely, positively clear that EVERY SINGLE CURRENT AVENUE of bug notification will REMAIN IN PLACE.

The list is purely an ADDITIONAL resource for those people running "if this dies then half the internet goes with it" DNS servers. It gives them a chance to patch up the mission-critical machines before every single script-kiddie in existence finds out how to bring them down. They ALREADY get this advanced notice; they have SINCE 1993! The only difference now is that the mechanism has changed.

EVERYONE who previously got their critical bug notification from CERT will CONTINUE TO DO SO. In THE SAME TIMEFRAME as before.

And as for you calling them arrogant, I think it's YOU who is arrogant. They're saying that if someone else produces a better product than they do (lets face it, BIND **IS** the dominant DNS server product - it's not boasting), that they will learn from it. And you're saying they SHOULDN'T learn from any better product that surfaces? You're just spouting flamebait.

Re:Uhh, you didn't read the FAQ at all.

[CyberKnet]

Uhuh. So I, John Q Public, find a security flaw in Bind. Then, being the good netizen that I am, I go and report it to ISC, saying "Your software is flawed, and I am root". They in turn say "Oh, let us inform our paying customers, fix this, and after that is done, tell the world. Thankyou." And proceed to make money off my work. They give me a thankyou, take a thousand* bucks from all involved, and then fix the hole. Thanks, but no thanks.

* DISCLAIMER: This is a guestimation of charges at best only. No weight should be given on the amount of money received by ISC for access to the closed list. Any at all is too much.

---

Re:Uhh, you didn't read the FAQ at all.

[f5426]

I laughed my ass off the so-called FAQ. Generally FAQs are done with real questions. Here, the answer ISC want to giuve to the community are re-written as questions. Like: "You mean this whole thing is just to _add_ a new level of access for the organizations ISC considers critical to the Internet's infrastructure."

> The FAQ makes it absolutely, positively clear that EVERY SINGLE CURRENT AVENUE of bug notification will REMAIN IN PLACE.

Use you head.

First, current way of handling bugs isn't correct, or this member-only list would not be necessary.

Second, with a different channel for the most demanding users, do you beleive that the current avenues will become more or less performant ?

Third, by having a fee-based list for most important security issue, do you think that ISC won't have an interest conflict ?

Fourth, this FAQ is written from the sole point of view of ISC. You need to take its content with a grain of salt, particulary due to the biased questions.

Fifth, what I found most missing are the guarantees. For instance, if there was something like a way to get access to all the list archive automatically after, say 7 days, I would be much less suspicious.

Cheers,

--fred

BIND perspective

[The Pim]

Though it may be a surprise to many, the security community generally agrees that immediate full disclosure of a discovered vulnerability is normally not the best policy. I cite for one rain forest puppy's Full Disclosure Policy, which has been widely approved and followed (see BugTrag archives for evidence). RFPolicy recommends a five day minimum before disclosure, even if the software maintainers are unresponsive, a ten day minimum if they at least respond, and arbitrary deferment of disclosure if they cooperate.

What is the purpose of the delay? To minimize the damage done by the vulnerability. Immediate disclosure means everyone's vulnerable until the news spreads, and even then, the only option is to disable the vulnerable program until a satisfactory fix is found (which is costly enough that many people will not disable it). Waiting until a fix is found still leaves people vulnerable while the news spreads, and subsequently while they evaluate the fix (a non-trivial task for critical systems), but it usually results in less overall harm. A logical next step is to inform, in confidence, the users most at risk prior to public disclosure. That, if we give them the benefit of the doubt, is all the ISC intends to do.

There are two problems with this strategy: It offends some people because it is inegalitarian and secretive; and the chance of a leak or independent discovery go up as the number of people in the know increases and time passes. If you hold an extreme version of the first position, you should argue that not even the program maintainers should get advance notice. This is a legitimate stance, but is by no means consensus among security researchers. Otherwise, you must admit that it's a trade-off, not a black-and-white issue.

Consider: Imagine you found a hole in a program you were using. Obviously, you would fix it locally before announcing it. Would you also get a review of your analysis from a trusted expert before disclosing? What if your friend were using it--would you tell him first? What if an organization you admire were at risk? It's a delicate balance.

I'm not defending Vixie's specific policy, I just want to point out it is not prima facie unreasonable.

Re:Sick of BIND? Me too.

[The Famous Brett Wat]

Due to the number of highly-moderated recommendations I've seen of this software on Slashdot, I decided to look into it. First up, I noted it's not in Debian, so I went hunting at cr.yp.to to see what the issue might be that keeps it out. My conclusion is that I'd be most happy to try it in principle, but there are two problems with it.

1. It's free beer. I don't mind free beer software: I use quite a bit of it. I prefer stuff that can actually be modified as needed, however, and not by distributing patches. If this were the only problem, Debian might be able to distribute it as non-free sotware, but then there's the second problem...
2. You can't modify it, and it has its own ideas about where to install stuff in the name of compatibility. Now I'm all for compatibility, but I think this kind of fiat is a really wrong way to try to go about it. I don't want to install this program on the grounds that it's going to mess up my nicely-structured Debian system. Debian's layout is as arbitrary as any other, really, but they've made it nice and consistent. The kind of solipsism demonstrated here by Bernstein is not welcome on my computer.

Maybe BIND sucks, but it's still got my vote for now. I'd buy Mr Vixie lunch if he was ever in the area.

Vixie needs to lay off

[Kp2]

KEEP IT OPEN!!

You can't *buy* the info.

[pelrun]

Paying money doesn't make you eligible. If you are eligible then you are permitted to join the list by signing the appropriate NDA's and paying the fees.

Even if I had a million US dollars and offered it to the ISC, I can't get onto the list - I don't run any DNS server critical enough.

Think about it - if you could join the list by simply paying for it, then the utility of the list DROPS TO ZERO. All you need is one cracker(or group of crackers) to get the cash and join, and then there is no longer any benefit in delaying notification because it is ALMOST CERTAINLY ALREADY PUBLIC. This service is for a select group of white-hats.

The fact that ISC collects fees from them is irrelevant; you are confusing implementation with motivation.

"ploy to raise capital" - they have to get money from somewhere. They are not-for-profit, so every cent they raise goes back into actually keeping the ISC functioning. And "market value of early information" only applies when that information is on the market. It's not - you *cannot* get the information using money alone.

Re:Secret Mailing lists are still evil.

[wuice]

Funny you should mention, as it's been pointed out many times that up here on /. that there *is* a reimplementation from scratch out there. Even funnier, it's written by the same guy who did qmail.

Re:Secret Mailing lists are still evil.

[MadAhab]

Right on. There's lot's of reasons to be suspicious and cautious, but membership might buy you an extra day to fix your servers and keep the internet from going pppppphhhhhhhht.

On the other hand, if they silently fix security holes, leaving unwitting users at the mercy of better-informed kiddies, they will deserve the flogging they will get and it will be fork time. But nothing I read in that FAQ leads me to think that will happen (although the distinction between 100,000 zones and 1,000,000 seems arbitrary; how many companies do you think fall in between?). And if it does, the code will probably fork and it will be obvious which lifeboat holds the smart folks.

Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.

Simple BIND fix

[mojo-raisin]

How about if the ISC holds on to the mailing list archives and releases them, say 6 months after they're sent. Then we could be sure there is no monkey business going on and "they" could pay for their special attention.

An open question to Paul Vixie and the Bind People

[Greyfox]

Do you feel your product is so insecure that it needs a closed, members only discussion list?

Sick of BIND? Me too.

[defile]

If you're a competent sys admin wishing you had an alternative to Vixie Inside, there's some hope.

Have a gander at djbdns. This is software done right people.

Instead of upgrading to the latest version of bind because of yet another security hole, I decided to switch. And I've been happy ever since.

I've been searching for an alternative forever and I still can't believe I hadn't come across djbdns until someone on Slashdot posted it. There must be others like me.

Re:Sick of BIND? Me too.

[Buddy]

The Famous Brett Wat wrote:

2. You can't modify it

This is not true. You're not allowed to distribute modified versions, but as long as you don't redistribute the package, you're free to do with it as you please - according to Bernstein.

Re:Sick of BIND? Me too.

[pdc]

As I understand it, Dan Bernstein does permit you (the owner of your computer) to modify the software to suit your system—including where it keeps its files. You can also make your own /etc/rc.d/init.d script so you don't need to use svc. He doesn't support it, but he says you have the right to do it.

This way you can still use documentation written for an unmodified system; you will know what changes you've made, because you made them. This is in contrast to vendors' helpful changes, which make it harder to write Djbdns in a Nutshell because each paragraph needs to detail the differences on half a dozen UNIX flavours, none of which is yours...

I find Bernstein's work very interesting. His style reminds me of Strunk & White (Rule 17, Omit needless words! becomes Omit needless features!). Things like the /service directory are very simple, elegant and useful. It's a pity that the licensing issue is going to get in the way. I can see his logic in eschewing the GPL if you already have all the rights he believes matter, but life would be easier if everyone just stuck with the good ol' GPL...

Re:Secret Mailing lists are still evil.

[mihalis]

ISC is trying to make money, yes, but it is a non-profit organization. They need the money to keep the global DNS system working. I assume you want that.

The most important port of an Open Source organization is that the Source is Open, which it is in this case. They are allowed to have private discussions just like anyone else, but anything substantive that is done to the code as a result of these discussions will be available just as soon as they've fixed certain critical nameservers.

If it weren't for this slashback this would be another slashdot hall of shame entry.

Someone would pay to be on this mailing list because anyone who runs a critical nameserver, or has customers that do so with their software will find it essential, no question. THAT is all.

Chris Morgan

Re:Secret Mailing lists are still evil.

[drinkypoo]

It is a clear attempt to make money by the ISC. They are supposed to develop Open Source software for the Interent. Money corrupts that.

Right, that's why RedHat is only doing things for people who pay them money, and not giving you an ISO you can download, burn, and install from.

More importantly, it is the secret nature of the list which is bad. The most important part of an Open Source organisation is that information is free. Here they are trying to make it secret.

This, I agree with. The whole reason that these lists are USEFUL is that they make vulnerabilities public right way, motivating vendors to issue patches ASAP, or at least workarounds.

--

They didn't listen to any criticism

[Lish]

Having read the FAQ, I don't think that the community "was a bit quick in their assessment of what's going to happen" at all. BIND is moving to a security-through-obscurity model. That much is clear. Mr. Vixie's answers in the FAQ indicate that the ISC did not take any of the criticism/comments from the community about this move seriously. Some of the answers sound like a parent brushing off questions from a small child. "Now, run along, and trust us to fix stuff in time. You don't need to know when a bug exists."

For example: the answer that referred to (paraphrased) "if anyone else's software runs on 80% of servers and is as dominant as ours, then we'll take a lesson from them" smacks horribly of arrogance. Nah, couldn't be that anything but the most widespread software would be the best, could it? *cough*Microsoft*cough*Sendmail*ehem* Just because your software is on more machines than others, doesn't mean it isn't "full of holes."

Basically, the ISC is closing off the information loop for its own benefit and leaving the little guys in the dust. I could understand this better if it were a purely commercial entity, but their purpose is to serve the community, not just an elite, specially chosen group who is willing (and able) to fork over the money to be in on the secrets. This is not right and that is exactly why the community is in an uproar.

Anybody who's thinking of migrating to BIND9: if you're going to retool for the new version anyway, just switch to something else. Save the headache in the long run.

This secret mailing list is a good thing

[Ben Schumin]

I'm tired of hearing about this secret mailing list thing, but I will explain to all of you why it is a good thing. BIND runs the dns for the entire internet. The root nameservers run bind. These are the nameservers that all the other nameservers use to figure out where they need to go. Your ISP most likely runs bind. Everyone runs bind.

Now, if a bug is found in BIND, do you really want every script kitty trying to make a name for himself to HACK ROOT on the ROOT NAMESERVERS for the ENTIRE INTERNET? Does this sound like a good plan to you? Wouldn't you rather, since the entire internet depends on them, that they get a chance to be patched up first?

I realize we're all in favor of open processes, but I think if anything this proves that in some situations they aren't appropriate.

As an example, have you ever left your front door unlocked? Would you prefer if someone told you personally, so you could fix it? Or would you rather they sent this information to the doorunlockedtraq mailing list to let you and everyone else know of the mistake you made, before you get a chance to fix it?

Re:This secret mailing list is a good thing

[biglig2]

Let us work the analogy further...

It is dicovered that certain models of the Acme "Gluon" door lock can be opened with wet spagetti.

This lock is used on lots of people's doors, and also on the door to the local army camps' armory, the local jail, and the town bank.

The lock makers, being responsible etc., want to tell people to change their locks, so they put an ad in the paper.

Now, the question here is, is it reasonable for them to quickly ring the camp, jail and bank, to tell them to change their locks straight away, and only then put the ad in the paper?

If yes, then the average joe has an insecure lock for a few dsays longer than strictly necessary, and has a risk of getting burgled if someone else discovers the spagetti trick.

If no, then there is a risk that the prisoners will escape, steal the guns, and rob the bank.

Re:This secret mailing list is a good thing

[Anoriymous Coward]

Or put another way, since the entire internet runs BIND, including myself on my poxy little home network, should the self-chosen elite (or worse, a pecuniously chosen elite) be allowed to know when your DNS server is vulnerable before you do?

To rework your door analogy, suppose a particular model of lock had a problem. Perhaps it can be opened with a piece of uncooked spaghetti. Would you rather that everyone was told, or just those people "with a reason to know", such as locksmiths, process servers and baillifs? Plus of course, any incognito burglars who'd stumped up the change to get on the list. Remember that you still think your door is locked.

Securing Bind Script

[stigmatic]

Sorry Slashdotter's on my prior post I had the link wrong. Its corrected now...

http://www.antioffline.com/secbind.html
Lazy Mans Link

Delayed mail archive

[Scrymarch]

I am forced to agree. However, there should be a time limit on it, to keep transparency. This is analagous to the way governments can't be expected to post troop positions on the nightly news.

I would hope for a bit more timely response than the 30-year + fudging type rules that predominate for government, however. How about a 30-day delayed archive? That way it gives them a chance to deal with vulnerabilities but the process is still transparent and dodginess can be made rapidly accountable. I suspect if you don't allow some secrecy for a matter as critical as this people won't use official forums at all, just send personal mail.

Re:Secret Mailing lists are still evil.

[roryi]

Really? That's hilarious.

Thank-you for brightening my morning.

BIND to djddns Migration Guide/ HOWTO

[DrProton]

Stop giving the knee jerk "switch to djbdns" replies.

It's a free country.

Installing djbdns is a pain in the ass.

tar zxf djbdns-1.04.tar.gz
cd djbdns-1.04
make
make setup check.

what a pain in the ass!

Switching from BIND to djbdns? Here's a howto: BIND-to-djbdns Migration Guide / HOWTO

Re:BIND to djddns Migration Guide/ HOWTO

[timftbf]

Hmm... followed the links from that HOWTO, and they're trying to convince me that the tinydns zone file format is more human-readable and easier to maintain than BIND zone files.

Now, more easily *machine* readable / writable I'll buy - autogenerating BIND zone files needs a little care, and parsing them is non-trivial. But to a human, which is easier to follow:

host.dom.ain IN A 1.2.3.4

which quite clearly tells you which type of record you're dealing with, or:

+host.dom.ain:1.2.3.4:0:4000000038af1379

which unless you're editing the damn things day-in, day-out, you're not going to remember which meaningless symbols correspond to which types of resource record.

The djbdns docs seem to advocate maintaining the DNS via the 'add-foo' scripts rather than editing zone files, secondarying is one of a variety of hacks ('run the axfr prog, filter the output in various ways, rebuild the database' or 'not our problem, use rsync'), and starting and stopping the daemons is non-standard.

The whole design simply doesn't work for me.

Regards,
Tim.

Re:Secret Mailing lists are still evil.

[drsoran]

Oh I don't know. How about they get advance knowledge of bugs that have been reported by decent Bugtraq users? Reports that let them prepare patches for their OS's before every lame-ass hacker and his brother gets the knowledge and goes on a script-kiddie hacking spree? Remember, it is the procedure of Bugtraq that you contact the manufacturer first and notify them of the bugs so that they can provide a fix in a timely manner. Only after you allow a sufficient amount of time to pass should you then release it to the public. Unfortunately there have been an increasing amount of luser kiddies out there who fail to take that step and think they can gain some kind of notoriety by posting bugs with exploits directly to Bugtraq without notifying the manufacturer. In BIND's case, the manufacturer (the BIND team) needs a mailing list that this contact can be contained to while working on patches so that said luser script-kiddies don't go terrorizing the net before a fix can be made available. Why on earth does everyone keep making this out to be some kind of vast conspiracy? BIND isn't becoming closed source and ISC isn't keeping security patches from being released. Chill out people.

You're all missing the point

[furrycat]

Don't want djbdns installed in /usr/local? Neither do I. I want it in /usr/djb (don't ask). So I take the hugely complicated step of running:

echo /usr/djb > conf-home && make setup check

Confused by the datafile format? Think it's no good unless you spend all day looking at it? Well isn't that what sysadmins do? Once you're used to it (which doesn't take long), don't you think it's easier to add edit one config file and run make (copy and paste new entries if you still can't remember which symbol means "A record") than to edit at least N files where N is the number of subdomains for which you are authoritative, remembering to increase an arbitrary number and then possibly root about in another config file, placed in a totally separate directory?

Don't like the way djbdns does secondarying? Good. You aren't supposed to. The whole point is that you don't worry about delegating "masters" and "slaves" and waiting fifteen minutes for them to synchronise. You just ssh your cdb database on to each of your dns servers.

What? You meant that you REALLY NEED to support a secondary running bind? Well what's so hard about tcpserver 0 53 axfrdns anyway?

Don't like the licensing issue? Oh come on. So Dan gives you complete freedom to hack away and change what you like with the sole condition that you don't distribute modified binary packages. Oh how harse. Actually you might not have noticed but Microsoft don't let you pass Windows around (they call it privacy) but they don't let you see the source either, let alone edit it or distribute patches. Sounds like Mr Bernstein's licence is a bit less restrictive than others. Oh, wait, I forgot. It isn't GPL and any other licence is no good.

Folks you have to learn that the whole point of djbdns, like the whole point of qmail, is to redesign from scratch bad software. Is it so surprising that it ends up doing things differently? So it takes a while to learn how to use daemontools and ucspi-tcp. So the cdb files and their intermediates the data files can be confusing at first. Isn't this worth putting up with if it means you don't have to spend half an hour editing your configs, nearly as long again waiting for the server to restart (remember bind has to slurp everything into memory and it's unusable while it's doing this whereas tinydns just a new data.cdb as soon as it's available) and then running away with all your memory? Isn't it more in keeping with the unix tradition to have separate tools for separate jobs (tinydns, dnscache, axfrdns)?

Why don't you stop moaning (probably your bad moods are caused by incessant patching of bind) and open your eyes to the superior alternatives?

Re:An open question to Paul Vixie and the Bind Peo

[Bob Uhl]

It's not that it is so insecure, it is that it is so vital. One may model the risk of publicising information by looking at the percentage of folks using the software--if .01 of the population uses it, a publicised risk won't hurt many. If .99 use it, a publicised risk could hurt nearly everyone. When you realise that BIND runs the root servers and the TLDs, you must accept that a flaw in it could take out those machines, and thus the entire domain name system; the 'net would be fragmented into little pockets of local namespaces.

The odds of a bug are not important to the equation: if in all of history there were one dangerous bug in BIND, it would still be important that it be fixed and the information be distributed to those important servers first.

To those who argue that security through obscurity is a bad idea: yes, it is. But it is also better than no security. To pubicise problems before a fix has been made is equivalent to taking an ad out in the paper stating that one's locks no longer function. Far safer to keep that information private and try to fix those locks ASAP, hoping that for a moment the insecurity will escape notice.

It's not as though DNS is a non-vital service which can be turned off in case of security flaws; rather, it must continue to run, even when it is known that it has problems. One can stop running irc if it has problems; DNS, OTOH, is essential.

Well, not really, but who remembers IP addresses anymore?

deez

[kaoticus]

Like sands through the hour glass.....

Secret Mailing lists are still evil.

[Kiss the Blade]

I just read the FAQ, and I find myself ill-convinced by the reasons given. It just strikes me as being bad in a couple of ways:

1)It is a clear attempt to make money by the ISC. They are supposed to develop Open Source software for the Interent. Money corrupts that.

2)More importantly, it is the secret nature of the list which is bad. The most important part of an Open Source organisation is that information is free. Here they are trying to make it secret.

Now, if you don't believe me, ask yourself this. Why would someone pay to be on this mailing list? What would they get out of it, that they couldn't get normally? I would guess that they get influence and information that gives them an unfair advantage. Secret Mailing lists for OSS related organisations are antithetical to the spirit of the OSS community, from which they benefit. That is all.

KTB:Lover, Poet, Artiste, Aesthete, Programmer.

Re:Secret Mailing lists are still evil.

[nightfire-unique]

More importantly, it is the secret nature of the list which is bad. The most important part of an Open Source organisation is that information is free. Here they are trying to make it secret.

Agreed; this is a problem, but for another reason as well: this eliminates a certain amount of liability for making mistakes.

Closed source software vendors are often more careless in the development of their products than open source vendors, knowing that there is less a chance that a vulnerability will become publicized (benefit of obscured code). The more public attention (via open mailing lists, open code, etc) there is, the more careful the programmers and QA teams must be, to avoid damaging their reputation (benefit of shared code/information).

I suspect this class division (trusted groups vs. the rest of the world) lessens the potential damage a serious security flaw could cause, which may in turn lower release quality.

--
All men are great
before declaring war

Speaking of bind...

[AFCArchvile]

...I just broke the binding of my Q3 manual. :-(

solution

[stigmatic]

Too bad the lameness filter didn't let me post a script for this.

Anyways I wrote a shell script for Linux, BSD*, for those lazy admins, or clue(lessler) admins, who don't know how to fix up DNS in a strong environment.

http://www.antioffline.com/secbind.html

Wow!

[Enahs]

Upon further inspection, I realize that Protozilla is probably the best thing since sliced bread. It sure would have come in handy this afternoon when I was working on Linuxdrivel.

Security through obscurity

[YuppieScum]

Hm...

I'd always thought "security through obscurity" was a bad thing...

Re:if you read the q3 manual.....

[AFCArchvile]

I was searching for a plot to Q3, and I found it in the manual.