Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

"DNS Forgery Pharming" Attack Against BIND 9

kdawson posted more than 7 years ago | from the better-hope-sitekey-works dept.

Security 105

Monley writes "Help Net Security is running a story about a severe flaw in BIND's implementation that allows fraudsters to efficiently predict generated random numbers without the need to control the route between the user and the DNS server. (Here are HTML and PDF versions of the paper.) Using this vulnerability, fraudsters can remotely forge DNS responses and direct users to fraudulent websites, which can steal the user's sign-in credentials and do other mischief. The flaw was discovered by security researcher and Trusteer's CTO, Amit Klein." The ISC has released a patch to BIND 9.

Sorry! There are no comments related to the filter you selected.

wow... (0, Troll)

Anonymous Coward | more than 7 years ago | (#19972789)

anyone still running BIND should just cut their feet off..

tinydns for ya'll niggaz in ya right mizzinds

btw, frist!

Re:wow... (1, Interesting)

Anonymous Coward | more than 7 years ago | (#19972975)

And what to you propose, Troll!

I won't run DJB's authoritative server as it violates the spec by not answering queries that have the recursive bit set. (The spec doesn't require honoring the bit, just answering the query out of what is knows would do).

Re:wow... (0)

Anonymous Coward | more than 7 years ago | (#19973319)

I propose you run and patch your bind ASAP, Mr. Clueless.

Re:wow... (2, Informative)

Anonymous Coward | more than 7 years ago | (#19973921)



OpenBSD's patched and native Bind9 is immune to this attack and has been for many years.

Re:wow... (1)

eneville (745111) | more than 7 years ago | (#19974231)



OpenBSD's patched and native Bind9 is immune to this attack and has been for many years.

But this article isn't about the OpenBSD stock, or about the DJB stock, it's about the -current version. Running BIND is like running sendmail... pretty stupid unless you *really* know what you're doing.

Re:wow... (0)

Anonymous Coward | more than 7 years ago | (#19974725)

Sure but OpenBSD had this patched in 1997... 10 years ago! Surely the ISC coders would have accepted the OpenBSD patches if it weren't for their politics.

OpenBSD++
ISC--

Re:wow... (1)

eneville (745111) | more than 7 years ago | (#19975613)

Sure but OpenBSD had this patched in 1997... 10 years ago! Surely the ISC coders would have accepted the OpenBSD patches if it weren't for their politics.

OpenBSD++
ISC--
The patch would probably be in BSD licence. I don't know what licence the ISC use. Maybe I'll look sometime.

Are you joking? (1)

Generic Player (1014797) | more than 7 years ago | (#19983329)

ISC use the ISC license, which is basically a 2 clause BSD license. OpenBSD also uses the ISC license. The patch is not accepted because its a patch to use the operating system supplied RNG instead of including a worthless broken one. ISC is more concerned about their software running on operating systems that suck than they are about it being secure on operating systems that don't suck.

Re:wow... (1)

Wdomburg (141264) | more than 7 years ago | (#19975899)

Neat trick, considering bind9 is only 7 years old.

Re:wow... (0)

Anonymous Coward | more than 7 years ago | (#19977089)

The patch was originally for Bind4 and moved forward.

Re:wow... (2, Interesting)

Wdomburg (141264) | more than 7 years ago | (#19976155)

I personally like my DNS servers to follow the relevent standards personally.

Of course I could go ahead and run the recommended DJB configuring using rsync + openssh to propogate zone files. Then I would avoid the 10 vulnerabilities filed against BIND9 over it's seven year life span, but open myself to the 40 or so against OpenSSH, 30 or so against OpenSSL, and 10 or so against rsync.

Re:wow... (1)

rs79 (71822) | more than 7 years ago | (#19980491)

"Of course I could go ahead and run the recommended DJB configuring using rsync + openssh to propogate zone files. Then I would avoid the 10 vulnerabilities filed against BIND9 over it's seven year life span, but open myself to the 40 or so against OpenSSH, 30 or so against OpenSSL, and 10 or so against rsync"

Looks good on paper, but in reality how many bugs have *ss* caused in real world name service? Zero.

How many compromised nameservers have there been because of bugs in bind? Non-zero.

Re:wow... (1)

Wdomburg (141264) | more than 7 years ago | (#19980741)

You seriously think there have never been real world compromises from OpenSSL and OpenSSH? Absolutely none?

If you look at the specifics of the vulnerabilities, none of the ones discovered so far in the BIND9 codebase have been privilege escalation. Mostly DoS, a couple cache poisons, one client side vulnerability in the backwards compatability stub resolver that's disabled by default, and a case of some leaked environmental variables. In the case of *ss* there are numberous code execution bugs. And yes, some exploits in the wild that led to real compromises.

Re:wow... (1)

RazzleDazzle (442937) | more than 7 years ago | (#19990707)

OR... you could just use OpenBSD and not worry about most discovered vulnerabilities such as this latest BIND one [marc.info]


unless of course you are of the opinion that BSD is dying.

Yes but... (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#19972831)

How can we blame this on Windoze?

8==========D~~~~~ ~~ ~~~{:-)

All over your face!

Re:Yes but... (1, Informative)

Anonymous Coward | more than 7 years ago | (#19973193)

Only clueless (windows) admins will install and run bind nowayday. There you go...

Re:Yes but... (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#19973569)

No, clueless Windows admins will install the DNS server that comes with Windows. And has never had a vulnerability. There you go troll boy.

Re:Yes but... (1)

matthewmok (412065) | more than 7 years ago | (#19973937)

What about this one:

http://www.microsoft.com/technet/security/advisory /935964.mspx [microsoft.com]

Punk.

Re:Yes but... (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19974385)

RPC problem; not the underlying DNS server. And if you have exposed RPC to the net then you have bigger problems than not being able to actually read an MS security bulletin. Tard.

Re:Yes but... (2, Insightful)

matthewmok (412065) | more than 7 years ago | (#19974843)

Moron,

It is related to MS DNS -- a SYSTEM you said did not have any vulnerabilities.

It's not hard to get a connection and a rooted machine in somebody's internal network. Also -- I can't think of anybody that would use MS DNS server outside on the Internet. If you do then that confirms my opinion of you.

FOSSie fix!!! (0)

Anonymous Coward | more than 7 years ago | (#19974905)

If only BIND were open source, this kind of stuff would never happen.

Oh, wait...

Re:FOSSie fix!!! (3, Insightful)

m.dillon (147925) | more than 7 years ago | (#19976125)

A large number of programmers can make minor modifications to small software applications.

A medium number of programmers can make minor modifications to medium-sized software applications.

Very few programmers can make any sort of modification to very large software applications. Very, very few.

Bind is a very large, complex piece of software. A good portion of that complexity is due to poor documentation and badly designed algorithms (a problem I've had with bind from the first release on through today), but at this point the majority of the complexity is due to feature creep. I still use bind simply because I do not have the desire to write a replacement for it, and because the only other really good DNS package has a copyright and licence on it that makes it virtually unusable. Software gets stale as it gets older... if I can't keep software up to date after the original author has lost interest then I have no interest incorporating said software, no matter how good it is.

-Matt

Re:FOSSie fix!!! (1)

Lennie (16154) | more than 7 years ago | (#19976779)

I'm pretty sure you also use gcc, then why not use powerdns-recursor ? I'm pretty sure it has the same license.

Ohh, euh... I think I know what the problem is.

Please, please, please, could you implement a good swapcontext and getcontext
implementation for the BSD's ? :-)

Re:FOSSie fix!!! (0)

Anonymous Coward | more than 7 years ago | (#19979069)

OK, you're clearly talking about djbdns' license. However, I don't think you have really looked at the alternatives: PowerDNS, MaraDNS, and NSD. There are good DNS servers out there, and it's not just a choice between BIND and having to patch djbdns (you have to; djbdns has a remotely exploitable security hole) by hand.

Seriously, if you have had problems with PowerDNS, MaraDNS, and NSD, please detail them. It sounds like you haven't tried them.

New (1, Insightful)

HomelessInLaJolla (1026842) | more than 7 years ago | (#19972833)

However, security researcher and Trusteer's CTO, Amit Klein, has discovered a severe flaw in BIND's implementation which allows fraudsters to efficiently predict generated random numbers without the need to control the route between the user and the DNS server.
How long has BIND been using the same random number generator? I'm a little bit skeptical that Mr. Klein is the first person to consider the possibility of mimicking its behavior.

Maybe the headline should read,"Exploit which bored college students figured out fifteen years ago is finally released to the mainstream".

Re:New (2, Insightful)

dave562 (969951) | more than 7 years ago | (#19973037)

Maybe those bored college students should have gotten off their asses, put down the bongs and published some research that they would have been paid for.

Re:New (1)

Poltras (680608) | more than 7 years ago | (#19973357)

You're obviously NOT subscribed to full-disclosure...

Re:New (1)

dave562 (969951) | more than 7 years ago | (#19973457)

You sir are correct.

Re:New (3, Insightful)

hal9000(jr) (316943) | more than 7 years ago | (#19974079)

Maybe those bored college students should have gotten off their asses, put down the bongs and and written some bots that they would have been paid for.

Oh wait, that isn't ethical ...

Re:New (0)

Anonymous Coward | more than 7 years ago | (#19975737)

budsmokers: 1
establishment: 0

Re:New (1)

ArsenneLupin (766289) | more than 7 years ago | (#19983075)

should have gotten off their asses,
Hehe, nice way to put it. Sneak 65.98.92.48 in them DNSes

Re:New (1)

TruePoindexter (975295) | more than 7 years ago | (#19973085)

Maybe the headline should read,"Exploit which bored college students figured out fifteen years ago is finally released to the mainstream".
They are a source of major innovation aren't they? Whitespace anyone? http://compsoc.dur.ac.uk/whitespace/ [dur.ac.uk]

Re:New (2, Interesting)

countSudoku() (1047544) | more than 7 years ago | (#19973107)

We'll thank goodness the people who are claiming the exploit *also* happen to have a product to defeat said exploit...

"Existing desktop security solutions cannot protect against this type of attacks since DNS forgery pharming does not involve the user's computer or the DNS server but rather the cached data on the DNS server. Mutual authentication solutions, such as Trusteer's Rapport, which strongly authenticates the destination website and prevents access to unauthenticated websites, can defeat the attack."

How convenient! ;)

What version of BIND is going to have the fix? I've got 9.3.2 at the moment.

Re:New (4, Interesting)

Charles Dodgeson (248492) | more than 7 years ago | (#19973141)

How long has BIND been using the same random number generator? I'm a little bit skeptical that Mr. Klein is the first person to consider the possibility of mimicking its behavior

If you read the PDF, you will see that a good history of this kind of attack (and previous responses to it) are detailed. Apparently there has been is history of research into this kind of attack, with various counter measures. But the new attack (which seems like it would apply to almost all versions of BIND9 takes a different approach at "cracking" the PRNG which looks like it could be run against real-world servers.

I don't pretend to understand everything (or even most things) in the PDF, but it looks like solid research to me.

Re:New (3, Informative)

e9th (652576) | more than 7 years ago | (#19973205)

This weakness of BIND has been griped about for TEN YEARS!

http://www.openbsd.org/advisories/res_random.txt [openbsd.org] http://cr.yp.to/djbdns/forgery-cost.txt [cr.yp.to]

Re:New (0)

Anonymous Coward | more than 7 years ago | (#19973295)

I think you'll find that the general idea, IE the possibility of forgery if the sequence numbers are predictable, has been well known for quite some time. The thing that's novel in this approach is a new attack against the PRNG that renders the output predictable in the real world.

MOD PARENT DOWN (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#19973271)

Insightful? Are you kidding me? This guy has been posting this crap for over six months. It's these shitty posts that keep him at positive karma between his trolling runs.

Where is your evidence? These types of exploits are found all the time, this isn't even news worthy. Check the bug reports at any major project and you will find code that is decades old still has a constant stream of exploits being discovered and released. There is no reason to believe this was discovered fifteen years ago, unless you have evidence that the general public doesn't know. If so, please share.

This conspiracy theory doesn't even make sense. If someone would hide an exploit for fifteen years, why in the hell would they just now release it?

I've honestly seen better attempts in your time. I guess it doesn't matter anymore, since any and every conspiracy theory is modded up these days.

Re:New (0)

Anonymous Coward | more than 7 years ago | (#19974201)



OpenBSD patched this back in 1997 [openbsd.org] Search for "OpenBSD" in that page.

Re:New (0)

Anonymous Coward | more than 7 years ago | (#19975067)

I agree with your latest JE. You should be given 10 years of probation and 500 hours of community service for harassing the users of slashdot.

Furthermore, I think we should launch a class action lawsuit against you.

Re:New (0)

Anonymous Coward | more than 7 years ago | (#19975223)

I concur. Shall I supply the lawyers? Afterall, I do have a job and can actually afford such things.

Good luck with your court appointed attorney, HILJ.

Re:New (0)

Anonymous Coward | more than 7 years ago | (#19975321)

If you would, kind sir or ma'am, supply the lawyers. I would be happy to sign a petition against this alleged homeless troll.

Come again? (4, Insightful)

Angst Badger (8636) | more than 7 years ago | (#19972849)

Since when is a severe flaw in BIND's implementation news?

Troll? Y'all are NEWBS! (1)

spun (1352) | more than 7 years ago | (#19973049)

Come on, whoever marked this as troll has no idea of the history of BIND, or how many times many of us have had to patch BIND over the last ten years. Consider this: BIND is the only server that I've ever seen a distro package so as to be easily chrooted. Why do you suppose that is?

Re:Troll? Y'all are NEWBS! (1)

msimm (580077) | more than 7 years ago | (#19973233)

It's news because for a number of readers will be effected (no matter how many times it might have happened in the past). As for chrooting it's really a shame more packages *aren't* commonly jailed. But even bind isn't frequently chroot by default.

Re:Troll? Y'all are NEWBS! (1)

spun (1352) | more than 7 years ago | (#19973515)

Sure, I know it's news, but I think the original poster was being sarcastic. In think he thought it was news, too. It's just, you know, the umpteenth time you have to patch BIND, sometimes you just snap... BIND isn't chroot by default but on several distros, jailing it is as easy as firing up Ye Olde Distro Specific Configurator and checking the "run BIND chroot?" box. I agree, more server packaged should come with the nice little scripts to chroot them easily.

Re:Troll? Y'all are NEWBS! (2, Insightful)

TheRaven64 (641858) | more than 7 years ago | (#19973925)

Consider this: BIND is the only server that I've ever seen a distro package so as to be easily chrooted. Why do you suppose that is?

Because BIND is the only one that's easy to run in a chroot. OpenBSD also runs Apache in a chroot, but it means you lose features, like the ability to share everyone's ~/public_html. BIND is quite rare among servers in that it's non-trivial but has fairly meagre requirements when it comes to disk access. I can't think of any others off the top of my head that meet this requirement, with the exception of an ftpd that is only used for anonymous FTP, and these tend to support chroot too now.

Re:Troll? Y'all are NEWBS! (2, Insightful)

Wdomburg (141264) | more than 7 years ago | (#19976321)

Eh? BIND9 has a relatively tame history in terms of vulnerabilities. Just using the updates to RHEL3 as a quick and dirty metric, there have been two security updates compared to 5 openssh, 6 openssl, 11 php, 12 apache, 20 kernels, etc.

Unfortunately a lot of people seem stuck in the past and still judge BIND from the 4.x and 8.x days.

Re:Troll? Y'all are NEWBS! (0)

secolactico (519805) | more than 7 years ago | (#19976855)

Why do so many distros default to sendmail and bind? There was a time when running sendmail felt like an open invitation for people to break into your system. Debian has exim and Redhat offers postfix as one of it's defaults, why hasn't an alternative to bind come forward (from a distro provider point of view. The end user/admin can always install something else).

Re:Troll? Y'all are NEWBS! (1)

Crazy Eight (673088) | more than 7 years ago | (#19989533)

Because no one has published a GPL clone of djbdns?

Re:Come again? (0, Offtopic)

The Raven (30575) | more than 7 years ago | (#19976639)

I just wish more places would use djbdns [cr.yp.to] .

Similiar To This Forgery? (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19972985)


Dear Patriots:

In order to defend democracy and freedom in the United States of America, please send your checks ( cash is preferred) to
Operation Neck_ Deep_ In_ The_Big Sandy ( formerly called "The Surge") [whitehosue.org] .

Please leave the payee line blank on your checks.

Your Talibangelism is greatly appreciated.

Anti-Constitutionally As Always,
George W. Bush

The flaw was discovered by... (1)

asphaltjesus (978804) | more than 7 years ago | (#19973039)

... the CTO's underlings doing the hard work and the CTO gets the credit.

IMHO, the story wouldn't garner any interest whatsoever if the summary did NOT include mentioning the CTO. Look at the grief your average employee get when they publish an exploit.

Our product not vulnerable to flaw we discovered.. (3, Insightful)

fahrbot-bot (874524) | more than 7 years ago | (#19973165)

The flaw was discovered by security researcher and Trusteer's CTO, Amit Klein.

The TFA recommends using Trusteer's product to defeat this attack:

Mutual authentication solutions, such as Trusteer's Rapport, which strongly authenticates the destination website and prevents access to unauthenticated websites, can defeat the attack.
So, to recap. Vendor discovers a flaw and recommends their product.
Film at 11:00.

A flaw in BIND? (1)

AliasTheRoot (171859) | more than 7 years ago | (#19973169)

Say it isn't so!

Isn't it part of the INSTALL doc to run it in a VM/Jail/Chroot?

Re:A flaw in BIND? (1)

phoenix.bam! (642635) | more than 7 years ago | (#19973211)

This isn't an attack on the server. It is a hijack attack against clients of the server.

Re:A flaw in BIND? (1)

Lost+Found (844289) | more than 7 years ago | (#19973503)

Um, this flaw doesn't allow you to take over the process context of the BIND server. Instead, it allows you to poison the BIND DNS cache with phony records of your choosing.

Again.... (3, Funny)

gweihir (88907) | more than 7 years ago | (#19973185)

Bind was and is a mess. The patch is to use something else....

Re:Again.... (1)

Xugumad (39311) | more than 7 years ago | (#19975301)

I live in the niave hope that there's only so many bugs you can fit in one piece of software, and as such Bind and Sendmail should be practically impossible to break by now...

Re:Again.... (1)

jZnat (793348) | more than 7 years ago | (#19975933)

Well, maybe if people would move on and use other software like postfix and powerdns (just off the top of my head), we wouldn't be having all these issues, now would we?

Re:Again.... (1)

gweihir (88907) | more than 7 years ago | (#19978447)

I live in the niave hope that there's only so many bugs you can fit in one piece of software, and as such Bind and Sendmail should be practically impossible to break by now...

Well, I think the thing is that you can fit only so many bugs per line of code, and both are growing...

Re:Again.... (1)

Tony Hoyle (11698) | more than 7 years ago | (#19981617)

They pretty much are.. when's the last time you heard of a vulnerability in sendmail?

This particular one is - as others have pointed out - about 10 years old and really doesn't matter.

Complexity breeds problems. (0)

Anonymous Coward | more than 7 years ago | (#19973277)

Hmmm. Is a DNS server really that complicated?

Re:Complexity breeds problems. (3, Informative)

Kreggan (36002) | more than 7 years ago | (#19973573)

Frankly, yes. The basic concepts of a DNS server are fairly straightforward, but as demonstrated by this attack, the devil is in the details. This attack uses reasonably advanced cryptanalysis, and exploits the predictable behaviour of DNS clients. I suspect that this attack would also have been mitigated by the use of DNSSEC, but the roll-out of that has been held up for years - and DNSSEC itself introduces even more cryptographic complexity.

Re:Complexity breeds problems. (1, Insightful)

Anonymous Coward | more than 7 years ago | (#19979713)

Yes, universal deployment of DNSSEC would have completely defeated this attack.

ISC software unfortunately is low quality (0)

Anonymous Coward | more than 7 years ago | (#19973459)

Also consider the dhclient shipped with at least all Red Hat-based installs.
Fragile software, non-standard cmdline option parsing, requires certain kernel parameter set (socket filtering for UDP) and is slow and quite big (for its functionality). Media-disconnects or booting without network cable is not handled (the latter resulting in an unreachable box even when the cable is re-attached).
Don't get me even started.

Don't Diss Bind (3, Insightful)

toonerh (518351) | more than 7 years ago | (#19973985)

Bind has been around since the dawn of Vint Cerf's IP, but it has been redesigned and rewritten several times. The RFC that says replies go via UDP make it a security risk, but also make the net work better.

In 2007, where 1000,s of "researchers" spend their lives trying to break the Internet.... This stuff happens. BIND, SendMail and classic solutions are attacked. Amazingly they hold up better than Windows!

Re:Don't Diss Bind (0)

Anonymous Coward | more than 7 years ago | (#19974849)

Yeah, better than Windows.

Since this is Slashdot the parent post will be modded up and I'll be modded down, but the truth of the matter is that the DNS server that ships with Windows has never has a single vulnerability.

Re:Don't Diss Bind (2, Insightful)

Anonymous Coward | more than 7 years ago | (#19976033)

Yeah, better than Windows.

Since this is Slashdot the parent post will be modded up and I'll be modded down, but the truth of the matter is that the DNS server that ships with Windows has never has a single vulnerability.


Wow, you must have a VERY short memory. Try thinking back to just earlier this year, when Microsoft Security Advisory (935964) [microsoft.com] came out. And that is just one of MANY flaws over the years in MS DNS server! Hell, their DNS server for NT4 and earlier releases of Win2K (pre SP3) ran so sloppy that most people had to write scripts to stop/restart their MS DNS servers nightly! I should know, I was one of them. It was the only way to fix memory leaking problems that would lead to cache lookup failures. And lets not forget the long era of MS DNS cache poisoning...

No, BIND has proven it self to be MUCH more reliable for serious Internet servers than MS DNS. Just like Unix/Linux has proven to be a better OS for serious Internet servers than MS Windows. There is a reason the REAL Internet servers of the world use Unix/Linux and BIND. It's because they handle more critical traffic than any thing else, they absolutely have to work, and MS products are NOT up to that task! No amount of marketing hype can counter the real world expeirence of professional network engineers, and the pro's choose Unix. Windows Server has become more reliable over the years, and is viable product for small and medium businesses. But it has never been, currently isn't, and may never be reliable enough for those really critical high end servers that large ISPs, governments, and businesses need.

The only reason people like you bitch about the popularity of Unix/Linux for high end servers is because you obviously know little about such things, but want to pretend that because you can install Windows 2003 Server and Exchange that you now know something about network engineering. Sorry, you don't... No one who does would have said "the DNS server that ships with Windows has never has a single vulnerability" because they would have had the real world expeirence of dealing with the problems that DO EXIST with that product! Knowing your way around a Windows server does make you talented, but it doesn't put you in a position where you know enough to go around dissing technologies you have obviously never even used...

Re:Don't Diss Bind (0)

Anonymous Coward | more than 7 years ago | (#19975107)

BIND does not hold up better than Windows DNS. You are a stereotypical zealot.

Re:Don't Diss Bind (1)

rs79 (71822) | more than 7 years ago | (#19980483)

"Bind has been around since the dawn of Vint Cerf's IP"

Not quite, try about 10 years later.

Paul Vixie when at decwrl was funded by his boss, Brian Reid to take the Berkley B-Tree code and whip up a name daemon. This cost Dec quite a bit of money. This was in the mid to late 80s or so. Remember that the relevenat RFC for the domain name system only came out in 86.

at least they are not hackers .. (1)

terbo (307578) | more than 7 years ago | (#19974029)

nice change of terminology there. quite refreshing, fraudsters . .. . .

slashvertisement for Trusteer's Rapport? (0)

Anonymous Coward | more than 7 years ago | (#19974105)

Last line in the article:

"Mutual authentication solutions, such as Trusteer's Rapport, which strongly authenticates the destination website and prevents access to unauthenticated websites, can defeat the attack."

Seriously, how feasible is this attack against the common web surfer?

entropy? (1)

thibbledorf (1076171) | more than 7 years ago | (#19974131)

I bet there's a way to incorporate some qrbgs [random.irb.hr] randomness to improve the security.

djbdns (2, Interesting)

jsdcnet (724314) | more than 7 years ago | (#19974493)

I've been using djbdns [cr.yp.to] for years. It takes some getting used to if you're coming from BIND-land but it's worth making the effort.

Re:djbdns (3, Interesting)

Antique Geekmeister (740220) | more than 7 years ago | (#19975035)

Try looking at the copyright on djbdns. None, I repeat *none*, of Dan Bernstein's technically excellent solutions have propagated to broad use because of his extremely poor documentation, installation instructions, violations of the UNIX FileSystem Hierarchy, unwillingness to allow others to fork his code even for ease of packaging reasons, confusing licensing, etc.

The functionality of clever tools like QMail and djbdns and daemontools has thus wound up sidelined and ignored by mainline developers. There are numerous lengthy and well-frounded rants on this, such as http://linuxmafia.com/~rick/faq/index.php?page=war ez#djb [linuxmafia.com] . And like the absurd licensing conditions of Pine and the University of Washington wu-imapd, the refusal to accept input or insights from others or cooperate with its packaging for more stable configurations has led to their being discarded from most distributions.

Re:djbdns (1)

Crazy Eight (673088) | more than 7 years ago | (#19990019)

I think you're overstating the case when you slam his documentation. I've found some of it to be so clearly expressed that it seems obvious he is a teacher. The problem with it is that it lives on his server in html format.

DJB's software is held up only by his licensing. Gerrit Pape's runit is a clone of daemontools with some added functionality. It's packaged in Debian and FreeBSD because it's GPL, not because daemontools is deficient in some way.

It's a shame Bernstein is such a polarizing figure. His disciples and detractors can be equally annoying and the noise buries a worthy signal.

Re:djbdns (0)

Anonymous Coward | more than 7 years ago | (#19976643)

I use djbdns also and haven't any serious problems with it. Sendmail and BIND has more problems than I like so that is the reason why the previous admin and I went and left using qmail and djbdns. There is no prefect software package out there or will there ever be but my work has been much easier with djb software.

Re:djbdns (2, Interesting)

Anonymous Coward | more than 7 years ago | (#19979649)

No, Djbdns is not acceptable. Its list of root name servers is five years out of date, and there is a remote denial of service security problem which has not been fixed. Heck, it won't even compile in any Linux distribution from the last three years or so.

And, no, you can't fix these issues and distribute a "djbdns-fixed.0.1.tar.bz2" file with the fixes in place, because djbdns is not open source.

djbdns is dead and has been dead for years now.

Jeezus freaking A Christ (3, Interesting)

m.dillon (147925) | more than 7 years ago | (#19975559)

Why the hell is bind trying to implement its own random number generator? It's a piece of junk compared to the random numbers modern BSD OS's generate via libc.

-Matt

Re:Jeezus freaking A Christ (2, Informative)

TheRaven64 (641858) | more than 7 years ago | (#19975969)

Probably because BIND has to be cross-platform. I'm sorry to break this to you Matt, but some people use inferior operating systems without good random number generation function.

Re:Jeezus freaking A Christ (4, Insightful)

eggnet (75425) | more than 7 years ago | (#19978903)

Probably because BIND has to be cross-platform. I'm sorry to break this to you Matt, but some people use inferior operating systems without good random number generation function.
That doesn't prevent BIND from using superior OS provided services for platforms that do have good random number generators. They decided not to do it, plain and simple.

Re:Jeezus freaking A Christ (1)

Wdomburg (141264) | more than 7 years ago | (#19980639)

They do utilize /dev/random if it exists, to seed and reseed the PRNG. There's a few reasons I can think of not to use those exclusively:
  • On some platforms /dev/random blocks if the entroy pool is exhausted. Really really great when you're trying to service thousands of queries a second.
  • On platforms where /dev/random doesn't block (or an alternate device like urandom is used for non-blocking random number generation) you're going to end up with a PRNG anyways.
  • They have to ship and support a generator regardless, since some platforms lack a built-in facility.
  • Adding in platform specific hooks adds code paths. Additional code paths add bugs.
  • They would need to track and circumvent vulnerabilities in every external PRNG they would potentially rely on.
  • They would need to issue security alerts every time a weakness was discovered in a third-party PRNG implementation. (And what do you want to bet this would just perpetuate the currently unwarranted poor security reputation even if the fault was outside the ISC codebase?)

Underscores the need for good design (1)

supachupa (823309) | more than 7 years ago | (#19976985)

At my organization, I've configured our DNS as split-split. Split-split means that the outside world only gets nonrecursive advertisements of our authoritative domains, separate servers are configured for the inside to do recursive queries(i.e. forwarders), and a last set is for our user land dns servers which forward to our recursive nameservers. Only these dns servers are allowed to talk to the forwarders, which sit in their own DMZ.
Now, my servers may have the same vulnerability as yours, but the risk of it being exploited is much lower. This buys me time to patch any given flaw without panicking too much.
To those that knock BIND, for its lack of security: if a system (i.e a group os servers meant to provide a service) is designed and then configured securely, even when flaws are discovered, the chances of getting hit can be vastly reduced. Yes, there are more secure versions of DNS out there, but BIND is the most popular. DJBDNS has a great reputation, but my solution works just fine and I don't have to learn yet another version of something that when passed on to the next person will go on neglected for years.

Re:Underscores the need for good design (1)

agbinfo (186523) | more than 7 years ago | (#19978777)

Warning: I'm pretty much clueless about this whole thing but I did read the report.

From what I've read, you're not safe either even with Split-Split.

What they claim is that you only need to get the caching server to make a few consecutive CNAME requests and they achieve that through CNAME chaining. Using those requests, they get your caching server's next not-so-random sequence number and start sending it DNS responses.

Like I said, I'm pretty clueless about DNS servers but after reading the article, I felt like I could probably setup an attack myself.

Re:Underscores the need for good design (1)

TheLink (130905) | more than 7 years ago | (#19979299)

BUT, the attacker needs to be _inside_ his organization in order to talk to the caching server (the inside dns server).

This sort of thing has been done for ages even with BIND.

With djbdns you actually have NO CHOICE and MUST do it that way - it's split into multiple programs e.g. tinydns = authoritative DNS (tell world about names), dnscache = caching server (to make recursive DNS requests for clients and cache them).

Anyway, the ISC has never had a good track record with software (dns, sendmail, dhcpd). Trouble is some alternatives are even worse :).

Re:Underscores the need for good design (1)

agbinfo (186523) | more than 7 years ago | (#19982503)

The way I was understanding this, please correct me if I'm wrong, is that you don't need to be inside since you pollute the external DNS server. Once it's polluted, all the inside servers get their DNS information from that polluted server. In order to be able to pollute the external server, it must have no DNS entry for the site you want to pollute or its entry must be expired. You also need to trick some internal user to visit your site. This would probably make it extremely difficult to pollute entries for very popular sites since the DNS entry would be present or updated soon after it expired.

As mentioned in my previous posts, this is my understanding from reading the article. I am no expert in this domain.

Split DNS explanation (1)

TheLink (130905) | more than 7 years ago | (#19984513)

You need to be inside, or need to bypass the firewall or other controls.

He was talking about a split DNS server configuration.

In my experience this is where you have:
1) External DNS server(s)
2) Internal DNS server(s)

Configuration A
(where the internal DNS server is allowed to do DNS queries directly)
An External DNS server provides authoritative replies for the domains it is Authoritative for to externals.
An External DNS server does NO recursive queries for anyone.
An Internal DNS server only does recursive queries for all internal clients.
An Internal DNS server does those queries directly.
An Internal DNS server may provide authoritative replies to internals for the internal-only domains it is authoritative for.

Configuration B
(where the Internal server has no direct access to the outside world - all requests have to be "proxied/forwarded" via an external DNS server)
An External DNS server provides authoritative replies for its own names to externals.
An External DNS server only does recursive queries for the Internal DNS server.
An Internal DNS server does recursive queries for all internal clients.
An Internal DNS server forwards the queries to an External DNS server (if paranoid, it may be one just for that purpose that does not even answer external queries).
An Internal DNS server may provide authoritative replies to internals for the internal-only domains it is authoritative for.

As you can see, you can't really pollute the External DNS server from outside, especially in Configuration A (where the external server doesn't really care about making queries) or a Paranoid Config B (where it's a different external server involved). And you should not be able to even reach the Internal DNS server from outside.

Note: both the internal and external DNS servers may be authoritative for say www.thecompany.com (and thecompany.com), but resolve those to different IP addresses. So outsiders might get one site. Whereas insiders might see something else. And intranet.thecompany.com and other internal names might only exist on the internal DNS server, and not exist on the external DNS server. I believe this is good practice.

Note #2: In a fairly secure network config, NONE of the clients get direct access out, not even for DNS queries - they all have to use the DNS server or even a proxy. So it will be a lot rarer to have outsiders complain about your malware infested clients "attacking them" even if someone inadvertently brings one in.

So.. if BIND9 sucks.. what is an alternative? (2, Insightful)

wethion (871311) | more than 7 years ago | (#19977629)

Lets see, it has to be GPLed or BSDed, run on every platform, be insanely robust, free as in beer, tested so thoroughly that it ought to make the law of gravity look like shaky science. So, based on those criteria, what DNS software could hold up? Just wondering. Peace, V

Re:So.. if BIND9 sucks.. what is an alternative? (1)

humungusfungus (81155) | more than 7 years ago | (#19979297)

Well, one answer: djbdns

Re:So.. if BIND9 sucks.. what is an alternative? (2, Insightful)

Just Some Guy (3352) | more than 7 years ago | (#19979709)

Well, one answer: djbdns

djbdns is proprietary, source-available software. It's nowhere near BSD or GPL licensed.

Re:So.. if BIND9 sucks.. what is an alternative? (2, Interesting)

elp (45629) | more than 7 years ago | (#19979999)

Don't forget DJB's legendary personality as well.

I've been using PowerDNS [powerdns.com] to manage several thousand domains for almost 3 years and its been the best thing I ever did. Besides being GPL it has an SQL backend so doing things like changing the TTL for 300 domains takes a few seconds instead of the slog or scripting nightmare with BIND. I use mysql replication to keep my slaves uptodate which is also flawless. Load average handling around 150 queries a second is less than 1%

There is a postgres backend for it as well although I have never tried it.

Re:So.. if BIND9 sucks.. what is an alternative? (1)

yestertech (246954) | more than 7 years ago | (#19980103)

The PostgeSQL backend works smoothly, and fits in with other services and backups. It is a simple table though and does not take any advantage of the relational capabilty.

Re:So.. if BIND9 sucks.. what is an alternative? (1)

Just Some Guy (3352) | more than 7 years ago | (#19982213)

Besides being GPL it has an SQL backend so doing things like changing the TTL for 300 domains takes a few seconds instead of the slog or scripting nightmare with BIND.

I haven't used PowerDNS but I've heard nothing but good about it. I only host about 20 DNS zones and BIND comes with FreeBSD, so I never bothered to learn anything else.

BIND maintenance doesn't have to be painful, though. The key is to refactor your zone files into smaller include files and let it auto-complete as much as necessary. Here's my standard template file:

$TTL 1800

@ IN SOA kanga.honeypot.net. root.kanga.honeypot.net. (
2007072002 10800 3600 604800 86400 )

$INCLUDE external/glaakipeerheader

$ORIGIN @
$INCLUDE external/www-kanga

It expands "@" to the domain name that loaded it. That is, if I have something like:

zone "example.com" {
type master;
file "external/standardtemplate";
};

then it gets expanded to "example.com". Then it includes a file which pulls in my site's standard secondary NS and MX records, A record, and SPF/LOC records. Finally, it pulls in the standard entry for "www.".

If I need to update 18 of those 20 domains, I just edit that one file and reload. No, it's not as elegant as an SQL backend, but neither does it have to be a scripting nightmare if you plan it right.

Re:So.. if BIND9 sucks.. what is an alternative? (1)

kc0dxw (42207) | more than 7 years ago | (#19985181)

I am using (and like) maradns -- http://www.maradns.org/ [maradns.org] . The format of the zone file is *much* simpler.

Just an idea (2, Interesting)

master_p (608214) | more than 7 years ago | (#19982349)

Shouldn't login into a web site be bi-directional? not only a user logs in a web site but the web site should log in a user by submitting to the user a password (let's name this password back-password).

The login sequence should be:

1) user submits his username.
2) site submits the back-password.
3) if back-password is correct, user submits his password.

By using bi-directional login, if the site is spoofed, the login process will fail, unless the spoofed site knows the back-password.

After login, communication should be encrypted so as that no 3rd party can eavesdrop on the communications.

Won't work (1)

jgoemat (565882) | more than 7 years ago | (#19986293)

1) user submits his username.
2) site submits the back-password.
3) if back-password is correct, user submits his password.

Let's say this occurs with a spoofed site, this is what could happen:

1) user submits his username to spoofing site
2) spoofing site connects to actual site and submits user name
3) actual site submits the back-password to spoofing site
4) spoofing site submits back-password to user
5) user will see the same back-password he saw if he connected to the actual site

Why not just use SSL? How browsers guarantee a site using SSL is that there is a public and private key. Everyone has the public key but the private key is kept secret by the site. The public key can be used to validate that the corresponding private key was used to encrypt or sign data. Now you would think that a site could spoof SSL by generating their own public key and private key, and giving the user their public key instead of the actual site's public key. This is prevented by having certificate authorities. Sites submit a signing request to a certificate authority based on their public and private key. The certificate authority then uses their own private key to sign the request. The Certificate Authority's public key that the user uses to verify the signature is incorporated into your browser.

Basically, let's say John is talking to Mary. Mary goes to Andrew to vouch for her. John trusts Andrew, he's a good friend. Mary tells John who she is, and John verifies her identity with Andrew.

Hackers, to your keyboards! (1)

ArsenneLupin (766289) | more than 7 years ago | (#19983059)

Point all A records to 65.98.92.48!

BIND 9 != (BIND 8 || BIND 4) (0)

Anonymous Coward | more than 7 years ago | (#19987419)

BIND 9 was a complete rewrite, and, unlike previous packages called "BIND", has a respectable security track record.

These troglodytes who crawl out of the woodwork whenever there is a BIND-related security alert and mutter "who runs BIND anyway? just run a secure package like djbdns (or _insert_name_of_favorite_non-reference_DNS_package _here_) instead" really aren't up on current technology in the DNS-software space.

As for the references to chroot'ing, BIND has had built-in chroot capability for years now. Any distro that doesn't take advantage of that capability has only itself to blame.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?