CURRENT_MEETING_REPORT_ Reported by Randy Bush/RGnet Minutes of the DNS IXFR, Notification, and Dynamic Update Working Group (DNSIND) The DNSIND Working Group met twice at the 31st IETF on 6 and 7 December. Agenda o Agenda bashing o Working group charter review o Load balancing o Incremental Transfer o Administrivia: scheduling, dnssec coordination, draft status o NOTIFY draft status and discussion o Dynamic Update discussion o IPng DNS Specification o IPv6 address-to-name mapping o What to do about COM o Structure and scheduling of drafts Load Balancing and Incremental Transfer Thomas Brisco's Load Balancing draft is moving toward becoming an Informational RFC. The group has no objections to this. The code for it may or may not be in the next BIND, but will at least be in the contrib directory. Masataka Ohta presented draft-ietf-dnsind-ixfr-00.txt. It is very different from the previous proposal in that the server maintains no state about the client. There was general agreement on the approach, but more work is needed on the draft. Security issues need review. Status of the Dynamic Update Work Susan Thomson presented the status of the Dynamic Update work. Broadening the scope of the work has raised questions about requirements that need to be supported and consequent new design issues. Requirements and issues were enumerated and explored. Atomicity of Updates There was a question of whether to limit updates to records of a single name, class and type or support updates of records of more than one name, class and type. The consensus of the working group was to provide a more general mechanism to support operations such as atomic renaming. Another question was whether to support partial updates of a set of records of a particular name, class and type (by supporting add and delete operations) or allow just complete updates (by supporting only an overwrite operation). Partial updates are more efficient for large record sets and allow for more error checking, but are not as simple. The issue is whether (1) replacement happens for the entire set of RRs that matched a given triple, or (2) replacement can be further bound to only add/delete RRs that match given . Under an assumption of a test-and-set mode of operation, the group reached rough consensus that a hybrid approach was best: have the capability to do (2), but also provide a way of specifying wildcard RDATA to emulate (1). Node Creation and Update There are two kinds of update operation: one to create records with a new name and check that the name is unique, and one to update existing records. There is also a third mode of operation that allows one to create records with a new name and not have the operation check that the name is unique. Clearly, update of existing records and some form of creation of records need to be supported. Checking for uniqueness is necessary if multiple clients are allowed to create new records in a zone concurrently. There was a suggestion that all three modes be supported. Update Sequencing There is a need to ensure that updates are properly ordered (update requests can be misordered due to delayed, duplicated and misordered messages). There was a discussion about sequencing granularity: whether updates should be sequenced with respect to the entire zone or just the records updated. The former does not allows for as much concurrency as the latter. Allowing both modes of operation should be feasible. There are several ways to support sequencing: sequence numbers, time stamps and using a test-and-set mode of operation. In all cases, a new record type would be associated with records of a name, class and type, containing the current sequencing value. The test-and-set mode of operation can be supported using the partial update scheme above. Security Dependencies It was felt that the dynamic update mechanism should not depend in any way on the security mechanism, even though it is possible to use the update mechanism without necessarily having security be in use. Need for Expiration Time There was a discussion about whether associating an expiration time with records of a particular name, class and type is useful. Support for an expiration time would allow records to time out within a zone after some period of time, and ensure that the records TTL value is decreased appropriately. It was not clear that the value is useful given that a configuration service, such as DHCP, could be made responsible for deleting unwanted records. Dynamic Update Discussion Conclusions The DynUpd crew felt they had sufficient guidance to produce a new draft. They expect more input from the mailing list, please. There will be an interim meeting of the DNSIND Working Group specifically to progress toward a new DynUpd draft. This is likely to be 8 February, just before the IPng interim, in the Bay Area. Problems in the COM Domain Mark Lottor discussed problems in the COM domain. The COM domain is annoying in terms of size, trademark issues, etc. Write to mkl@nw.com if you are interested in the subject. Is there any carrot or stick or authority? IANA is acting, but cautiously. Some requirements are: o stop excessive growth of COM o eliminate single registration authority o maintain self-sufficient top-level registrar and root servers o discourage frivolous registration o allow more naming possibilities o work with existing DNS protocols and implementations o expandable and scalable o no forced name changes (grandfather existing) There is a proposal to sell the TLD space for $1k-25k per name with a yearly renewal of $1k. It was concluded that this should be taken to the bigz@isi.edu list. Use the -request address for subscription and removal requests. Other Business Paul Vixie described the status of the Notify drafting work. Problem statement: o SOA refresh cannot be granular enough without being either too small or too large o Would like to have slaves updated in more like real time o Do not add more security holes o Keep it simple, BIND is a wreck The content of the current pending draft was described and discussed. Susan Thompson put out an IPv6 DNS draft in October. Would this working group please read and review? The remaining issue is the address to name mapping. The IPng Working Group (IPNGWG) plans to make decisions about which drafts to move to standards track in the next couple of months, so timely review is appropriate. Surprise, multiple PTR records for the same address work. Paul Vixie hacked it into BIND recently. Robert Austein described a proposal for address to name lookup in the presence of non byte-aligned netmasks. It will work in IPv4. Michael Patton presented an address to name mapping for IPv4 which added PFX RRs to tell resolvers at which boundaries they should break to get the next delegation level. It was the general consensus that the current nibble IPv6 address to name translation was currently the safest. Masataka Ohta presented a case for allowing multiple primaries. Action Items o IXFR: Masataka Ohta will have a new Internet-Draft soon and plans for it to be an RFC in Danvers. o DynUpd: will have an interim meeting in late January or early February, with the plan to produce an new Internet-Draft in time for a cycle at Danvers. o Notify: Paul Vixie will publish a new draft in the next weeks, with the intent of becoming an RFC by Danvers.