Slashdot Mirror

← Back to Stories (view on slashdot.org)

Open Source BIND Alternative Launches

Posted by kdawson on from the ties-that-bind dept.

bednarz writes "A group of experts on Tuesday released an open source alternative to the BIND DNS server. The new software — dubbed Unbound 1.0 — is a recursive DNS server. From its first prototype in 2004, Unbound was designed to be a faster, more secure replacement for BIND. Unbound supports DNS security extensions (DNSSEC), which authenticate DNS lookups but are not yet widely deployed because they rely on a public key infrastructure. Unbound was released to open source developers by NLnet Labs, VeriSign, Nominet and Kirei."

14 of 162 comments (clear)

  1. Powerdns anyone? by superskippy · · Score: 3, Interesting

    We use powerdns_recursor which seems very similar, and is very good.

    1. Re:Powerdns anyone? by num42 · · Score: 4, Interesting

      When we - which you can read as 'i' btw. ;-) - were still on BIND9.(3|4) i had crashing named processes at least once a day, never had a single crash of a pdns_recursor process that wasn't my own fault until this day. Just as a funny sidenote i thought i should share with you what happened when i grabbed myself a heart and switched from BIND8 to BIND9 one day. ;-) This was the result: http://zaphods.net/~zaphodb/high-performance-bind9.html
      --
      "morning is a state of mind ;)"
  2. Are we supposed to trust.. by bleh-of-the-huns · · Score: 5, Interesting

    Anything with Verisign's named attached to it?

    --
    I came, I conquered, I coredumped
  3. Re:IE6 by zn0k · · Score: 2, Interesting

    They are the guys that wrote and support nsd (http://www.nlnetlabs.nl/nsd/), the software used on at least 2 root servers (k.root-servers.org and l.root-servers.org).

    Those are some mighty fine credentials.

  4. ldapdns by morgan_greywolf · · Score: 3, Interesting

    I use a perhaps not-well-known alternative called ldapdns, which used to be based on the DJBDNS code. It gets its DNS information from LDAP, which is very, very nice -- I can make a change in LDAP and the change is instant as opposed to making a change to the BIND stuff, which I then have to restart BIND, etc.

    --
    My blog
  5. Re:It's not... by value_added · · Score: 4, Interesting

    I've only had a quick glance, but it appears you're correct.

    Seems this is a first: both the submission and the article are absurdly wrong.

  6. Feh.... by Ritz_Just_Ritz · · Score: 2, Interesting

    Dan Bernstein's public demeanor makes Theo de Raadt look like Miss Manners. I'll stick with bind, thanks. It just plain works and I'm not stuck with an angry maintainer for updates. :D

  7. DNS is a big problem and it's getting bigger by mseeger · · Score: 3, Interesting
    Hi,

    DNS is one of the bottlenecks to come. For nearly every ISP, DNS traffic grows faster than the overall traffic.

    i'm doing a lot of consulting for large ISPs on DNS problems. BIND is good for small and medium ISPs but bad for large ones (as resolver, as primary or secondary nameserver).

    It doesn't work very well with Cache above 1GB and the multithreading is not very efficent. Startup (for servers with 100K zones) is very slow, restart (after changing the configuration) is risky if you decreased the number of masters for a secondary zone (core dump). The readability of the code is far from perfect and it doesn't seperate different functions very well (e.g. you cannot easily replace the caching algorithm). The handling of slow or dead servers could be improved too...

    So, i personaly welcome the new contender in the OSS nameserver arena ;-). Let the games begin...

    The best results (up today) i got with Nominum ANS and CNS. It's neither FOSS nor cheap but really, really fast. We replaced at one customer 4 overloaded BIND systems (3 Ghz Dual Xeon, 4GB RAM, 2 BIND processes per system) with CNS on the same hardware (but only 2 systems) and the load barely reached 10%.

    Sincerely yours, Martin

    1. Re:DNS is a big problem and it's getting bigger by mseeger · · Score: 3, Interesting
      Hi,

      If DNS traffic is your bottleneck, you don't have a bottleneck.

      Sorry, you missunderstood me. I didn't say DNS traffic is a bottleneck. I said DNS is the bottleneck and i meant the number of requests.

      Why do we get so many more DNS requests today:

      • Anti-SPAM-Systems use DNS to make their decisions.. A SPAM mail may cause several DNS requests on the receiving side.
      • Everyone and his dog is using small firewalls which regularly do a reverse DNS query per incoming connection. A new worm (even without any infection) can cause millions of DNS requests for a large ISP.
      • Web-Sites are heavily loaded with images/adds from other servers. This means a dozen or more DNS requests for a singe web page.
      • etc...

      While DNS is still a small percentage of the overall traffic, it can be a bottleneck. I slow caching nameserver (if its overloaded or as inefficent as a BIND in a large ISP environment) can severely decrease the "speed experience" of a fast DSL line. If you have an average answer time of 300ms for a DNS request from a caching nameserver, it really hurts. Just believe me...

      Iw ould agree that BIND nearly never is your biggest problem. But for big ISP it can be a big problem anyway. A lot of them already dumped BIND.

      Regards, Martin

    2. Re:DNS is a big problem and it's getting bigger by mseeger · · Score: 5, Interesting
      Hi, If bind is your problem, your doing it wrong. Root F runs bind and I'm betting it does far more than your trivially small organisation with only 100k zones. Root F and its mirrors answer somewhere in excess of 1/3 of all top level queries.

      If you run BIND with 100K zones, it takes quite some time to come up and starts answering queries. If you do a reload, it has a dead time in between. Try it...As secondary it has bugs (for more than 12 months now) that may crash it. I just had customer who paid a lot of money to get it fixed by an external company. Of course the fix was sent to the BIND maintainers.

      As always, you can work around the problem. E.g. for the startup/reload problem you can use multiple server and load balancers, switch ip addresses, pull a rabbit out of your hat... It's all possible. The question is always: is it cost efficent? If you have to adopt your procedures to work with BIND, you may do so. A lot of companys prefer paying money and adopt the software to their procdures. Both ways may work.

      BIND doesn't have a performance problem as primary nameserver or secondary nameserver. It has a performance problem as a caching nameserver and a severe one. This is why i'm happy about Unbound.

      At last: Some root nameservers should always run BIND. We need at huge diversity of software for root server, even if it creates pains. Just for security reasons....

      Regards, Martin

      Disclaimer: I don't hate BIND, i don't love specific comercial products. The decision is always based on a lot of parameters. Price, FOSS vs. comercial, hardware or software based solution, Know How of the administrators... All goes into one pot. There is no one size fits all.

  8. BIND isn't Open Source? by hitech69 · · Score: 3, Interesting

    Am I missing something, when did BIND not qualify as Open Source?

  9. Re:Java based DNS server? by lseltzer · · Score: 2, Interesting

    Only slightly on point, Unbound was originally prototyped in Java, but rewritten in C.

  10. Re:It's not... by Omnifarious · · Score: 4, Interesting

    Perhaps most pieces of DNS software can do both. But actual DNS installations should not be configured that way. In fact, I've seen a rise in DNS cache poisoning attempts against my authoritative DNS server.

    --
    Need a Python, C++, Unix, Linux develop
  11. Re:djbdns by profplump · · Score: 2, Interesting

    I generally agree, and have recently switched from qmail-ldap to postfix myself. But keep the historical context in mind. Back in say 1998, postfix wasn't an option (version 1.0 in 2001), and qmail was waaaaaay better than sendmail.

    Also keep in mind that qmail proper is 10 years old, and things like RFC 2822 didn't exist when it was written. qmail-ldap provides a much more modern view on email -- including all the goodies like TLS/SSL support, pre-acceptance address verification, etc. -- to the same basic structure.