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

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 19-Feb-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

Minutes of the DNS IXFR, Notification, and Dynamic Update (dnsind) Working Group

Chair: Randy Bush <randy@psg.com

Reported by Lars-Johan Liman <liman@sunet.se>

I. Introduction

Randy reported on interoperability testing the night before. A detailed report will be released shortly. During the tests of Dynamic Update a few unclear passages in the documentation were discovered.

In section 1.3 of the paper, the term "owned by" is misleading terminology, and should be rephrased. Paul Vixie will fix the document.

The document will not be advanced since:

There is rumored to be an RFC that prohibits the use of domain labels with only hex digits in them. The audience was requested to find the document so that the problem can be "fixed".

II. TSIG

draft-ietf-dnsind-tsig-04.txt

There is a difference in opinion on how to interpret the digest function in the draft. Should the digest calculated over all of fields at once, or piece by piece. Two different implementations exist.

The discussion has not been on the list. Paul Vixie will dig out his personal mail archives, and put relevant parts on the list. Hopefully there will be consensus before the end of April.

III. Secure DNS Updates

Secure updates are viewed as cumbersome but dynamic updates are needed now.

There was consensus to ask IESG to forward the DYNDNS document when either of secure dynamic updates _or_ TSIG is ready to accompany it.

IV. EDNS

draft-ietf-dnsind-edns-02.txt

Paul Vixie reported on the status of the Extended DNS document.

According to Paul "All it really does is to expand all the fields from 8 to 16 bits that Paul Mockapetris didn't double in the original design."

There are two label types free. Paul V suggests to use one for "extended" DNS and to maybe use the remaining one for local compression.

The current spec is designed so that one will get a deterministic error reply from old servers.

The drafts has 2 main aspects:

1) How the mechanisms of EDNS work.
2) Specification of a few extensions that are needed immediately.

There is a problem with forwarders that might not understand what end systems want to communicate, but it can be considered an operational problem, and Paul will give some recommendations in the document.

There was consensus to try to push this to proposed standard before the next IETF meeting.

V. DNS Labels

Donald E. Eastlake presented status on the DNS labels document. See the slides.

On slide 4/5: Rob Austein, one of the persons behind the suggestion to use a 2-bit prefix for labels from 64-127 bytes (the 3rd alternative on the slide) withdrew his suggestion after some consideration.

There was some weak consensus to go for alternative two: to use a 2 bit field for local compression.

VI. DNS Error

draft-ietf-dnsind-dns-error-00.txt

Edward Lewis gave a presentation on extended error codes. See slides.

VII. UDP Size

draft-ietf-dnsind-udp-size-01.txt

Donald E. Eastlake gave a presentation on UDP size extensions. The main idea is to encode client buffer size and possibly fragmentation capabilities or IPv6 capabilities in the packets.

Someone suggested that the options method would be better for such negotiation.

Michael Patton wanted to move issues regarding entire DNS messages from "extended error codes" do EDNS.

VIII. BINARY LABELS

draft-ietf-dnsind-binary-labels-00.txt

Matt Crawford gave a presentation on the subject. See slides.

There was a discussion on whether 0-length bit field should be allowed or not. The meeting did not reach a conclusion.

Masataka Ohta stated that longest match would be difficult to do on cached records.

Matt replied that longest match must can only be preformed by the authoritative server.

The following issues are to be taken to the mailing list:

IX. DNAME RRs

draft-ietf-dnsind-dname-00.txt

Matt Crawford gave a presentation on the subject. See slides.

Some discussion erupted on whether more RR:s should be allowed for owner names that have DNAME or not (as with CNAME).

X. Local Compression

draft-ietf-dnsind-local-compression-01.txt

Peter Koch gave a status report. See slides.

Bill Simpson and John Gilmore wondered if the benefit would motivate the input effort.

There was some general discussion but no conclusions, and it was deferred to the list.

There was consensus to move the document forward.

XI. Test TLDs

draft-ietf-dnsind-test-tlds-08.txt

Donald E. Eastlake gave a status report on the test TLDs document.

IANA has worries about the amount of domains (42) suggested in the document. Donald has reduced number of test names and leaves to IANA to decide which to reserve.

William Simpson did not want to give such discretion to IANA. Donald countered that everything was done in best cooperation with them.

Bill Manning questioned the _technical_ reason for having such domains.

It was decided to take the question whether to forward the document or not to the list.

XII. Local Names

draft-ietf-dnsind-local-names-05.txt

The discussion carried on to the Local Names draft.

Robert Elz, suggested, in a very politically correct manner, to send it to the sewer. :-)

Some people pointed out the need to be sensitive to the needs of persons who weren't in the room to defend their views.

Paul Vixie spoke for test domains by giving the example of the need to put VERSION.BIND in a good local place.

It was decided to take it to the list and ask for support.

XIII. Multicast Addresses

Masataka Ohta did a very brief presentation on DNS for multicast purposes.

XIV. UTF8 In Labels

draft-skwan-utf8-dns-01.txt

Stuart Kwan presented the problem that Microsoft NetBIOS allows UTF8, and when one wants to move to DNS the usual limitations click in. He suggested that the DNS community endorse UTF8 as the future encoding scheme.

Immediately a violent discussion erupted (as expected :-).

Rob Austein commented that clients may break.

There are immense problems with input. Apart from the apparent problem with typing in strange foreign characters on local keyboards, there is also the problem that certain glyphs have multiple codes, e.g. cyrillic C != latin C, but they look the same.

John Gilmore concluded that there are general problem with displaying and input, but they can be put in labels already.

John also suggested to write a BCP on how to use DNS, and maybe include sections on character issues.

At this point time was up, and the discussion exploded into a mess that was beyond the capabilities of the scribe to translate into written text. :-)

Slides

None Received

Attendees List

Roster Not Submitted