2.3.1 DNS IXFR, Notification, and Dynamic Update (dnsind)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 27-May-99

Chair(s):

Robert Elz <kre@munnari.oz.au>
Randy Bush <randy@psg.com>

Internet Area Director(s):

Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>

Internet Area Advisor:

Erik Nordmark <nordmark@eng.sun.com>

Mailing Lists:

General Discussion:namedroppers@internic.net
To Subscribe: namedroppers-request@internic.net
Archive: ftp://rs.internic.net/archives/namedroppers

Description of Working Group:

The DNS Incremental Transfer, Notification, and Dynamic Update Working Group is concerned with three areas of future DNS protocol development:

1. Incremental Zone Transfer - As the sizes of some zone files have grown quite large, it is believed that a protocol addition to allow the transfer of only the changed subset of a zone will reduce net traffic and the load on critical servers.

2. Change Notification - There can be large time intervals during which at least one secondary has data that is inconsistent with the primary. The proposed ``notify'' mechanism (where the primary sends a message to known secondaries) facilitates fast convergence of servers vis-a-vis consistency of data in the zones.

3. Dynamic Update - The need to frequently update small portions of a large zone and to have those updates propagate is perceived.

Goals and Milestones:

Done

  

Consolidated review of draft-ietf-dns-ixfr-01.txt.

Done

  

Submit Incremental Transfer and Notify Internet-Drafts.

Done

  

Submit revised Incremental Transfer and Notify Internet-Drafts.

Apr 96

  

Submit Dynamic Update, Incremental Transfer, and Notify Internet-Drafts to the IESG for consideration as Proposed Standards.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1996

PS

A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)

RFC1995

PS

Incremental Zone Transfer in DNS

RFC1982

PS

Serial Number Arithmetic

RFC2136

PS

Dynamic Updates in the Domain Name System (DNS UPDATE)

RFC2181

PS

Clarifications to the DNS Specification

RFC2182

 

Selection and Operation of Secondary DNS Servers

RFC2308

PS

Negative Caching of DNS Queries (DNS NCACHE)

RFC2317

 

Classless IN-ADDR.ARPA delegation

RFC2606

 

Reserved Top Level DNS Names

Current Meeting Report

Minutes for DNSIND / DNSSEC joint meeting, Monday July 12, 1999, Oslo

Chaired by Randy Bush and Robert Elz. Minutes taken by Robert Elz with the assistance of M.T. Hollinger, Mark Gritter, and Ed Lewis.

One agenda addition from previously published agenda: added a brief slot for Matt Crawford to talk about ipngwg's A6 record draft.

The proposed charter for the proposed new merged dnsind/dnssec WG was shown, no comments received. "dnsext" received no objections as the new WG name. The charter will now have its milestones updated reflecting the outcomes of this meeting, will then be sent to the list for review, and then, assuming there are no problems, will be sent to the ADs for IESG approval.

The list of dnsind & dnssec RFCs in PS status was reviewed, with brief comments on what their next steps might be, and when. RFC1982 is, and has been for some time, ready to advance. RFCs 1995 and 1996 still need some interoperability testing. RFC2136 must wait until there is a security mechanism ready to advance to DS along with it, which won't be RFC2137, which is obsolete already. RFC2181 will be a little difficult to deal with, because of its nature. No interoperability reports yet exist on RFC2308. None of the newer RFCs (2535-9, 2541) have been at PS long enough to advance yet. And there are three more approved by the IESG, but not yet published (edns0, binary-labels, and dname).

All known current internet-drafts in dnsind and dnssec were then listed, and briefly discussed. The group suggested possible outcomes for the various documents, more detailed discussion of many of which was on the agenda anyway. Of the ones not on the agenda for this meeting, it was felt that draft-skwan-gss-tsig-*.txt should advance as PS, draft-ietf-dnsind-indirect-key-*.txt may proceed as either PS or Experimental, that to be determined later. Discussion of draft-ietf-dnsind-keyreferral-*.txt was merged into the agenda item on draft-ietf-dnsind-sec-rr-*.txt. It was felt that draft-skwan-utf8-dns-*.txt needed to be compared against UTF5 proposals (of which no draft was known at the meeting, though the name of one was subsequently sent to the list).

Draft-ietf-dnssec-as-map-*.txt has been sent to the routing area so often over the years that no-one has kept count, it kept returning to dnssec when no-one from routing showed much interest. The group resolved, once again, that this draft is not work for this working group. No-one had any information on draft-ietf-dnssec-secfail-*.txt and it was consequently dropped (it is an old draft and should most probably have expired by now anyway). A draft just recently submitted with a dnssec label (draft-ietf-dnssec-externalkeys-*.txt) was also unknown to the group, and not considered to be a work item.

One additional draft, draft-ietf-urn-naptr-rr-*.txt (from the URN group) was noted as being one that this group should keep an eye on, if not actually take over from that group. This is intended to become a standards track RFC.

Finally, draft-ietf-dnsind-tsig-09.txt had completed its working group last call, and was considered ready to be sent to the ADs for review and IETF last call for PS. Being (apparently) completed no discussions of this draft were held.

