Developers have published a fix to tackle a high-risk flaw in BIND, the widely used Domain Name Services (DNS) software. The flaw creates a potential mechanism for miscreants to crash systems running vulnerable version of the name-to-IP-address translation software. Left unaddressed, the vulnerability can provide a means to …
In a Bind
Why does anyone still use this croc of shite? BIND must be well up there as one of the all-time crappiest pieces of software ever written, EVER.
I'm amazed that it has managed to stagger on as long as it has. It's not as if there are no alternatives - there's LOTS of alternatives.
"LOTS of alternatives", AC11:38?
How many is "LOTS"? Name three alternatives to BIND that are viable.
That's what I thought ...
Three alternatives to BIND
...or maybe a few more...
djbdns works very well - I've used it for years.
Viable means "capable of existence and development as an independent unit " ... djbdns is a scattered, drunken mess, with no central control. Kinda like your average 6th former. And I don't view Wikipedia as authoritative for anything.
Again, name three viable alternatives to BIND.
That's what I thought.
Uh? You dismiss wikipedia as "not authoritative", but then ask El Reg commentards for suggestions instead?
I agree djbdns is iconoclastic, with a license to match.
But why do we need 3 decent alternatives to Bind ?
1 is adequate.
Ken, re-read mine.
I knew I wouldn't get any answer from the AC ;-)
Don't get me wrong; I'm well aware that BIND is a clusterfuck. So are Apache, Sendmail, GCC, and perl. But we use 'em anyway. They are all head & shoulders over the alternatives.
Why three? Because the AC said there were "LOTS"(sic). My invitation seemed reasonable at the time ... three being fewer than "LOTS"(sic).
Seems I'm tilting at windmills again. Sometimes I wonder why I bother.
Sorry, Sarah ... on the bright side, it's Friday. Have a cuppa on me :-)
The 'net's "yellow pages"?
Careful ... MaBell might get a trifle upset if you call it that ;-)
This bug affects and older version of BIND.
Update your BIND install as it has been fixed.
Why use IXFR ?
Can't really see the need to use a DNS specific protocol to transfer zone file changes between masters and slaves. Why on earth not use Rsync over SSH ? A more general purpose data transfer approach has the benefit of being maintained by a larger user community.
This all just makes Bind more complex and buggy than it needs to be.
Err, because it works ?
It's simple both to set up and use - and it's reliable.
Rsync can do the job, but then you have to set up rsync as a service on your slaves, and write some scripts to both send the updated zone file and trigger the slave to reload it. If the slave is down or unreachable for some reason, you then have to remember the transfer failed and keep trying. So it's far from a trivial system to setup reliably.
Zone transfers ? Update zone, job done.
By default your master will send a notification to the slaves to say the zone has been changed, and the slaves can then retrieve the changes. If the slave is down or unreachable, it doesn't matter - it will pick up on the changed serial number and initiate a transfer later.
You would be correct in pointing out that there's no guaranteed transfer time, but that's the same right through the DNS system - when you make a change, it can take days to ripple through everyone's caches.
Zone transfers are also host/software agnostic. Neither masters nor slaves need know anything about the other, and they may use any format for local zone storage. At work we use BIND for our own servers, but we also buy in a service from another outfit to add resilience. I do know that they use something else, but I don't know what, and I don't need to know what - all I have to do is allow zone transfers to them.
I'm responsible for the DNS for hundreds of domains - zone transfers work, work reliably, are simple, and even our helpdesk monkeys can cope with it !
zone transfers (axfr or ixfr) are part of the dns protocol. every implementation should support them.
djbdns doesn't support zone transfers properly. then again it's a mickey mouse crock of shit that's no fucking use. the list of important dns stuff it doesn't support is long: secure dns, dynamic update, edns0, new resource record types, tcp queries, tsig, dns responses > 512 bytes, etc. nobody with dns clue uses djbdns.
using rsync or some database replication thing to move zone files is all very well. but this introduces new failure modes. it also means the dns servers are under one administrative control, which is an undesirable single point of failure. the whole idea of a secondary dns server is that it's run by somebody else in a different place from the primary server.
bind may well be complex and buggy. but so is the dns protocol.
"...users could still reach websites by using the IP address..."
They'd usually need to do this by intercepting the DNS query (e.g. by amending the HOSTS file).
If you simply type the server's IP address into a browser, the server can't know which of its sites you want (unless it hosts only one). (See HTTP 1.1 and host headers).
Some write constantly here about "virtualisation". The notion of one site per server must surely give them the vapours.
Nine posts so far...
... and nobody's yet suggested that Microsoft is implicated in this programming problem!
It hardly seems possible.
Of course not...
...it's all Steve jobs' fault.
BIND does not work properly. Use AppleTalk
Sent from my iPhone.
Who in there right mind would use M$ DNS software for mission critical servers? Of course BIND is such a kludgy POS its not much better.
Note from Internet Systems Consortium.
But how many people are using these older versions?
And are they *critical* servers?
The Internet Systems Consortium lists the latest version as 9.8.0rc1 but describes it's status as "experimental" and on release from Feb 2010.
Previous version is listed as 9.7.3 and described as "stable" and presumably without this bug, also from Feb 2010. So in *theory* a fix has existed for 1 year already.
didjabreaksomedns? I've found, when looking at this package in the past, that the installation instructions were written by one of the developers for another developer on the same project. Of course, I've also found that most FOSS documentation suffer from the same issues. The installation instructions are usually written by writer A watching developer B (on developer B's machine) run through the installation. which means that all of the really important stuff (like paths, libraries, etc) are never seen by the person writing the docs...
Who exactly is your target audience?
"the widely used Domain Name Services (DNS) software." - I think most of us know what BIND is and DNS stands for without the idiots guide
"The flaw creates a potential mechanism for miscreants to crash systems running vulnerable version of the name-to-IP-address translation software." - I think most of us know what DNS does without the idiots guide
"Authoritative name servers can be pushed into a deadlock condition when processing incremental zone transfer (IXFR) updates. These updates deal with recent changes in DNS records, with unchanged records omitted to save bandwidth and processing power." - I think most people whether IT literate or not know what incremental means without the idiots guide.
I find more and more the articles on here containing this pointless waffle to try and pad out the "story" into more than a one liner and it is lazy journalism.
Perhaps you could write your suggested one-line version of this story for us. it will, presumably, be written for those of you who are familiar with all aspects of IT.
I'm impressed by your implied breadth of knowledge, because after more than 30 years in the field, I find that I know only a small portion of it.
I run a few DNS servers (one with BIND) and I'm familiar with the subject of this article, but I'm not offended by the writer's proper attempts to make it clear to those for whom DNS is only a vague notion. If only all the articles here were written so well, the site would be much improved.
Why not apply to "The Register" for a job as journalist. We'll be interested, if not amused, to see how far you get.
There is a high risk and remotely exploitable DoS in BIND 9.7.1 and 9.7.2 - https://www.isc.org/software/bind/advisories/cve-2011-0414
The djbdns software package is a DNS implementation created by Daniel J. Bernstein due to his frustrations with repeated BIND security holes. A $1000 prize for the first person to find a privilege escalation security hole in djbdns was awarded in March 2009 to Matthew Dempsky.
hehe from 1991 till now just 1 hole...
DJB knows this shit bro'
Risk is overstated
This deadlock affects authoritative DNS servers that service queries while processing an update or sending a zone transfer. Let's see what that means in the Real World:
An authoritative (not recursive) DNS server that serves a high rate of queries AND accepts dynamic DNS updates is at risk. Small to medium sites might run DDNS on their Internet-facing servers. Large sites use MS DDNS on only internal networks, and would use Active Directory for that anyway.
An authoritative DNS server that serves a high rate of queries AND performs frequent zone transfers is at risk. A busy and frequently changing site like an ISP or hosting facility might indeed perform frequent zone updates, maybe even several per hour. Such a business should already monitor service availability and kick-start services that stop responding. They're also well equipped to set up extra nameservers and run BIND single-threaded.
DNS servers that aren't getting pounded with queries don't have to care. Nor do single-threaded servers. Or caching-only servers. DNS servers with decent monitoring will be minimally affected. Large sites with robust DNS architecture already plan to lose the occasional nameserver anyway.
It's mostly the sites with big IT requirements and small or inexperienced IT staff who need to worry. They need to worry about everything, though. And how many of them run the latest versions of BIND?
Thanks I think that answered my question on who would *really* be affected in a very thorough way.
As far as I can tell...
Either there's another major vulnerability in the wild - or else Network Solutions' root server has been hit, because there are major sites dropping off the 'net that don't even have an entry on WHOIS anymore.