Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

BIND Patches Make Bad Situation Worse

Posted by CmdrTaco on Wed Oct 15, 2003 01:04 PM
from the screwing-with-the-infrastructure dept.
The Internet
An anonymous reader writes "After .COM and .NET started using a wildcard, the internet community busily started creating patches to various pieces of software to circumvent this. It was said that this was a grave problem to the internet. Several official BIND patches were announced over the next few days. However, it turns out they weren't necessarily too well thought through. Usage of the patch unexpectedly broke at least 7 Top Level Domains, ISC announced 3 weeks later, after users started having problems. The .NAME registry has sent a formal letter to ICANN's Security and Stability Advisory Comittee to warn against using the BIND patch, which they will look into in their next meeting. The intention may have been good, but... Stability? Anyone?"
+ -
unknown
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

BIND Patches Make Bad Situation Worse 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • I thought sitefinder was dead
    • sitefinder is not dead as far as Verislime is concerned. They have only "temporarily" suspended it pending final resolution to the "technical problems" that it caused. Verislime is working hard to try and get them reinstated.
    • Verisign is playing a cat and mouse game with the US Dept of Commerce (NTIA) and ICANN.

      As I see it, Verisign is building a portfolio of legal positions that it will be using in what I belive is almost certain litigation between Verisign and ICANN and possibly involving the US Department of Commerce?

      - Verisign is trying to engender a sufficient number of statements by technical experts that it can convince a judge that there is really a technical debate and that thus the judge ought to stay out of the m
  • Write, Compile, Deploy, Test, Pass the Blame.
  • It should be noted that the bugs in the BIND patch are really Verisign's fault, not ISC's. Verisign (Network Solutions) is the company that unilaterally decided to break the .com and .net TLD servers by making them return false data, with almost no advance warning. ISC basically came up with an emergency response to support their customers, and it's unsurprising that it wasn't perfect.

    It seems appropriate for the Commerce Dept. to revoke the Verisign contract and award it to another entity that will be m

    • Not surprising, as BIND is as shown again and again a poorly designed and coded product. The fact that authors of this crap can't come up quickly with a working patch is laughable.
      • They patched quickly, and now they're in a bind.
        Ba-doom, pssh!
      • The fact that you can post at all is due to that "poorly designed and coded product".
        • The problem is that .com and .net aren't the only TLDs with evil wildcarding brokenness, just the latest and the only one to do so unilaterally without the responsible people discussing and setting policy first, and the patch didn't list quite all the TLDs that have official policies of wildcarding, just most of them. You can update it to add the others to the list, if you want, though that'll only help web browsing on port 80, and will cause you trouble if spammers try to forge mail from the other domains
    • > It should be noted that the bugs in the BIND patch are really Verisign's fault, not ISC's. Verisign (Network Solutions) is the company that unilaterally decided to break the .com and .net TLD servers by making them return false data, with almost no advance warning. ISC basically came up with an emergency response to support their customers, and it's unsurprising that it wasn't perfect.

      Preach on, brother. None of this would have happened had Verislime decided that it wanted to 0wn teh i

    • I don't necessarily think that it is a bug in the BIND patches, nor with VeriSign. Its more a configuration issue with BIND.

      The problem is that some TLDs do more than just delegation. The article mentioned the .name domain specifically.

      The problem with the BIND patch arose when people implemeting the patch decided to not allow wildcarding on all TLDs. If you used the patch to only set .com/.net to delegate-only, there wasn't a problem. If you also set .name to delegate-only, then you would have

    • *What* bugs are there in BIND due to the anti-wildcarding of DNS patches? ISC's patch provides two ways of approaching the problem; either prevent wildcarding of specific TLDs or globally ban wildcarding of TLDs and provide an exception list. Both approaches work fine, provided that the DNS admins that implement them take the time to understand the implications and approach the patch with caution instead of a jerking knee. It also clearly stated in the release notes with the patches what the issues were
  • Indeed the patches were bad. I tried the first one and it caused strange problems.
    My ISP installed another one and it is even worse: it does not return an error but it simply returns no answer for the wildcarded records.

  • Overblown (Score:5, Informative)

    by Rafke (22542) on Wednesday October 15 2003, @01:09PM (#7221756)
    This report sounds a bit overblown. A conservative named.conf would only contain:

    zone "com" { type delegation-only; };
    zone "net" { type delegation-only; };
    And that would not have the problems described.
  • BIND patches? Well I'm in a bind as to whether or not I should ask someone what in the heck this means, since I have no idea.
  • it made picking up new domains take half of forever in my experience. i have bellsouth access, still, through sheer interia. they seem to be always the last on the net to refresh dns.
  • Don't I feel all smug for letting the free world try out all that expimentanl @#$!&!!#$A$#@$!!^!!#$%!#Q [No Carrier]

  • I'll play the part of ICANN... (Score:4, Funny)

    by pergamon (4359) on Wednesday October 15 2003, @01:13PM (#7221802) Homepage
    ...in an appropriate response to .name's letter:

    Dear (dot)name,

    Since (dot)name provides such a useful and valuable service to the Internet community, we will immediately take action to address your--

    DELETED!
  • http://cr.yp.to/djbdns.html [cr.yp.to]

    It's nowhere near as difficult to set up as BIND, it's more secure than BIND, and there's a patch [tinydns.org] available to block Verisign's wildcard lookups. I've been running the patched version at home and at work since shortly after Verisign added the wildcard records and haven't had issues with any DNS queries.

    • Cool.

      Is there a way to install and run it without having to install the rest of his daemon management stuff? I like to disrupt as few things as possible when making changes to my gateway.

      Schwab

      • Is there a way to install and run it without having to install the rest of his daemon management stuff? I like to disrupt as few things as possible when making changes to my gateway.

        I don't think so...but there's no reason why you couldn't use daemontools and ucspi-tcp only with djbdns and continue using whatever else for your other services. They're also useful to have on hand if you're using qmail (as I am).

        (The only other publically-accessible services I usually run are httpd (Apache) and sshd (Op

    • It's nowhere near as difficult to set up as BIND, it's more secure than BIND, and there's a patch [tinydns.org] available to block Verisign's wildcard lookups.

      Your characterization of that patch is incorrect. It blocks A RRs which contain a specifc IPv4 address. This is not what the BIND patch does, it's far more general.

      • Your characterization of that patch is incorrect. It blocks A RRs which contain a specifc IPv4 address. This is not what the BIND patch does, it's far more general.

        How it goes about doing what it does, I think, is a minor point. For purposes of blocking sitefinder.verisign.com's IP address in response to a DNS lookup of some other domain, it gets the job done without affecting other lookups. (You can punch in http://sitefinder.verisign.com/ [verisign.com] and still go there, if that's what you want to do. It's only

    • WARNING: SAME MAKER AS QMAIL!!!

      Sorry, I prefer my DNS server package to include JUST the DNS server package, instead of trying to replace my OS with his own distro of network crap.
  • the blame for this lies squarely at verisign's feet.

  • There are two features (Score:4, Insightful)

    by Florian Weimer (88405) <fw@deneb.enyo.de> on Wednesday October 15 2003, @01:19PM (#7221892) Homepage
    The first feature (which is the one that was implemented initially) supports marking selected zones as delegation-only. This is safe, as long as VeriSign doesn't rush ahead and offers a special DNS service (with alleged super-high reliability) which involves A records directly in the COM and NET zones.

    The second feature is much more dangerous because you have to explicitly mark the TLD zones which contain records which aren't delegations--all other zones are assumed to be delegation-only. Some zones have lots of in-zone A and/or MX records (DE, for example), so you have to do some research before you can enable this feature.

    If the second feature is incorrectly configured, there will be some local disruption of service. While it might contribute slightly to the instability of the Internet, it's just a localized configuration error (mind that BIND doesn't even have a default for the configuration option), and it's not comparable to what VeriSign did on a global scale.
  • I'd almost say that if a TLD can be handled with a single wildcard, then the domain is not large enough to exist and should be a second level under something else. Even if it is just starting out, it should be run as if it were a significant participant in the net, which means delegation of specific second level entries under that tld.
  • ZIM: I helped with the DNS problem.
    Tallest: You made the DNS problem worse!
    ZIM: Worse..? or better?

  • But I thought, regression testing, hell testing at all, was a bad thing. Isn't it *good* that in the open source world, a patch gets slapped together and applied the world over, within an hour?

  • ISC at fault? Not likely. (Score:3, Insightful)

    by samj (115984) * on Wednesday October 15 2003, @01:34PM (#7222070) Homepage
    I find it strange that I be coming to the aid of the authors of BIND as a loyal djbdns user, but in this case I strongly believe it is Verisign who are to be hung, drawn and quartered over this one. The ISC were merely attempting to meet the needs of their customers. I haven't looked at why this caused breakage yet, but I wonder how much of it is related to poor configuration of the other domains? I wonder also how difficult it would be to modify the patch to sanitise only .com and .net domains? Not quite as clean, but better than, say, filtering IP numbers!

  • BIND considered harmful (Score:3, Insightful)

    by Angst Badger (8636) on Wednesday October 15 2003, @01:54PM (#7222302)
    You know, every time this buggy, insecure, over-complicated sack of crap is the source of a security hole, I make a post here to the effect that BIND is a buggy, insecure, over-complicated sack of crap and that its maintainers evidently lack either the will or the ability to fix it, and that there is more than one good alternative, including, but not limited to, djbdns.

    And every time, someone comes back and says no, it's really fixed this time, it's really finally stable, the developers really are both concerned and competent.

    I no longer bother replying anymore. Usually CERT does it for me.

    BIND must go. The only thing it does reliably is diminish the credibility of open source. (And make sendmail look good by comparison, which is no mean feat, either.)

    • Re:BIND considered harmful (Score:5, Informative)

      by Nevyn (5505) * on Wednesday October 15 2003, @02:39PM (#7222725) Homepage Journal
      there is more than one good alternative, including, but not limited to, djbdns.

      Ok, so I want a authorative and recursive DNS server. It needs to be able to be distributed via. rpms, and patchable etc. I really want it to be my vendor of choice who packages and distributes it, but I that's more of a social thing.

      So ... what do I use?

      • nsd is written with just as little regard for security as bind ... and isn't a recursive server
      • djbdns has all the legal djb problems and can't be a recursive and authoritive server
      • maradns has already had security problems and fairly major DNS bugs, uses a threaded design and has piles of needed things in the "unimplemented" section of the man page. The string ADT looks suspicious to say the least.
      • dnrd is recursive only
      • dents unmaintained, and never worked well AIUI
      • dnsmasq just does recursive queries
      • dnsproxy is just recursive
      • ens (yaku-ns) is said to be "experimental" by the author
      • pdnsd proxy only, has lots of bugs and uses a threaded design.

      So I'll use bind 9 ... and when there's a security problem I hope it's the last. However this issue doesn't count, this is a minor configuration problem that is All verisigns fault.

  • Not safe to install patches? (Score:3, Insightful)

    by dirk (87083) <dirk@one.net> on Wednesday October 15 2003, @02:20PM (#7222551) Homepage
    People are always saying it isn't safe to install MS patches because they break things, but this case surely shows that it can happen in any OS or any environment (closed and open). Where are all the people screaming about how people shouldn't install patches until they have been out at least 6 months like they do with MS patches? And doesn't this make OSS patches as dangerous, since they obviously aren't being tested?

  • Hypocrits. (Score:3, Insightful)

    by zapp (201236) on Wednesday October 15 2003, @02:27PM (#7222618)
    Wow, so the open source community released a patch that wasn't well tested, that caused problems, and probably cost some people a bit of money.

    How many times has slashdot bitched and moaned about a certain unnamed corporation doing something similar.

    Some people say "this could have been avoided if your named.conf was written properly." Yes, and most viruses and worms could be prevented if people would patch their desktops.

    So what we have:
    A patch that caused a lot of problems.
    Users that could have prevented the problem if they had known better.

    Sounds a lot like the kind of users all you eleet unix junkies diss on so often.
    • Amen to that.

      Patching bind only adds legitimacy to the actions of Virilentsin, er, Verisign. When the wicked do wrong, they are seen as evil. When you do something wrong to counter the wicked, YOU are seen as evil.

      • I don't see how patching bind adds any legitimacy to Verisign's actions. Internet protocols are built on agreement, and agreements can only be enforced by actions such as this. To do nothing is to surrender the network and it's operation to the biggest, brashest jerk around.
    • Look, it was a patch to add an option to named.conf to give an administrator the choice to force root-delegation-only.

      If ISC failed to give a proper list of domains that needed to have root-delegation in the sample configuration, then their configuration is to blame and not thier patch.

      The people over at .name are not addressing this issue properly. No formal letter was required to be sent to ICANN -- All ISC had to do was inform people that the sample configuration was invalid.
    • if [wilcarding TLD domainss is] legal then then BIND people would probably find themselves sued.

      BUNK!

      There is NOTHING that says that it is illegal for me to do post processing on DNS data that I receive from the internet. My server, my rules and if I want to block all of .biz, .cn and .edu with a patch to bind, nothing can (legally) stop me.

    • and if it's legal then then BIND people would probably find themselves sued.

      Sued for what? It's a feature you can turn on or off and it's disabled by default in the config. What's the big deal? The only reason it's there is because people wanted it. That'd be like suing Microsoft for outlook viruses.

    • I think that DNS operators should think twice before applying code that tampers with authoritive answers from root nameservers.

      The BIND patch doesn't alter the contents of the root zone (small nitpick).

      The path to follow was via ICANN, or if you still wanted to disable the sitefinder, just insert a route for the /32 in your favourite IGP and reroute the traffic to /dev/null or your ISP's site.

      Tampering with Internet routing could be viewed as damaging as dealing with DNS. Route manipulation is almost
      • zone "com" {type delegation-only;};
        zone "net" { type delegation-only;};

        So how it's breaking all these other zones is a farking mystery to me.

        There's another option which makes delegation-only the default for top-level zones, and you have to list the exceptions explicitly. This can break all zones you fail to mention and which are not delegation-only.

      • I think that DNS operators should think twice before applying code that tampers with authoritive answers from root nameservers.

        Not only do i agree with your statement, but i feel this applies equally as well to mailservers (and other facets of inet infrastructure).

        The Internet is a collaborative network, i.e. it only functions because independent nodes agree to collaborate with each other. Conversely and by consequence, it is not only unneeded but undesirable to collaborate with a node that is not coll

      • So you'll take an idiot's software that doesn't work over an asshole's software that does? Merely because you can redistribute the other?

        I dunno, man. It takes less than five minutes to compile DJBDNS on my P-pro 266. I'll take five minutes of grudging competence over BIND's half hearted tinkering every day of the week.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.