DNS again: a clarification

There are a few points I’d like to clarify regarding my previous post about DNS in FreeBSD 10.

Some people were very quick to latch on to it and claim that “FreeBSD announced that Unbound and LNDS will replace BIND as the system’s DNS resolver” or words to that effect. This is, at best, a misunderstanding.

First of all: this is my personal blog. I speak only for myself, not for the FreeBSD project. I participated in the discussions and decision-making and did most of the work related to the switch, but I am neither a leader of nor a spokesperson for the project. As the current Security Officer, I sometimes speak on behalf of the project in security matters, but this is not one of those times. If this had been an official announcement, it would have been posted on the project’s website and / or on the freebsd-announce mailing list, not on my blog (or anybody else’s).

Second: BIND is a very mature, complex and versatile piece of software which implements pretty much every aspect of the DNS protocol and related standards, and is at the forefront of its field. It is developed and maintained by the Internet Systems Consortium, which is a major actor in the development and standardization of the DNS protocol. If you need an authoritative nameserver, or a caching resolver for a large and complex network, BIND is the natural choice. I use it myself, both privately and at work (note: I do not speak for the University of Oslo either). Most of the root servers run BIND. Unbound, on the other hand, is primarily a caching (recursing or forwarding) resolver. Although it has limited support for local zones (serving A, AAAA and PTR records only), which is mostly useful for overlaying information about machines on your RFC1918 SOHO network on top of the data served by a “real” nameserver, it is not capable of running as a full-fledged authoritative nameserver.

Third: due to its key role in Internet infrastructure, BIND is one of the most intensely scrutinized pieces of software. A tiny flaw in BIND can have major consequences for the Internet as a whole. The number and frequency of BIND-related security advisories are more a reflection of its importance than of its quality. Frankly, if you want to talk about code quality and BIND vs LDNS / Unbound… let’s just say that people who live in glass houses shouldn’t throw stones.

Fourth: FreeBSD has shipped with BIND for many years, but BIND was never the FreeBSD’s “system resolver” except in the loosest definition of the term. Most applications that need to perform DNS lookups use either gethostbyname(3) or, preferably, getaddrinfo(3), which are implemented entirely in libc (with code that goes back at least 25 years); I haven’t touched that code, and I don’t plan to. A few applications—notably host(1) and dig(1), which are actually part of BIND—need more fine-grained control over the queries they send and more details about the answers they receive, and use the BIND lightweight resolver library (lwres(3)); these applications have either been replaced by LDNS-based equivalents or deprecated. It is, of course, entirely possible to set up BIND as a local caching resolver; in fact, the default configuration we ship is perfectly suited to that purpose. It’s a little bit more work if you want it to forward rather than recurse—especially on a laptop or a broadband connection without a fixed IP, because you have to set up the resolvconf(8) magic yourself—but it’s not rocket surgery.

Fifth: a major part of the decision to remove BIND, which I stupidly forgot to mention, is that BIND 10 has been completely rewritten in C++ and Python. Importing Python into the base system is out of the question, so we would have been forced to switch sooner or later: at the earliest when users started complaining that we shipped an outdated version, and at the latest when the ISC discontinued BIND 9 entirely.

Sixth: Unbound is not a long-term solution. We needed a caching resolver for FreeBSD 10 and decided to use Unbound because it’s fairly mature and we know it well, but it is a stopgap measure to address the DNSSEC issue while we work on a long-term solution. For FreeBSD 11, we see DNS as only one of several services provided by the Capsicum service daemon called Casper; no decision has yet been made as to which validating resolver library Casper will use as its back-end. In any case, we will continue to provide both authoritative nameserver daemons and caching resolver daemons, such as BIND, NSD, Unbound DNSMasq etc. through the ports system, which can provide better support, access to newer versions, and faster updates than we can in the base system.