Matt Crawford spoke on the A6 record draft from the ipngwg group. That is draft-ietf-ipngwg-dns-lookups-*.txt. He was asked about the potential explosion of lookups that could possibly be required. The answer was that resolvers should limit the amount of work they're willing to do - anyone who makes an unreasonably complicated zone (too many indirect A6 records) will not have their names resolved. They will be the ones to suffer. This is much the same as that which limits chains of CNAME records, etc.

There was discussion on the current status of draft-ietf-dnsind-rfc2052bis-*.txt, the planned replacement of the experimental RFC 2052. This draft completed its working group last call and IETF last calls early in the year, after which it was rejected by the IESG. Subsequent discussions, on the namedroppers list, and in private between the chairs, ADs, IESG, and IAB, have so far failed to arrive at a compromise position.

The most recent list of 11 requested changes were discussed. Some of those were considered as trivial, some had been previously agreed by the working group, just have not yet appeared in a new draft while other open issues remain. Most discussion centered upon what protocols (or non-protocols) should be used as examples of the SRV RR that this draft defines. Using examples of well known protocols which do not in fact actually use SRV was objected to by the IESG. The group made no actual progress on resolving this issue during the limited time available in the meeting. Aside from some requested wording changes there were less objections to other proposed changes, except that some members of the group felt that prohibiting the use of SRV records in protocols other than where their use was specified by an RFC was going to far, and claimed to be already using them for applications like telnet. One wording change requested, and generally agreed with, was to replace the phrase "load balancing" anywhere it appears (an in one place in particular) by the phrase "server selection". It was felt that attempts to read the SRV record as a mechanism by which load could really be balanced in any meaningful interpretation of the term may be one of the causes of some of the difficulties this draft has experienced. The attendees felt that pressing ahead with attempting to get this published on the standards track was worth while - it was noted that it has already been implemented, and our attention was drawn to draft-ietf-cat-krb-dns-locate-00.txt. More discussions will be held on the mailing list. The milestone for the charter on finishing this document is still way out into next century however (and receding).

There was a very brief mention of draft-ietf-dnsind-edns1-*.txt, and its aims. It was requested that discussion continue (start really) on the list.

Donald Eastlake III spoke on draft-ietf-dnsind-tkey-*.txt. It has been waiting upon tsig to be finished before any real attempts to push it forward. This is a scheme for agreeing upon keys (to use for tsig). He was asked if this belonged in the DNS at all. The answer was that a mechanism is needed, and it needs to be one which does not rely upon the DNS being functional, he was loath to depend upon any other mechanisms necessarily being available. It was pointed out that this would mean there would be (could be) multiple different mechanisms to obtain essentially the same information. Don asked the group whether all of the options that currently exist in the tkey draft are required, and whether it should perhaps be simplified. More discussion on this draft is needed on the list. It is currently intended as a standards track document.

Edward Lewis, as proxy for for Brian Wellington, spoke on draft-ietf-dnsind-simple-secure-update-*.txt. He went through the changes in the latest version of the document (which has moved from a dnssec doc). Authorisation for the dynamic update transaction has been separated from the security of the data being updated. That is (as your reporter understands it) the key needed to perform an update of data in a zone will not be the same key used to sign that data. Only the zone key is now permitted to sig, not user keys. Ed was asked why this change had been made - he didn't have the answer. This will be explained on the list. The new doc also now allows the use of SIG(0) as an alternative to TSIG as a signing mechanism. There are no current known implementations, though it was stated that one was planned for Bind version 9.

Donald Eastlake spoke on draft-ietf-dnssec-update2-00.txt. RFC2137 should be considered obsolete, it is incompatible with RFC2535. This draft was the intended replacement for RFC2137. That is the public key secure update method, whereas simple-secure-update is the shared key secure update method. Other methods could also be defined. It was asked whether all these could be combined into one document. Don stated that he couldn't defend update2 as currently proposed, it is too complicated. It was also asked which method should people implement. The answer was that this depends, public key methods are more general, but have higher overhead. None of the methods have actually been implemented yet. Randy Bush said that for the global internet public key was the way to go, for small clouds, shared key, but that doesn't scale to the internet as a whole.

It was suggested that the names should be changed, so instead of suggesting "simple" and "complex" updates, that names suggesting public, and shared, key updates be used, to avoid loading the names. This is to be discussed on the mailing list.

Donald Eastlake also spoke on draft-ietf-dnsind-rollover-00.txt. This is a mechanism for zones to deal with parent/child zones needing to be resigned. He solicited comments on the list on this draft, which also deals with zones that split, or recombine.

It was asked whether in some world where .com is shared among various administrators with different keys, might this get complex. The answer was yes. It was also asked whether the request for a key to be signed be manual? The answer was no, that is the point of this proposal. Does this cause a problem with zones where the key is not to be kept on line? There is no comment on how quickly things happen, just that they do. If latency might be days, servers might not want to retain state of the requests that had been made. Donald briefly described the method, but suggested that discussion of the issue be continued on the mailing list.

