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

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98

Chair(s):

Randy Bush <randy@psg.com>

Internet Area Director(s):

Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>

Internet Area Advisor:

Jeffrey Burgan <burgan@home.net>

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

Current Meeting Report

DNSIND meeting minutes - 98.08.27

Agenda bashing:
I-N-D
Binary Labels
Dname

Added
EDNS
TSIG

There was no work since LA on any of I, N or D.

Binary Labels

As discussed in LA, longest match was dropped from the Binary Labels draft and
moved to eDNS. The draft also reflected the extended label type from eDNS. There
was a discussion of whether the current dotted quad decimal syntax restriction to
requiring all four octets should be dropped. One person felt that dropping it was useful
for representing decimal prefixes. All other opinions in the room thought that the clause
requiring all four octets was still important and the suggestion was withdrawn.

Some minor edits were needed and Matt will have the next draft available by
september 4. This is expected to go to last call.

DNAME

The draft was changed to remove the suggestion for wildcard CNAME RRs for
compatability, but instead includes an algorithm that creates specific CNAMEs when
required.

There was a discussion of rule 2 in the draft for processing. The issue was why was a
specific loop detection algorithm specified. Several people believed that the statement
in 1035 saying that only a limited effort to resolve a query applied was sufficient and
that any further discussion here was over specification. After a discussion, it was
agreed that the specific algorithm would be removed.

The draft will be recycled by september 4. Because the changes were considered
substantial, some review and comment period will be needed before last call, but this
should be well before Orlando.

eDNS

A number of wording changes that have been accumulated since the last draft just
before this IETF. Paul has made the changes, and briefly presented these. Among the
issues was that the opcode for eDNS and local compression were the same, so the
eDNS draft will be changed to not conflict. Two others were more than wordsmith,
and those were discussed in the meeting.

Some vendors were concerned with the complexity of implementing all of eDNS as a
single lump, but were very interested in the larger UDP packet capability. Three ways
to move ahead were put forth:

a) move forward with eDNS with big UDP and with the eastlake UDP draft
b) remove the UDP work from eDNS and just move the eastlake draft forward
c) split eDNS into two parts, and have version 0 have just the UDP parts.

After a discussion, it was decided to move forward with c). It was pointed out that
having both parts of eDNS described in the same document would require that all parts
of document move forward at the same time. Because of this, it was agreed that the
current draft be broken in two documents, one describing eDNS, the OPT record and
base options, and one describing extended option from the current draft.

It was pointed out that if the longest match match hits a wildcard label, the return
value was not clearly specified. It was decided that the return value should stop at
the wildcard, as this was as close to current DNS operation as was possible.

The draft will be divided and both new drafts will be ready by september 4. Since
there is little change in the functioning, it was thought that this should go to last call
soon afterwards.

TSIG

Mark Andrews presented a flaw in the time synchronization logic between the client
server. If the time offset was in one direction it worked with the time window specified,
in the other offset direction, even a one second offset caused the authentication to fail.
The proposal was to take the two 32 bit dates that existed in the current spec and
reallocate them. In the new scheme, 16 bits are allocated to offset distance in seconds,
and the other 48 bits will be allocated to seconds time. This also removed the 2038
epoch issue from TSIG. WG discussion agreed that this was a good approach. The
discussion then moved to how the choice for the offset was done. It was agreed that
the offset is a user set parameter, with the 300 second recommendation from the
current draft.

The draft will be recycled to address this issue by September 4. Assuming mailing
list agreement, the draft will go to last call.

I N D conformance testing

Randy is extremely concerned that no progress has happened on the I N and D drafts.
Randy will resend comments on N and D to Paul, and Paul will make the changes.
Olafur agreed to lead a push to get implementation and compatibility information on
these documents for Orlando.

Randy also said that there would be a co-chair added to the working group, and that
should be completed by Orlando.

Thanks to Jerry Scharf <scharf@vix.com> the minutes.

Slides

None received.

Attendees List

go to list