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

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 06-Jan-99


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

Internet Area Director(s):

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

Internet Area Advisor:

Jeffrey Burgan <burgan@corp.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:



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



Submit Incremental Transfer and Notify Internet-Drafts.



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.


Request For Comments:







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



Incremental Zone Transfer in DNS



Serial Number Arithmetic



Dynamic Updates in the Domain Name System (DNS UPDATE)



Clarifications to the DNS Specification



Selection and Operation of Secondary DNS Servers



Negative Caching of DNS Queries (DNS NCACHE)



Classless IN-ADDR.ARPA delegation

Current Meeting Report

Minutes of the DNSIND working group
1999-03-16 Minneapolis, MN, USA

Chair: Randy Bush <randy@psg.com> (DNSIND part)
James Galvin <galvin@commerce.net> (DNSSEC part)
Reported by: Lars-Johan Liman <liman@sunet.se>


Olafur Gudmundson reported on the DNS interoperability tests the previous day.

6 vendors showed up. Some didn't make it due to the weather conditions on the US East coast. Negative caching (NCACHE), dynamic updates (DynUP), incremental zone transfer (IXFR) and transaction signatures (TSIG) were on the test agenda.


Only two vendors wanted to test TSIG. The test failed, since the vendors didn't have a common key format, suitable for key exchange. This might lead to a need to update the document.


All present vendors have implementations. The test went much better than at the previous IETF in Orlando. For each sub-test, at least _someone_ passed, but no one passed them all. Some tests had to be left out due to time limitations.

The following issue was raised during the tests: If a server receives a request to _decrement_ the serial number in the zone, that is supposed to be ignored, according to the documents. One of the vendors chose to _increment_ the serial number instead. Is this to be allowed? Does it have any denial of service implications?

The documents need a clarification. If you update the NS RRs by deleting the _last_ NS RR and adding a new one, is this considered to be an atomic operation? (The documents says "ignore", but what about the _last_ NS RR?)

A test report will be released soon.

Kevin Dunlap reported on IXFR tests.

There were 3 implementations present. Not all of them managed to talk to all of the others.

The following issue was raised during the tests: The existing protocol uses SOA bracketing to delimit an update, but that might not the most accurate way of doing it. There might be a need to modify the protocol to use update packets instead.

It was suggested to rewrite the IXFR spec to use the formats of DynUP, something that has been suggested and turned down at least once before.

Mark Andrews reported on NCACHE tests.

No implementation was completely correct. Some vendors did not generate negative answers correctly. Many vendors did negative caching of some RRs types, but not all RRs types.

NOTIFY was not tested in conjunction with NCACHE.

The test team did not find any need to modify the protocol.

More tests will be performed between the vendors across the real Internet.

The test team wants to hear from other implementors.

Matt Crawford reported on the progress of the binary-labels document.

The last call ended 1999-03-02.

The document is waiting for IESG to take decision. The same goes for the DNAME and EDNS documents also.

Peter Koch reported on the progress of the local-compression document.

All issues raised at the previous meeting in Orlando have been resolved.

Issue raised raised after Orlando:


How does one deal with locally compressed unknown RR types in conjunction with DNSSEC? DNSSEC requires that canonical form is used. One solution might be to limit local compression so that it may be used only for "new" RR types, and that global compression not be used for those RR types. There was consensus that this needed more discussion on the mailing list.

Transaction signatures (TSIG)

TSIG introduces the error code BADID, which leads to problems and is unnecessary.

There was consensus that the error code itself can be removed as long as the ID information is kept elsewhere.

The dns-lookup-03 document

Concerns were raised about scalability. The combination of ENDS1, binary labels, and DNSSEC will need much resources. The characteristics for DNS lookup will also change. It is possible to implement, but the effects of doing so are uncertain.

The group was reminded that IPv6 uses a different addressing model, and that it needs to support rapid renumbering.

The question was raised whether there is need for a BCP that limits the numbers number of addresses in fanout?

The EDNS1 document

No new comments.

There is need for a list of known RR types.

RFC 2052bis

The HTTP examples in the document need warning text that this is not yet supported by HTTP.

The APPS area directors had suggested alternative writing of the weight definition. The consensus on the list was to leave as is.

Donald Eastlake reported on the local-names document.

The document contains two pieces

Consensus: go for BCP.

The dns-error-01 document.

There was no input from the audience.

Peter Koch reported on the apl-rr-01 document.

The idea is to store address prefix lists in DNS.

