LinuxSecurity.com: Can you give us a brief description of your background? How did you become involved with BIND and eventually come to form the ISC?

Paul Vixie: I started working on BIND in 1988 while employed at Digital Equipment Corp. (DEC) which was later bought by Compaq. My job was to run their corporate internet gateway (DECWRL) in Palo Alto, and also to run the servers for the DEC.COM zone and work with other parts of the company to allocate subdomains on a global basis (we had about 400, which was a lot at that time.) One of the biggest sources of operational instability in my (DEC's) gateway was the sleazy, icky, rotten code produced by U C Berkeley in the previous decade, and I quickly found myself up to my armpits in Sendmail and BIND muck.

Eventually it became known that I had a stable version of BIND running at DECWRL, and folks who heard about this asked me for copies. I published kits on my FTP server and folks started not only picking up my kits but running them and submitting patches (both enhancements and bug fixes). Soon it was time for UCB to ship another BSD tape (4.3-Reno, I think) and they included my version of BIND rather than their own. UCB BIND was dead, and DECWRL BIND had taken its place.

In 1993 I left DECWRL to return to my private consulting practice. I found that the BIND community expected me to "take BIND with me" -- it was clear that noone remaining at DECWRL had any interest in it. So I continued to publish new BIND kits independently. Rick Adams, then of UUNET, evidenced a *very* strong desire that BIND be worked on, and had the "old nonprofit" part of UUNET issue me a grant to do just that. In 1994, Rick and I decided that other companies should also be helping to fund this piece of critical infrastructure (since it was by that time clear that ISO was dead and that TCP/IP would be the basis for all public data networking), and we founded ISC as a funding clearinghouse to support BIND and similar software.

David Conrad: Started working with the Internet around 1983 as team leader of a joint IBM/University of Maryland project for the development of a commercial TCP/IP on the IBM PC product. Leaving UMD in 1990, I worked as a researcher at the University of Hawaii on the PACCOM project, providing the first Internet connectivity to various Asia Pacific countries. I moved to Japan in 1992 and helped start up the first commercial ISP in Japan, Internet Initiative Japan, Inc. In 1994, I was asked to create and run the Asia Pacific Network Information Center, the Regional Internet Registry for the Asia and Pacific Rim region which I did until 1998. Returning to the US in 1998, I became the Executive Director of ISC and helped set up (what became) Nominum with Paul.

My involvement with BIND came with the job (ED of ISC), however I used and administered BIND (of various versions) at pretty much every job I had.

LinuxSecurity.com: BINDv9 is a 'major rewrite' from previous versions. Can you explain to us the reason for this rewrite and what new features have been added with regard to security?

Paul Vixie: Because every bit of effort I ever put into BIND, from version 4 to version 8, was patchwork. The basic sleazeware produced in a drunken fury by a bunch of U C Berkeley grad students was still at the core of BIND. In 1998, Jerry Scharf, who was the Executive Director of ISC, convinced the remaining UNIX vendors and a few government agencies that the only way to support all of the new DNS protocol enhancements was to totally rewrite BIND. That work is substantially complete as of last month. The major feature isn't security as much as it is robustness. BIND9 was written by a large team of professional software developers who had enough time and enough money to "get it right." BIND9 is auditable in ways which BIND8 and BIND4 never were. It will support the next generation of DNS protocol evolution, as well as back end database support, security (both transactional and authenticity), portability, abstract user and management interfaces, SNMP, and everything else that's needed to be a robust commercial product in the Internet of Y2K and beyond.

Nominum, Inc., was founded in 1999 to carry the DNS torch commercially, since ISC as a nonprofit was not able to move aggressively enough.

David Conrad: Actually, BINDv9 is a complete rewrite. There is no significant code shared between BINDv8 and BINDv9.

BIND version 8 evolved almost organically over about 17 years with little thought given to coherence or design. It is architecturally unsuited to further development of any significance, particularly given the complexity of the new standards being produced by the IETF in the areas of IPv6 and DNS security enhancements. For example, one of the requirement of the new version of BIND was that it scale with multi-processor machines. Putting multi-processor support into BIND version 8 would likely have taken more effort than it took to implement the entirety of BIND version 9 due to the requirements of data locking, concurrency control, etc.

Security was a key consideration in design -- BINDv9 was designed to run without privileges (where possible) and in a chrooted environment. We used a "programming by contract" paradigm during implementation which helps insure that parameters to all routines are verified for correctness. We've also done several audits of the code, in particular those areas of the code that deal with network input.

On the standards front, BIND version 9 supports the full DNSSEC standard (with the exception of supporting wildcards in signed zones) and IETF standardized TSIG (HMAC-MD5) and all the other security related RRs.

Both of these enhancements will enable the DNS infrastructure to be more secure which will permit additional services and applications to be built on top of the DNS.

LinuxSecurity.com: Can you explain exactly what DNSSEC is and why a site would want to use it?

Paul Vixie: DNSSEC is a data authenticity model. In the normal insecure DNS, a client has no way to "prove" that the answer it has received actually came from the owner of the zone it purports to be part of. (A zone is like a parent domain.) With DNSSEC, the protocol has been amended to support distributed keys and signatures in the "public key cryptography" model so that a client who wants to be *sure* that an answer is "authentic" has a means of doing so.

David Conrad: The only thing I'd add would be that we're beginning to see the development of applications for DNSSEC, such as LADON (http://www.cs.jhu.edu/~smang/sshproject.html).

LinuxSecurity.com: Are there any features that you expect to be more fully implemented as we continue through the 9.x version?

Paul Vixie: That depends on the market. I've listed some of the things I know folks want, earlier above. The point of BIND9 was to make it once again possible to add features to BIND. BIND8 was "full."

David Conrad: The requirements we've heard so far are support for Microsoft's GSS-TSIG (a not-yet-standard private key transaction protocol that Microsoft is using in Win2K), support for multi-lingualization of the DNS, and support for building/running BIND version 9 without pthreads. There are still a couple of areas where we're deficient in support of standards, e.g., we don't support using DNSSEC with wildcards and a BIND version 9.0.0 slave does not forward dynamic updates to the master as it should according to the RFCs. Our intent is to fully implement the standards (and/or help revise the standards to make them more useful to the Internet community).

Another area that we know needs some work is in the resolver. Due to the requirements of DNSSEC and A6 support, we chose to create a "lightweight resolver daemon" with get*by*() routines which call this resolver daemon (similar in concept to Sun's "ncsd"). However there are a few areas that this can be improved and we're looking at this right now.

LinuxSecurity.com: Why is nslookup going away? When do you expect this to happen? Can you give us an example of how to use 'dig' or 'host' as a substitute?

Paul Vixie: nslookup's functionality will probably return in some form, since a lot of people seem to like it. The existing BIND8 implementation of nslookup is very closely bound to the internal API of BIND8, which does not exist in BIND9. Generally, "dig NAME RRTYPE" is all most people need to know, but if it's important to direct a query to a particular server then the syntax is "dig NAME RRTYPE @SERVERADDRESS". Lastly, if what you want is a zone transfer (which nslookup implemented in its "ls" command), the syntax is "dig NAME axfr @SERVERADDRESS", in other words, use an RRTYPE of "axfr".

David Conrad: The behavior of nslookup is suboptimal in many areas, giving weird or un-useful error messages, however it is difficult to simply fix nslookup as many people rely on the weird behavior (particularly in scripts). The functionality provided by nslookup will likely continue (given how many people have written scripts that require and are used to using nslookup), but we didn't have time to do the full revision we wanted, so we give a warning suggesting people use dig instead.

LinuxSecurity.com: Some other DNS server implementations state one of their primary development goals is to be as secure as possible. Specifically, Dan Bernstein has posted a $500 reward to the first person that can find a security hole with his name server implementation. Was security a primary design goal for BIND?

Paul Vixie: No, it was an indirect goal. We wanted to produce a rock solid, commercial grade, open source DNS implementation in the tradition of BIND and with high compatibility with BIND. One important side effect of all that is security.

David Conrad: I can't speak to earlier versions of BIND (I wasn't involved in their design), but security was among the core requirements of the BIND version 9 project.

LinuxSecurity.com: Can you explain how security fit in to the new implementation? Do you have any feelings on how the two development processes differ?

Paul Vixie: Nothing really comes to mind here, except that Bernstein's software does not support either DNSSEC or TSIG, and as far as I know there are no plans to implement either one. BIND implements both. Even Microsoft implements TSIG.

David Conrad: According to Bernstein's definition of "security hole", yes. Of course, $500 will almost certainly be in the noise compared to the cost of recovering from a breach that would meet Bernstein's definition.

Generalizing, BIND version 8 has been hacked on forever and it is really unpleasant to work on. I don't think there is anyone that would choose to work on it except under some form of duress :-). As for working on BIND version 9, it was funded by a bunch of organizations and the development was outsourced to Nominum, Inc. with the requirement that the results of the development be Open Source. As a result, the development of BINDv9 was more along the lines of a traditional large scale development project with a set of requirements specified by customers (funders/ISC) which we at Nominum did our best to meet.

These requirements significantly constrained the design. In particular, BIND version 8 backwards compatibility, DNSSEC and A6 support, full RFC conformance, and performance considerations (i.e., thousands of queries per second) implied the architecture that resulted.

In the case of an individual, acting alone, no such constraints apply and entirely different architectural decisions can be made. I will note that Bernstein's djbdns does not support DNSSEC, A6, DNAME, bitstring labels, Dynamic DNS, outgoing AXFR, IXFR, and other of the more modern features of the DNS. We did not have the luxury(?) of ignoring IETF standards and prefer to work and play well with others.

LinuxSecurity.com: What are your thoughts on the recent RSA patent expiration? How will that affect commerce on the Internet, companies relying on that algorithm, and programs that use it, such as OpenSSL?

Paul Vixie: It will allow BIND to be used in more places, since some redistributors were forced by this patent to edit BIND's sources to remove the cryptographic features. It's unlikely that this will change the rate of DNSSEC's adoption.

David Conrad: I look forward to seeing significantly increased use and interest in developing applications based on the RSA algorithm. Hopefully, the easing of US crypto controls earlier this year doesn't mean that someone has figured out how to factor large primes trivially... :-)

LinuxSecurity.com: What do you see as the most significant trends or developments in computer security in the next few years?

Paul Vixie: We have to make the technology more available and more usable to end users. Security has to be end to end, and the endpoints right now are very weak since end-user security is either expensive, complex/unusable, fragile, or all three. Usually it's all three. I expect DNSSEC to be used as a key distribution platform for other applications, including shell access, e-mail, and file exchange. Eventually we have to make good security ubiquitous or the "haves" will continually raid and control the "have nots".

David Conrad: Seeing computer security as primarily risk assessment and management instead of site or application hardening.

LinuxSecurity.com: Do you think Linux has a place in the data center as a secure platform for commerce in the state that it's currently in? What do you think needs to change with regards to security and Linux? Are there any root servers that run Linux or other Open Source platforms?

Paul Vixie: Some versions of Linux have become remarkably mature in the last few years. Now that there's a growing stable of companies providing commercial support, I think we'll see Linux become a respected component of enterprise information management strategies alongside BSD/OS and FreeBSD. Both Linux and BSD have already proven their strengths in the front end, and when they filter out to the back end I think we'll see the end of the historic ABI/API captivity strategies of the big iron vendors, not to mention Microsoft. I also note that Mac OS X is BSD-based. This means we've finally gotten our point across, and open source is viable in both the long and immediate term.

David Conrad: Linux most assuredly currently has a place in the data center as a secure platform for commerce.

There is a fine line to be drawn between usability and security. I personally feel that Linux (or rather, the popular distributions) may err on the side of allowing too many applications and services to exist and/or default to on. From my experience, it is difficult to fully audit contributed code (the BIND v8.2 & v8.2.1 NXT bug that has caused such difficulties was a result of a bug in code donated to us, ironically enough, from a large firm that focuses on computer security) and Linux is, almost by definition, contributed code (from FSF, ISC, etc.). Simplifying distributions would probably tend to increase security (while possibly decreasing usability, at least for somebody).

Each root server operator makes their own decision about what architecture/OS/nameserver is used. None that I'm aware of run Linux. A couple run FreeBSD, I believe.

LinuxSecurity.com: What are some of the biggest challenges you face when dealing with security?

Paul Vixie: No comment comes to mind.

David Conrad: The complexity of the recent IETF standards results in a lot of complexity in the code which increases the potential for bugs (security related or otherwise). Standards bloat, in combination with feeping creaturism demanded of us by our funders or users, results in software bloat which is probably our most significant challenge.

Only registered users can write comments.
Please login or register.

Powered by AkoComment!