Subject: DNSIND minutes - ietf minneapolis

From: Randy Bush <[email-masked]>
Date: Wed, 7 Apr 1999 19:56:16 -0700 (PDT)

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

		  Chair: Randy Bush <[email-masked]> (DNSIND part)
			 James Galvin <[email-masked]> (DNSSEC part)
	    Reported by: Lars-Johan Liman <[email-masked]>

#----------------------------------------------------------------------

INTEROPERABILITY TESTS

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.

TSIG

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.

DynUP

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:

DNSSEC 

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
  1) It makes recommendations on ways to construct names for devices
     with local IP addresses (not global recognised), and
  2) It makes recommendations on how to put names into the normal
     domain tree and have them resolve different ways depending on the
     address of the querying client.

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:
 *) We need to get in contact with IANA about registration of the
    new RR type.
 *) Should the IPv6 addresses be stored as AAAA or A6 format?
 *) The mask value should be 1 bit longer to be able to handle NSAP
    addresses.
 *) Is the AFDLENGTH really necessary?

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:
 *) How do the deletes happen in a timely manner?
    - interval timer?
    - exact timer (priority queue)?
    - on data lookup?
 *) Should deferred updates sent in the same packet be guaranteed to
    execute atomically?
 *) Should TTL modification be mandatory?
 *) Is relative time OK?
    - It doesn't require clock synchronization.
 *) Should there be a way to find a deferred delete?
    - 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.

#----------------------------------------------------------------------
#----------------------------------------------------------------------

DNSSEC ISSUES

#----------------------------------------------------------------------
#----------------------------------------------------------------------

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.

as-map-05
  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.

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

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

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

secfail-00
  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.

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

The following two documents are treated together.

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

simple-update-01
  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.

keyreferral-xx
  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.
 *) Non-DNSSEC SIGs are retained.
 *) SIGs generated by the zone key are verified, and retained if
    successful.
    -) This allows off-line zone signing and key roll-over.
 *) SIGs generated by other keys are dropped, and the data is
    resigned by the zone key.

#----------------------------------------------------------------------

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

#----------------------------------------------------------------------
# END OF NOTES