Edward Lewis spoke on draft-ietf-dnsind-sec-rr-00.txt. This and draft-ietf-dnsind-keyreferral-00.txt are related drafts. Keyreferral came first, sec-rr is an addition to the earlier draft. The issues were that it could be difficult for a parent if it had to retain keys for all of its children, and that there was also some desire to progress away from NXT records. However, Ed is now convinced that the parent doesn't need to hold keys for all children. Don Eastlake remarked that only keys for insecure children that cannot be updated are needed. Also, there have been comments that the current specifications should not be delayed more, before some implementation experience has been gained. For example, on NXT records, they have not yet been implemented for anyone to really be able to say that they are unworkable. For now these drafts will be considered dormant. If, at some later stage, there appears to be a need for them, they can be revived.

Donald Eastlake spoke on draft-ietf-dnsind-kitchen-sink-00.txt. This is a new proposed resource record (actually not all that new, drafts proposing it have even around for a while, and it has a type code assigned) to provide a mechanism for those who want to define new RR types to hold the known universe, but who don't, or can't obtain a specific RR type code, and otherwise tend to attempt to interpret the contents of TXT records. One problem with the Kitchen Sink RR (and TXT records) is that an application seeking to use it will get all the records returned, and then have to dig through those to find the relevant ones. It was asked why individual RR type codes couldn't simply be used. Rob Austein replied from the audience that this is for those who won't, or can't, do that. For example, the IANA is unlikely to register an RR code for an RR type whose contents cannot be divulged. If a proposed RR is worthy of standardising, it should get its own RR type code. This RR is for all of the other junk. A new draft is to be expected within about a month of the meeting, after which it should be pushed forward as an experimental RFC.

Peter Koch spoke on draft-ietf-dnsind-apl-rr-02.txt. This new draft resolves the issues that had been raised since the last meeting. No new issues have been raised. Peter believes the draft is ready for a working group last call prior to requesting the draft be advanced as a proposed standard.

Edward Lewis again acted as a proxy for Brian Wellington, and spoke on the draft-ietf-dnsind-dddd-01.txt draft. Ed went through the changes in the new version of the draft. It seems that there is a demand for a mechanism that can be used to (in particular) make old DCHP installed records go away after they are no longer relevant. However there was little support for this particular mechanism, it is too complex. Michael Patton proposed a method long ago, the reaction then was that the work required wasn't justified by the benefits. There is really little harm in leaving the obsolete records in the DNS. A simple way to arrange for records to be deleted is a desirable goal, but so far, no-one has been able to find a suitable method. Rob Austein pointed out that most of the mechanism proposed is for handling all of the possible failure cases, which are unlikely to occur, and in any case, do little harm. It was suggested that this draft be dropped.

Robert Elz spoke very briefly on Mark Andrews' draft draft-ietf-dnsind-verify-00.txt, and explained its purpose. Peter Koch spoke on draft-ietf-dnsind-local-compression-05.txt which is, essentially, an alternative - both provide a mechanism to allow name compression in DNS packets for future RR types which contain domain names in their data.

The new draft of local-compression avoids an ambiguity that was in the previous draft - it now makes compression mandatory, so every RR will have a canonical form for the compressed RR. Local compression should simply work if deployed at client & server for a new RR. On the other hand verify requires all the DNS servers on the net to be upgraded before it can safely be used.

It was asked which, local-compression or verify, would work better for a new RR type that is to be deployed for only a short period. No-one was really in favour of proceeding with verify.

Randy Bush asked whether anyone has any pressing need for any kind of compression inside the RR data fields of anything but the NS records of the root zone? No-one had any demand. Peter Koch suggested that there might be new RRs coming where compression might be useful. Matt Crawford suggested A6 records might, but probably no type of compression will really help.

Donald Eastlake spoke on draft-ietf-dnsind-local-names-07.txt. This draft has been updated, but more updates are still needed. The draft deals with two issues, and perhaps should be split into two. The more controversial second part needs the TLD "local" added to the root zone files to work. It was asked what is the demand for this mechanism. Don couldn't really say, but did indicate that there do seem to be some
people using it.

As a suggestion for naming local resources, it seems OK. The local top level domain part is more controversial. The draft is to be revised one more time and then group will decide what we will do with it.

Under any other business, Donald Eastlake suggested that an IANA considerations draft, for the DNS, was needed. Bill Manning indicated that he already had a task to create such a document. Don and Bill will work together to produce a draft of this.

The group was asked whether any had examined the new proposal for another resource record giving location information. The group did not express what could be considered support for the proposal.

Robert Elz suggested that for the Washington IETF, as a trial, dnsind (or whatever the group has turned into) drafts will be required to be submitted to the secretariat at least two weeks prior to the secretariat's cut off date. That is, dnsind has an earlier deadline. Drafts that do not make that earlier deadline will be considered at the meeting only if time permits (they will definitely be at the end of the agenda, and no attempt will be made to squeeze the agenda to make them fit). No dissent was expressed to this.

Slides

None received.