Issues that were raised:

Further discussion will take place on the list.

Question: Could this be used to authorise the use of specific IP addresses?

Answer: No, that is better handled in the reverse mapping tree.

Mark Andrews reported on the verify-00 document.

The motivation for this document was the early drafts of local compression and the general issue of signing records of new types.

There was discussion about which RR types are known at this point, and which are not affected by the document. Which types should be supported minimally.

There was suggestion for a current status of the RR types document.

Discussion continued and concluded that we need to tie known RRs types to the corresponding EDNS version. This will be further discussed on the list.

Donald Eastlake reported on the test-tlds-13 document.

Test TLDs is currently in IETF last call, and has received no substantial negative comments.

Brian Wellington reported on the dddd-00 document.

This document deals with the lifetime of DNS objects.

Currently DNS does not expire authoritative records. The document specifies a way of adding a record and specifying that it will be deleted after a "lease" time. The updating client should be able to renew or cancel an existing lease. This is useful for addresses obtained through DHCP and IPv6 routing prefixes.

RFC 2135 specifies that dynamic update deletes must have the TTL field set to 0. This doc specifies that a non-zero TTL represents a lease time in seconds. These record are referred to as deferred deletes. A new deferred delete _always_ replaces an old deferred delete (lease renewal). The special value "-1" (all bits set) is used to cancel a deferred delete. Deferred deletes are stored persistently by the server, and evaluated in a timely manner. The TTL of a leased record is modified so that the TTL does not exceed the lease time.

Open issues:

- interval timer?
- exact timer (priority queue)?
- on data lookup?

- It doesn't require clock synchronization.

- Possibly using a prerequisite.

There was concern for how this was to propagate to slave servers.

Another concern raised is, what happens if the network between the DHCP and DNS breaks, and they end up in different partitions?

Yet another concern brought forward was that in some cases the node itself is authoritative to update its address, not the DHCP server. How is that handled?

There was also discussion on how to handle TTL when giving out answers containing such records. The preferred suggestion is to just say that the TTL given out has to be smaller than the lease, and not specify it in more detail than that.

Michael Mealling reported briefly on the NAPTR document.

NAPTR is handled in the URN working group.

Michael solicited comments from the DNSIND group, especially from the DNSSEC people.

The chair mentioned the draft-moberg-dns-caching-useful-00 document.

The author was not there do defend it. It received no comments.

The chair will not push the document unless it is resubmitted.

One final comment was that the consequences of caching and not caching are missing.

(The document was initiated by the IESG who wanted to try to evaluate scalability.)

At this point James Galvin, chair of DNSSEC, took over as chair of the meeting.


The chair did a quick walk-through of the current documents of the DNSSEC working group, and listed their status.

ar-00 DNSSEC Authentication Referral Record.
- Remove this from the agenda. If TISLabs want it to reappear, they should resubmit it.

- The document is supposed to get review from the routing area. This "needs to happen". James got the action to make this happen or make sure someone else takes on the job.

- The author is to resubmit the document either to DNSOP if it's real, otherwise to DNSIND.

- This document describes how to find a key if it's not in the DNS. This document need revision. Inherit it into DNSIND.

- Secret key establishment for DNS (TSIG) Wait for TSIG, then push it forward. Inherit into DNSIND and resubmit.

- Intermediate secure DNS failures. What happens when resolving host finds a security failure, and what to communicate to the end client. Inherit into DNSIND and resubmit.

- What happens when whole zone need re-signature with a new key. Inherit into DNSIND and resubmit.

The following two documents are treated together.

- This documents describes how to do secure domain name updates based on SIG records. It updates existing RFC 2137.

- This documents describes how to do secure domain name updates based on TSIG records.

Donald Eastlake, author of update2 commented that he will change and update the update2 document and make it simpler.

Conclusion: Inherit to DNSIND, revise the two and progress both.

- Inherit into DNSIND. Needs to be resurrected.

In all cases of documents to be inherited, the authors are requested to resubmit it, with possible revisions, before the working group takes action.

IF a merge between DNSSEC and DNSIND happens, the mailing list for DNSSEC will be closed down.

Paul Vixie made an announcement:

BIND 8.2 was just released. f.root-servers.net is running it. It uses less memory, and is faster.

Brian Wellington presented changes in simple update document.

Policy for processing SIG records.

- This allows off-line zone signing and key roll-over.

The DNSIND WG will meet at the upcoming IETF meeting in Oslo, Norway.


None received.