NIST DNSSEC workshop notes (original) (raw)

NIST DNSSEC workshop notes

I know there was a lot of interest in the results of the workshop, so here is the first draft of the results. I wasn't planning on putting these in "Internet draft" form, unless there was a WG request for it. I will talk about the workshop in London as well.

Scott

Notes on the NIST DNSSEC Workshop June 26-27 NIST North Campus - Gaithersburg MD

1. Introduction The NIST DNSSEC workshop was held on the NIST campus on the 26th and 27th of June. The target audience for the workshop was DNS administrators and operators of zones in the ".gov" domain. The participants were a mix of skill levels, but all having knowledge of DNS and server operation (either previous BIND versions, or another implementation of DNS server software).

The workshop covered two days: The first day was spent setting up the workshop test domain, learning the new administration and security tools in BIND 9, transaction signatures, and signing zones. The second day was the continuation of zone signing, then performing a key rollover. The storing of the child KEY record and signature at the parent scheme was used for the first day, then the switch to storing the KEY and SIG at the child was used on the second day.

The network was set up on the NIST campus outside the NIST firewall. NIST provided all the network infrastructure and managed the workshop (run by Darrin Santay and Scott Rose - both NIST). The tutorials were given by Ed Lewis of NAILabs. Discussion sessions were run by Ed, Russ Mundy (NAILabs), Doug Montgomery (NIST) and Olafur Gudmundsson (WG chair).

1. The workshop domain The workshop domain was set up for the participants to use for the duration of the workshop. There was a single root server (X.ROOT-SERVERS.NET) and a test TLD (nist2001.) set up. The root and TLD were run on the same machine, but using each zone was run on a separate BIND daemon listening on a separate IP address. The participants were using a mix of Linux, FreeBSD, and even Solaris systems running different versions of BIND 9. This turned out to be a source of some problems between BIND 9 versions (at the time, the latest was 9.1.3rc2 and 9.2.0a) that will be described later.

The participants were issued a "homework" assignment similar to the zone assignments handed out in prior workshops (the workshop during NANOG 20). This made the initial setup easier, though in future workshops, it might be a good idea for organizers to check up on participants progress before the workshop to insure their setup before the start. A brief "sanity check" was necessary to establish the test domain running unsecure zones and making sure zone transfers were being conducted.

1. Secret key security The first set of tutorials covered the use of secret keys to secure server administration and zone transfers. The rndc tool in BIND 9 was discussed first, then the use of TSIGs to secure zone transfers. This part of the workshop was highly successful. Participants were able to use rndc and use shared secrets to secure zone transfers between primary and secondary servers.

One security risk that was not discussed, but discovered by participants was that users were still able to perform zone transfers from secondary servers without using a secret key. This point should be stressed in future workshops to insure the restriction of zone transfers.

1. SIG at parent vs. SIG at child At first, the child zones submitted their KEY to the parent zone (nist2001.) for signing. The parent zone stored the KEYs and SIGs in the parent zone. This later proved to be a problem with the current BIND 9 resolver software. The child KEYs were distributed with the referral, but the resolver did not use the parent's SIG when attempting to verify the child zone. The result was a SERVFAIL response as the resolver encountered a self-signed key at the child zone. This was fixed by reverting back to the more traditional SIG@child scheme for the rest of the workshop.

2. RR TTL values The other problem encountered at the workshop was low TTL values of records in the parent zones. The TTL values were originally set at 30 seconds, but this proved too short for some secure resolutions. The values were increased to 300 seconds, which solved the problem.

3. Participants' comments

• There were many requests for easier to use dnssec tools. The tools were sometimes difficult to grasp at first, and the error messages produced by BIND and the tools were not always helpful. Any tools that would make a DNS admin's job easier (especially when the admin is not an expert in security) would be very helpful. Tools for validating secure zones as well as creating them were also requested. There was also a request of hardware support for signing large zones.

• Tools, and a process for the exchanging of keys with secondaries is also desired. This would probably not be done using the DNS, but some other (more secure) key exchange protocol. This was a minor concern, and there are other solutions to this problem than adding additional features to DNS.

• There needs to be more documentation and references for the average user to consult before deploying DNSSEC with their domain. The new O'Reilly book is a good start, but more could be useful.

• The biggest hurdle to the deploying of DNSSEC in the .gov domain is one of policy. Currently, there is no policy for securing the DNS in .gov, and there is little policy for the interaction between individual agencies and the NIC for the .gov domain (GSA). Until there is a set policy in place, individual agencies can only form "islands of security" within .gov that will likely lead to inconsistent security policies within the domain.

1. Notes for future workshop holders

2. Make sure to use a consistant version of BIND. Some bug fixes in later versions result in incompatibilities between early and later version of BIND

3. It is safest to insure every participant is using the latest version.

4. Hold a "dress rehearsal" with just the workshop organizers and any DNSSEC knowledgeable people to work out any problems with the workshop test domain before starting the tutorials. We held a "sanity check" the first morning that helped work out some problems before starting securing the domain, but it was not enough. It was also helpful to have dnssec experienced users also working through the tutorials to assist participants that are having difficulty.

5. Starting with the rndc and TSIG usage first helped the users grasp some basic concepts of DNSSEC. Using a shared secret to secure administration and zone transfers was easy to grasp (as a new concept) before starting on zone signing, key management, etc.

Reply to me if there are any questions. I will talk a little bit about the workshop during the DNSOP WG meeting in London, but will answer email questions before that. I know I did not mention everything that happened during the workshop.

Scott