Severe bug deadlocks BIND 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 …
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.
::crickets::
That's what I thought.
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 :-)
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.
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.
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.
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.
http://www.isc.org/software/bind/versions
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...
"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.
This post has been deleted by its author
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?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
