Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/dnsind/dnsind-minutes-94dec.txt

Text File | 1995-02-28 | 8KB | 214 lines

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 <name,class,type> triple, or (2) replacement can
be further bound to only add/delete RRs that match given
<name,class,type,rdata>.

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 [e-mail]
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 [e-mail] 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.