Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
The Internet Open Source News

ISC Releases the First Look At BIND 10 172

Ethanol writes "Internet Systems Consortium, producers of BIND 9 (the most popular DNS implementation on the internet), have spent the past year working on a successor, BIND 10. It's entirely new code, redesigned and rewritten from the ground up, and now the first glimpse of what it will eventually look like has been released. 'This code is not intended for general use, and is known to be inefficient, difficult to work with, and riddled with bugs. These problems will all be fixed over the next couple of years, as functionality is added and refined, and the software matures. However, the codebase has a good framework for moving forward, and the software is capable of serving as a DNS server with significant functionality.' (Full disclosure: I work for ISC and I'm one of the engineers on the project.)"
This discussion has been archived. No new comments can be posted.

ISC Releases the First Look At BIND 10

Comments Filter:
  • DJB might agree (Score:5, Insightful)

    by bugs2squash ( 1132591 ) on Friday March 19, 2010 @09:28PM (#31546748)
    This code is not intended for general use, and is known to be inefficient, difficult to work with, and riddled with bugs Could apply to any version of BIND
    • Re: (Score:3, Informative)

      by Vellmont ( 569020 )

      Right, much better to write code under some bizarre license, ignore it for years forcing people to distribute patches unto patches, then 6 years later finally realize you're not maintaining the code and never will and finally release it under a sane persons license.

      • Enforcing your copyright over original content is a bizarre license scheme? Patching considered bad? Actually doing something you promised is wrong? Public Domain is a license?

        Wow, you really have drunk the DJB haters kool-aid.


        • Enforcing your copyright over original content is a bizarre license scheme?

          Releasing source code, but refusing to allow anyone to modify it and not maintaining it yourself is rather bizarre, yes.


          Patching considered bad?

          Yes. Forcing people that actually DO want to maintain your code to do so by collecting together a series of patches and apply them to your original code is rather poor software distribution and maintenance.

          Actually doing something you promised is wrong?

          I never said what he did was "wrong", b

    • Could apply to any version of BIND.

      That was my first thought, having given up on BIND years ago in favor of the vastly more efficient, user-friendly, and -- most importantly -- bug free djbdns.

      After all this time, the best they can do is something they themselves admit is crap, and they plan to take years to make it less crappy? That's really stunning, and not in a good way. We are, after all, talking about a key/value store. Thank goodness they didn't try something that wasn't appallingly well-understood already.

      • by Ant P. ( 974313 )

        What definition of "bug free" are you using there? Is it the one where DJB pretends bugs don't exist for years by handwaving them as user error? And how is a piece of software user-friendly or efficient when you have to install the author's NIH-syndrome init and xinetd replacements just to use it?

        • by Otterley ( 29945 )

          I'm sorry, which version of xinetd and init tracks both the daemon and its logger daemon as a unit and ensures they are always piped together?

        • Is it the one where DJB pretends bugs don't exist for years by handwaving them as user error?

          Do you have a citation for that?

          I know of exactly one DJBDNS bug:
          djbdns<=1.05 lets AXFRed subdomains overwrite domains [gmane.org]

          Afaik that bug was acknowledged (and paid for) rather quickly.
          As a happy djbdns user I'd be curious to learn about other bugs that I've missed?

  • I thought bind 9 was a rewrite from scratch? They did such a crappy job, they have to do it again for 10?
    • I thought bind 9 was a rewrite from scratch? They did such a crappy job, they have to do it again for 10?

      Yes.

      Next question?

  • Yes, yes, we realize djbdns is far more secure. And that DJB is ornery.

    Instead of peppering the whole forum with "djbdns is great", just respond to this thread.

    Frist!

  • ...if you're doing it to end up with new code that is "inefficient, difficult to work with, and riddled with bugs"?

    Was the original code too efficient, well-commented and well-tested and they couldn't live with that?

    • Re: (Score:3, Funny)

      by Tackhead ( 54550 )

      What's the point of a rewrite...

      ...if you're doing it to end up with new code that is "inefficient, difficult to work with, and riddled with bugs"?

      Why, backwards-compatibility with BIND 8 and 9, of course!

  • BIND is thirty years old and a core piece of Internet infrastructure. That a completely new design and re-write of such a fundamentally important piece of software is "inefficient, difficult to work with, and riddled with bugs" highlights the continuing immaturity of the computer software industry.

    This should be an embarrassment to every software designer, Google, IBM, and Microsoft should be screaming out how this is making the entire industry look bad.

    Wouldn't this be an ideal target for test driven deve

    • by PCM2 ( 4486 ) on Friday March 19, 2010 @11:06PM (#31547246) Homepage

      BIND is thirty years old and a core piece of Internet infrastructure.

      Actually, BIND 9 -- "the most popular DNS implementation on the Internet," according to the submitter -- is merely 10 years old, and was itself a major rewrite of BIND 8. BIND 8 was only declared "end of life" in 2007.

      That a completely new design and re-write of such a fundamentally important piece of software is "inefficient, difficult to work with, and riddled with bugs" highlights the continuing immaturity of the computer software industry.

      Really. So the fact that a software developer plans to take "the next couple of years" (again, re: the submitter) to complete a software project is symptomatic of the total failure of an entire industry. Interesting perspective. Thanks for that.

      • Mod Parent up. Seriously, they're basically in alpha here and are opening up for help from the community. They're obviously testing their code like crazy, that's how they know their issues. Why is everyone pissed that a bunch of developers are giving their time to develop a free project that is going to make the internet more reliable and safe in the end. Too many armchair developers in here. "Years! I could rewrite Bind in my sleep with one arm tied behind my back!"
      • by phoebe ( 196531 )

        Really. So the fact that a software developer plans to take "the next couple of years" (again, re: the submitter) to complete a software project is symptomatic of the total failure of an entire industry. Interesting perspective. Thanks for that.

        Are you really defending the current development shortcomings of BIND 10 with the article author's inability to elucidate software engineering? Not at all continuing another symptomatic issue of the software industry.

    • by dkf ( 304284 )

      Wouldn't this be an ideal target for test driven development

      Depends on the difficulty of running meaningful tests. Moreover, testing an application architecture is rather more difficult than testing individual units that plug into such an architecture. (One of the goals of an architecture ought to be that it allows the testing of modules plugged into it without doing a full run of the whole mess, i.e., that it enables TDD. Getting to that stage isn't trivial; if you think it is, that's probably because you've never tried writing one for real, and have just been leve

  • So instead of 1 daemon I'll now get 3-4 running daemons interacting in strange ways? Thanks, that's exactly what I need.

    How about scriptability and/or custom resolvers? Nope, none of this.

    Oh well, probably I should switch to DJBDns. It also uses a ton of daemons, but at least it's architectured properly.

    • "Architecture" is a noun. "Design" is a verb (or a noun). There's no "architectured".

      • We've just witnessed the birth of a new buzz word.

      • by brusk ( 135896 )

        The OED begs to differ. It has an entry for "architecture" as a verb, and quotes some major English writers as sources.

        To design as architect.

        a1821 KEATS Fingal's Cave (D.) This was architectur'd thus By the great Oceanus. 1893 Strand Mag. VI. 268/1 The house..was architectured by John Belcher from plans by its owner. 1939 AUDEN & ISHERWOOD Journey to War 120 The slope has been architectured into terraces.

      • by kybred ( 795293 )

        "Architecture" is a noun. "Design" is a verb (or a noun). There's no "architectured".

        I thought any noun could be verbed.

  • Most of the trouble with BIND stems from the fact that it's a database app with its own database implementation. BIND10 uses SQLite, which already works. That ought to simplify the thing enormously.

    Building in a web server for BIND administration is probably the source of much of the complexity.

    • It would be good if it allowed the use of a generic back-end. I do not want to administer a system with multiple SQl database systems. I want to standardise on one and use it for all my server data needs. The days of using different databses for email, DNS, authentication, web applications and more should by now be a thing of the past.
      • Why should everything use the same database? A file system is a type of database. SQL is another. Each has it's own purpose. SQLite is contained in a file anyways. A separate database server wouldn't have to be setup for this.

      • The design for BIND 10 allows for generic back-ends. We implemented SQLite as the first one, simply because it was the easiest. One of our early goals for the second year of development is to support additional database back-ends (we call them "data sources"), including MySQL, PostgreSQL, and an in-memory 'database' (for performance-critical environments).

        In the end we'll also support more exotic back-ends, like BDB, LDAP, directories, and possibly even the tinydns data format.

        [ disclaimer - I am the BIND 1

    • First of all I agree, building a webserver for something as critically important as a DNS resolver is completely asshat if that is what they are doing.

      But I disagree with you. Any dns resolver should be as complete an island as possible, depending on as little as possible, the fewer other subsystems it has to rely on the less points of failure there are.

      This should be a very straight forward hash table, loaded from into ram, all entries mapped to either upper or lower case and then the queries hashed and t

    • Ummm...this "database" isn't relational, there's no inner joins or anything like that (at least there shouldn't be), it's a one-to-one lookup (text string to IP address).

      It's not the sort of thing which takes ten revisions just to get to a state where it's "inefficient, difficult to work with, and riddled with bugs".

    • by Skapare ( 16644 )

      DNS is not naturally a data structure suitable for relational databases. Any SQL is a bad choice because SQL is a bad choice. Something like Berkeley DB might have been better, or perhaps some of these [wikipedia.org].

      • They could've learned from how fast one of their detractors' systems work -- tinydns uses a BDB-like database system for storage as well, and is extremely fast. I think there are even more problems with how BIND handles memory management and historically doesn't understand that resolving and serving are completely different concepts.

  • These problems will all be fixed over the next couple of years

    I admit complete ignorance in this area, so please educate me if this sounds stupid -- but surely writing a DNS server can't be that hard?

    • Are you kidding? It is software written by committee which always sucks. What other examples, try http, css, xhtml, xml, etc. etc. the list is endless.

      Additionally the entire DNS system is one pile of legacy crap with a on of kludges to support this or that interest group.

      Just be glad there are alternatives.

      And you are correct, it should just be a database that responds to a very simple query, here is the domain name, here is the record type, return the IP address.

      But it is far more then that. Depending

    • by Ethanol ( 176321 )

      surely writing a DNS server can't be that hard?

      Try it some time! It's fun! I can even refer you to an ongoing open-source project that you can contribute to, if you like! :)

      To give a rough idea of scale, BIND 9 has about half a million lines of C code, and the first release took a couple of years to write.

      (BIND 10, in its current minimal and unfinished state, is about 40,000 lines of C++, and 10,000 lines of python.)

    • by Arimus ( 198136 )

      Ok, if you want it to simply carry out lookups and return answers then fair enough.

      If how ever you want to do more a quick set of things to consider (this is purely off the top of my head)

      0. Security
      1. Validation of the various record types
      2. Caching of lookups
      3. Proper use of the dns heirarchy
      4. Security
      5. Should be easy to manage
      6. Zone transfers
      7. Speed... slow dns will be no use to man nor beast
      8. Security
      9. Compliant to the relevant RFC's
      10. Dynamic DNS support

      Ok, I've put security in a few times but i

  • Which major features in bind9 are going to be thrown out (and stay out even beyond beta) for bind10?

  • Seriously? The idea is to go for yet another rewrite? And it sounds like it's going to be a half-assed database backing (SQLite? Is this right?)? Why not just move to an abstracted storage backend, and let the admin pick what works for him (or write his own backend plugin)? You know, like PowerDNS has been doing for awhile now. Seriously, guys, let's just stop using BIND and move to a better nameserver; it really seems like ISC is going to be rewriting BIND until the heat death of the universe.

  • 'This code is not intended for general use, and is known to be inefficient, difficult to work with, and riddled with bugs.'

    If this is indeed a true statement this code is doomed and should be thrown away right now.

    If they don't do it right from the start they will spend the rest of forever turd-polishing.

  • There's no mention of the bloat of BIND9. Will it be carried into BIND10? Are they reimplementing all the bloat from the ground up?

    I'll stick with NSD [nlnetlabs.nl] and Unbound [unbound.net].

    • Well they're probably not going to cull features and probably going to design more efficiently, but it raises the question - what's better about this rewrite than, say, unbound, with several years' head-start in the rewrite race?

  • Is there still a lot of Bind users out there?

    NSD and Unbound are way better, but they aren't the only worthy alternatives.

  • DNS for IPv6 will have to know a whole lot more about which address to dish out 1st than current versions of BIND and I'm not sure how long it will take to get a good handle on that problem.

    I'm old school so I like dedicated hardware for my DNS servers. I run bsd jails that don't have anything but bind running. I used to run solaris servers that had init running named running off a read only scsi disk that was shared with another server. Init ran another program that would mount the file system read only,

    • by TheLink ( 130905 )
      > I run bsd jails that don't have anything but bind running. <etc snipped>

      The reason why anyone would need to do all that was both BIND4 and BIND8 were pieces of crap. BIND9 was a bit better but still...

      Anyway, if it's a different team doing BIND10, maybe they might produce something better.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (7) Well, it's an excellent idea, but it would make the compilers too hard to write.

Working...