http://www.linuxsecurity.com/feature_stories/conrad_vixie-1.html
> Paul Vixie and David Conrad on BINDv9 and Internet Security
>
> By Dave Wreski
> 10/3/2000 7:54
>
> In this interview, Paul Vixie and David Conrad talk about the
> Internet Software Consoritum, the changes in the latest major
> version of bind, the security features designed into it, and the
> future of Internet security.
>
> Recently I had an opportunity to speak with Paul Vixie and David
> Conrad, two Internet veterans and developers of the Berkeley
> Internet Name Daemon (BIND), the software that translates
> Internet host names to IP addresses.
>
> 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... :-)
He must be referring to:
The obvious mathematical breakthrough would be development of
an easy way to factor large prime numbers."
-- Bill Gates, The Road Ahead, Viking Penguin (1995), page 265
quoted on
http://philip.greenspun.com/humor/bill-gates.html
> 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.
--
Gerald Oskoboiny <
[email protected]>
http://impressive.net/people/gerald/