Minutes on Meeting for DNS RR Updates in Parent Zones
2008-07-31 09:00--11:35 local time

Nominet Meeting Room
Citywest Hotel
Dublin
Ireland

Present: 

  Roy Arends <roy at the domain nominet.org.uk>
  Jakob Schlyter <jakob at the domain kirei.se>
  Patrik "Pawal" Wallström <patrik.wallstrom at the domain iis.se>
  Michael "MC" Widerkrantz <mc at the domain hack.org>

Minutes by MC.

= Introduction =

DNSSEC lacks a specified way for automatic child-parent communication,
for instance to update a DS RR in a parent zone. This meeting was one
of the first steps in finding a solution.

Everyone present agreed that there was a problem and that we want a
standardised or at least a recommended solution.

An initial document, Rollover_Requirements_v2.txt, was discussed. [MC:
Available where? Should we include an URL here?]

The meeting agreed that we need a protocol agnostic problem statement
that is more clear than in the existing document. It is left for the
future to define the exact problem statement. We will work it out in
mail and future meetings.

The meeting suggested a clear split of:

  1. Problem statement.

  2. Requirements.

  3. Discussion of possible solutions.

= Requirements =

We went on to discuss requirements of the protocol:

MUST be scalable: n to 1 and 1 to n. "Imagine 6 million children
updating a single parent at the same time."

SHOULD demand a minimum amount of state.

SHOULD include a direct response and acknowledgement of a
message. Why? Because how would we want immediate feedback if
something is wrong. The meeting noted that this most likely
disqualifies DNS NOTIFY as a solution.

MAY have a discovery mechanism. Discover if your parent zone can
handle this protocol, where to go (i.e. which server) to contact et c.

MUST be able to support mutual authentication of both ends of
commmunication.

MUST: Credentials should be seperate from the contents. It must be
possible to update without a key in the content. Do not use DNSKEYs to
authenticate.

How do we set up the credentials?

MUST have message integrity.

MAY have message confidentiality. "We need integrity, not
confidentiality."

The consensus was that signed data end to end is not required. It was
suggested that a discussion is needed in the requirements why this is
not required.

MUST be able to update at least RRs: A, AAAA, NS, DS and DNSKEY.

MUST be able to update several records at once in the same update. One
or more RRs in one or more RR sets in one or more zones.

No requirement to be able to check if record is published: ordinary
DNS queries can be used.

= Possible solutions =

DNS UPDATE with TSIG (and different passwords for all peers) might
fulfill all requirements, even mutual authentication, but not SIG(0).

= Next Step =

The next step is to:

  1. Formulate a stringent problem statement.

  2. Make a proof of concept implementation, possibly with the use of
     the DNS UPDATE protocol.

= Other Work =

HTTP API for updating DNS records:

  http://www.ietf.org/internet-drafts/draft-jennings-app-dns-update-00.txt