Finally, I should add that the ISC has supported the FreeBSD project for many years, both directly and indirectly. Although I haven’t been directly involved in that part of the project, I’m very grateful for their contribution and bear no ill will against them, and I was very unhappy to see my previous post misconstrued as an attack against BIND and the ISC.

8 thoughts on “DNS again: a clarification”

  1. Several root servers (l and k I believe) run NSD. It’s a good choice along with unbound and it keeps the resolver and the authorative DNS separate.

    BIND 9 might be mature, but since BIND 10 has been rewritten from scratch its maturity has yet to be proved in production. I for one would rather have BIND in the ports collection only.

    Another part of the base system I’d like to see gone into ports is Sendmail, although I am not aware of any BSD licensed replacement other than OpenSMTPD to go into the base system.

  2. There is some confusion about BIND 10. The naming and the number suggest that BIND 10 is “the next version after BIND 9.9”. However, that is not the case. BIND 10 is a product of its own right, and will not replace BIND 9 (not in a foreseeable future). BIND 10 is important, as it solves challenges that some DNS operators will experience in the future (scalability, modularity). I work with unbound, BIND 9 and BIND 10. Using unbound in FreeBSD as a resolver is a good choice. Please don’t misjudge BIND 10 without taking a closer look and understanding the design decisions made.

    1. I’m not sure why you think I’ve “misjudged” BIND 10. I have no opinion of BIND 10 whatsoever, and I haven’t said a word about it except to mention that it is partly implemented in Python and can therefore not be imported into the FreeBSD base system.

  3. For those of us who currently run major DNS servers on FreeBSD, it appears that the move to FreeBSD 10 will require us to do things differently with respect to chroot and the location of our configuration files. In addition, I like drill, but I like dig better, and dig often has new options that better support DNSSEC troubleshooting (note that I have used the ldns tools for years as well). This leads me to a few questions:

    Will there be (or is there) a NO_UNBOUND option for /etc/make.conf? Frankly, I’d rather not build either in the base and instead have ports install my preferred package in the base system. That said…

    Why is REPLACE_BASE going away as an option for BIND? Sure, one can set PREFIX=/ on the command line, but this makes portmaster and other tools harder to use. Is there an option to keep the PREFIX=/ persistent so that I can install the BIND tools in the base system?

    Is there a way to maintain chroot support for BIND in FreeBSD 10 or do we have to roll our own? Keep in mind that many of us did roll our own back in the 3.x – 4.x days and were quite happy to change to the “FreeBSD way” when FreeBSD set up its own chroot mechanism for BIND.

    1. 1. Yes, there is a WITHOUT_UNBOUND option; see src.conf(5).

      2. REPLACE_BASE only makes sense when there is already a version of BIND (or OpenSSL or whatever) in base which you want to replace (hence the name).

      3. You’ll have to ask the BIND port maintainer (Erwin Lansing)

  4. Why is Unbound not a long-term solution (i.e., FreeBSD 11)? Is it a security, code base, integration, or policy issue?

    I’m not familiar with FreeBSD and Capsicum. I use OpenBSD, which has moved Unbound and NSD into the base system. I’m just curious as to why FreeBSD will not be doing the same for the long-term. What’s the vision?

    1. Capsicum is FreeBSD’s capability framework. Think of it as kernel-assisted privilege separation. Casper is a daemon which provides services to sandboxed processes. Without Casper, the privileged parent of a sandboxed process that needs to perform DNS lookups would have to explicitly grant it permission to read /etc/resolv.conf and /etc/hosts, open a UDP socket, send one or more UDP packets, listen for return packets, etc. Instead, it can open a connection to Casper, tell it to allow DNS lookups, then pass that connection to the unprivileged child. Same thing for user identity lookups (the unprivileged child can’t read /etc/nsswitch.conf, /etc/pwd.db or /etc/group, much less load and execute NSS modules). There is nothing to stop normal, non-sandboxed processes from using Casper as well, so once Casper does DNS, we no longer need Unbound.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.