NIST DNSSEC workshop notes

"Scott Rose" <> Mon, 02 July 2001 15:09 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with SMTP id LAA20185 for <>; Mon, 2 Jul 2001 11:09:09 -0400 (EDT)
Received: from (localhost []) by (8.12.0.Beta13/8.12.0.Beta13) with ESMTP id f62EaJsG020012 for <>; Mon, 2 Jul 2001 16:36:19 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by (8.12.0.Beta13/8.12.0.Beta13) id f62EaJM6020011 for dnsop-outgoing; Mon, 2 Jul 2001 16:36:19 +0200 (MEST)
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.12.0.Beta13/8.12.0.Beta13) with ESMTP id f62EaIsG020006 for <>; Mon, 2 Jul 2001 16:36:18 +0200 (MEST)
Received: from barnacle ( []) by (8.9.3/8.9.3) with SMTP id KAA20681 for <>; Mon, 2 Jul 2001 10:36:16 -0400 (EDT)
Message-ID: <019401c10304$27965280$>
From: "Scott Rose" <>
To: <>
Subject: NIST DNSSEC workshop notes
Date: Mon, 2 Jul 2001 10:34:51 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Precedence: bulk
Content-Transfer-Encoding: 7bit

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.


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).

2. 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.

3. 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

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.

4. 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.

5. 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.

6. 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.

7. Notes for future workshop holders
1.  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
9.  It is safest to insure every participant is using the latest version.

2.  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.

3.  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.