Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
The Internet

BIND Patches Make Bad Situation Worse 280

Posted by CmdrTaco from the screwing-with-the-infrastructure dept.
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?"
This discussion has been archived. No new comments can be posted.

BIND Patches Make Bad Situation Worse More

BIND Patches Make Bad Situation Worse

Comments Filter:
  • 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
      • But surely Verisign must know by now that playing hardball in this matter will simply result in the net working around the issue ("The more you tighten your grip, Tarkin, the more star systems will slip through your fingers" :) ). If it has to be through changes to BIND, that's what it will be -- I'm sure the BIND people will get everything right eventually. Or the next generation of popup blockers will override sitefinder (maybe getting their suggestions while stripping the ads?). If nothing else, ISP's
  • Yes. .io and .sz.
    • And CX for that matter. Anyway, stability, security and Vixie? Give me an effing break. The man has great ideas, but god forbid him from implementing them or even directing the implementation. If you want an example, take the source of dig out of bind 8 or even 4.9 and try to read it. 40K of a single C file. Bloody hell... It is HIS handywork. His name is in the copyright. Behold (I already did once upon a time).
  • 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".
        • There are other DNS servers, some of them even work. And one could post here just as well if BIND would have been implemented correctly, preferrably from the very beginning, or at least with the BIND 9 "complete rewrite" which doesn't seem to have helped much so far.

          Then again, this issue has nothing to do whatsoever with BINDs rotten codebase. Normally you can be pretty sure that they get the DNS part right and only fuck up in the C implementation part, this time it's the other way around.

    • > 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

    • Re:Not ISC's fault (Score:3, Insightful)

      by rufey ( 683902 )
      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

    • Re:Not ISC's fault (Score:3, Insightful)

      by Zocalo ( 252965 )
      *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

      • *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.

        Boy, I wish my mod points hadn't expired. I'll quote this portion again;

        provid

  • 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.
    • The problem is the root-delegation-only option. ISPs are using this as an easy way of doing the above. The problem is that then you have to explicitly name all TLD's that are allowed to do things other than delegation.

      The .name letter asks for the root-delegation-only option to be removed (so that delegation-only must be used to explicitly name those TLDs for which sitefinder like stuff is disabled.)

      Personally I agree with that much.
    • I agree. That's all I put in mine, because I generally don't like trying to fix things that aren't broken on production servers.
    • That's not the problem. There's another option, "root-delegation-only exclude", which makes all the DNS roots (except the list provided) delegation-only. The problem is, they left out a few common registries that are *not* delegation only when they first released the patch for that option.

      Honestly, though, I do agree that the debate is overblown...change the defaults, and move on. Not using insurance against Verisign's nastiness because someone left a zone off a default list (since fixed), is crazy.
    • And that would not have the problems described.

      Quite frankly, a million sysadmins could configure themselves as the authority over '.', 'com', 'net', or any domain of their choosing and it would similarly break thousands (millions) of connections.

      Misconfiguration is hardly the fault of the software package. It's not BIND's responsibility to inform you that you're not the proud owner of ".com" and that it won't start until you smarten up.

    • I say there is an easier way to fix this. I say we all start a DDOS attack on non existant web sites. I mean, who is going to sue you for flooding www.aafefasa.com if www.aafefasa.com doesn't exist? Technically, you aren't even denying service since the freaking domain doesn't exist, right? :D
  • 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!

  • Sounds like a good reason to use djbdns instead (Score:4, Interesting)

    by ncc74656 ( 45571 ) <scott@alfter.us> on Wednesday October 15, 2003 @01:13PM (#7221803) Homepage Journal
    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

    • 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.
      • What are you talking about? ucspi is only needed if you want axfr. Both dnscache and tinydns do not require either ucspi or daemontools (although both are way better and more convenient/easier to use than inetd and init). If you don't like your services supervised with daemontools, then try runit, minit, and a hoopla of others. They're great timesavers, and make your systems more available.
    • It would be nice if the license got clarified on this app so that it could be shipped with distributions. (Or at least a clarification so that vendors will be more willing to include it.)

      • It would be nice if the license got clarified on this app so that it could be shipped with distributions.

        The last few times I've installed djbdns, all I've had to do was type in emerge djbdns, go away for a few minutes, come back, and start adding data.

        Last time I checked, DJB's usual license says you can't distribute modified versions without prior approval. BFD. Distribute an unmodified tarball, along with whatever patches you want to apply, and set up your install script to patch, compile, and in

        • The last few times I've installed djbdns, all I've had to do was type in emerge djbdns, go away for a few minutes, come back, and start adding data.

          emerge: Bad command or file name. Installing and configuring Gentoo Linux on a production system is not always an option.

          Distribute an unmodified tarball, along with whatever patches you want to apply

          Applying a patch to a copyrighted program prepares a derivative work of that program. Will it be lawful under all nations' copyright laws for end users of

          • The last few times I've installed djbdns, all I've had to do was type in

            emerge djbdns, go away for a few minutes, come back, and start adding data.

            emerge: Bad command or file name. Installing and configuring Gentoo Linux on a production system is not always an option.

            So it ends up being a bit more work by not having the build process automated if you're stuck running Redh*t/SuSE/etc. For someone other than a paper MCSE, it shouldn't be a problem.

            Distribute an unmodified tarball, along with what

    • ...there's a patch available to block Verisign's wildcard lookups.

      Great, I'm sure some packager I trust will build a version of djbdns with the patch included so I can just install it and go...

      Oh, wait, that will never happen be cause DJB's license forbids it.

      Feh.

      Of course, it's not really relevant since the problem isn't with BIND's patch, it's with users mis-configuring the new option that the BIND patch provides.

      The BIND patch is way more flexible, the djbdns patch requires you to keep updating

    • Compared to Bind 8, or 9? Bind 9 has a pretty good security record, being a complete rewrite of previous versions. Its pretty easy to set up, it, especially since, unlike DJBDNS, its open source, so you can get binary packages that install into standard FHS locations and work with the other applications on your system.
  • 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 ) * <samj@samj.net> 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!
    • "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."

      Exactly. Verisign deliberately broke the systems of everyone using the .com and .net domains, and peoples' reaction to try and stem the resulting flows of additional spam, lost emails, broken applications, and unnecessary traffic have broken some other domains.

      Yet Verisign, still unrepentant, waited weeks to

  • 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.)
    • Brilliant troll, sir.

    • 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,

      Those statements are true of BIND 8. I challenge you to provide convincing support for any of these:

      • buggy
      • insecure
      • its maintainers evidently lack either the will or the ability to fix it

      with regard to BIND 9.

      Whether or not 9's over-complicated is entirely a judgement call, and not really a metric worthy of objective discussion.

      • I'm not going to argue about whether BIND version N is buggy, insecure, hard to configure but easier to configure than sendmail, or an over-complicated sack of crap, but -

        the reason we still use it after 15+ years is because its maintainers evidently DO have the will to maintain it, in spite of all the features that people keep wanting added, and the reason that 48 hours after Verisign broke the DNS system you could install a BIND patch is ALSO because its maintainers have the will and ability to fix it.

    • 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.

      • Although I'll agree with djb's annoying licensing issues, why do you need a recursive cache and an authoritive server on the same IP? It is simple to set them up on seperate IPs (even on the same machine) and well documented.
      • The right thing to do is to run two services one for DNS cache, the other as your authoritative nameserver. Even BIND idiots recommend to run BIND this way.

    • 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.

      You may or may not be correct. However, I'm left wondering why you posted your opinion in connection with this story, considering that

    • The subject at issue is not a security hole.
      The patches allow -- wowee -- an administrator
      to configure BIND in such a way that some TLDs
      cease to function.

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


      So, uhh.... you didn't write this?

  • 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.
    • Please, "Linux junkies" or better still, "OSS junkies." Most Unix professionals understand that OSS is neither a holy grail or guarantee of perfect software everytime.

      Open software is an essential part of the market, but it's not magic. Bad programmers will still write bad code, and lazy reviewers will still miss bugs.
  • Hi,

    some may have faced the same decision i did: Either you spend hours and hours in investigations if the sitefinder shit breaks some script of yours or your ancestors, or you take the risk applying a patch that can't be tested very throughly. Neither choice really seemed inviting.

    As it turned out, the patch wasn't working very well (increased memory usage, was an unofficial patch for 8.4.somewhat) and we had a malfunctioning debug script.

    Regards, Martin

  • BIND 9 still doesn't have all the functionality of BIND 8 (which is one reason a lot of people haven't switched). The IPv6 reverse-lookup records are painful to the eyes. I'm not convinced DNSSEC is fully working.

    Since BIND doesn't support dynamic updates, it doesn't work well with DHCP, Mobile IP, Ad-Hoc IP or any other environment in which dynamic updates are, well, essential. (Incidently, as IPv6 mandates Mobile IP support, BIND cannot be considered IPv6-compliant.)

    The API changes with BIND 9 meant t

    • Since BIND doesn't support dynamic updates, it doesn't work well with DHCP....

      That's news to me. On my Linux box, the DHCP server is dynamically updating the BIND 9 server with no problems.
  • Paul Vixie releasing untested, buggy software?

    You're kidding!

    - A.P.
  • The problem isn't the code, it's just data. The BIND patch had a list of top-level domains, like .museum, for which wildcarding is ok, and otherwise it blocks them. The problem is that Vixie missed some of the domains that do wildcarding - so just add the extra domains to the list. The patch works just fine, and seems to be stable. Furthermore, Vixie (who discussed this at a talk at Stanford as week or so ago) says that the patch *does* violate strict interpretation of DNS standards, whereas Verisign's
  • Every time there's a patch to BIND, somebody spouts off about DJB's "great stuff"...

    As much of the value of software is the LICENSE under which it is release as the source code itself.

    If M$ didn't sell binary copies of their Windows O/S, it would have no value at all.

    DJB's tools might be great for some people, and it might even become a standard for the Internet, but as long as DJB's license is so restrictive as to prevent Red Hat from releasing a QMail RPM, its value is greatly diminished. Despite the a

Slashdot Top Deals

How many Unix hacks does it take to change a light bulb? Let's see, can you use a shell script for that or does it need a C program?

Close