Subject: DNSEXT IETF-50 WG minutes (final)

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 12 Apr 2001 23:42:48 -0400 (EDT)

IETF 50 DNSEXT minutes 
Note-takers: Matt Larson, and Donald Eastlake
Editor: Olafur Gudmundsson

Agenda bashing
Working Group status: OG (Olafur Gudmundsson)
- Lots of documents: two in RFC editors queue, one in author editing cycle, 
  IESG sitting on four, OG sitting on one, one waiting for IXFR interop report.
- 20 I-Ds: 5 new, 4 last call, 6 on IESG/RFC plate

Next steps:
- Write Dynamic Update implementation report and update RFC. 
- Rewrite DNSSEC
- DNS clarifications
- Update charter

New charter:
- No major changes, new milestones
  WG consensus is that this is ready to be forwarded to the IESG. 
- New model for advancing RFC's a person or an organization will 
  adopt an RFC and be responsible for interoperabilty testing. 

DNSSEC core editing:
- RFC 2535: difficult to read, split into:
  - architecture and design goals
  - terminology
  - protocol
- Many updates make it hard to follow
- Impossible to generate test plan from the document
- Collaborate with DNSOP WG on operational guidelines

RFC2535bis editors
- WG chair recruited Dan Massey and Scott Rose
  - Need small number of people to be on Editors list to review drafts
  - Charter: combine RFC2535 and subsequent updates
  - Only include updates from existing RFCs or I-Ds
- Donald Eastlake to edit KEY documents
- Brian Wellington to edit secure Dynamic Update document
- Time line for DNSSEC editing
	2001/04/15 Outline of new documents posted to namedroppers
	2001/05/15 First drafts posted
	2001/06/15 Revised drafts posted
	2001/07/15 First WG last call on documents
	2001/10/15 Documents advanced to IESG
	2002/06/15 Documents and Interop report sent to IESG for advancement
		   to draft standard. 

Eric Nordmark (AD) questioned if all specs are currently (or soon)
proposed standard the need to recycle at proposed rather than go
directly to.  AD and WG-chars are to address this once the revised
specs are close to completion.

Working group documents: 
DNSSEC Roadmap: Scott Rose
Latest version is out.  Only comments are typos or editing things.
Still being pushed through last call unless anyone has any objections.

AXFR Clarify: Mark Andrews impersonating Andreas Gustafsson
Chair commented that discussions on mailing list going from technical
to insults.
Mark Andrews conducted three straw-polls on the document. 
Do we want a negative answer returned if refusing an AXFR?
Resounding yes, (hum yes)

Preservation of zone content?  What you load in the zone is what is
transferred in the AXFR?  (or the difference between bind-8 and
bind-9). Bind-9 (preserve content has more support)

Where should AXFR records go?  Entire packet or answer section only?
Answer section only is supported. 
(hum for answer section only)

AD is secure: Olafur Gudmundsson
No comments on mailing list on this document. One comment from 
off-line: AD is secure should reflect first non-empty section.
(Right now says answer and authority)  Border case is negative answer, but
there are certain problems dealing with CNAME or DNAME chains--any chains.
How about: should cover the answer section, if answer section is empty
covers authority.
(hum in agreement)

NO record: Simon Josefsson OG: Simon is not here.  
Minor discussion on this on the mailing list, which is interesting,
because this is a big question in front of us.  NO has certain
properties that some people and organizations don't like.  NXT is
disliked, NO is not as universally disliked.  Main argument against
changing is we have some experience with NXT and no chance for
interoperabilty with NO any time soon.  
The question in front of the working group is to 
	- Go with NO, 
	- go with NXT, 
	- drop authenticated denial completely?  

Lively discussion resulted, pointing out that even if NO sucks less
than NXT the cost of deploying it is higher (no software, longer
names) and there is no real experience either way. 
Rob Austein proposed that the working group try on the mailing list to
come to a consensus on if authenticated denial is needed. 
Some questions if NO should be published as experimental, and there is
support for that and to try to get some operational measures on how
NXT and NO compare. 

Inverse query obsoleted: David Lawrence
The consensus of the meeting was that it is a good idea to document
that IQUERY is a bad idea and why. Further more that implementors
should remove it from any future releases.

DNSSEC Opt IN: Mark Kosters
DNSSEC has scaling problems.  What is the best way to sign large zones?
Want to give a low cost of entry.  There's a big bang now for DNSSEC:
NXT records and NULL keys for unsecured subzones.  This is an idea of
how to do it in incremental fashion. Has low cost of entry.  An opt-in
idea.  Somewhat controversial--I realize that.  One way of solving the
big bang dilemma.  Read the draft to find out more. 

Some discussion on how this proposal and the proposal about storing
signatures for child keys in parent zone interact.

GSS-TSIG: Levon Esibov
LE (Levon Esibov): Quick status report on progress with GSS-TSIG.  Submitted
second draft in March 2001.  Made technical updates to clarify
ambiguities.  No outstanding issues that we're aware of. 
Currently two independent implementations: Microsoft and Lucent.
Foresee question on interoperabilty.  Few bugs to fix, few more to
fix before claiming interoperabilty. 
OG: Are those implementations in release products or products in testing?
LE: Lucent's is in beta testing Micorsoft is in a released product,
but there are some bugs. 

Unknown RR types: Andreas Gustafsson
MA: Never saw this as a controversial draft.  Do people think we should
continue to go forward as standards track? 
OG: This is standardizing a presentation format of unknown types, forcing
implementations to support unknown types in the future and load them.
It's surprising this is not specified in the original spec.
OG: Sense for last call?
(positive hum)

Zone and View options
Two drafts now, used to be one, Zone allows specific data from one
side of a zone cut, VIEW is specific to BIND 9. 
Zone goes standards track, VIEW would be informational.
OG: I don't think either one is controversial.  Should move ahead to last
call. NO objections.

EDNS handling unknown: Mark Andrews
EDNS0 didn't specify default handling of unknown options.  This splits
the option space so that a server has a better chance of proceeding
forward if an option is really optional vs. the server has to do
something special with it. 
Olafur: Trying to do something that EDNS0.5 was trying to address in a
much more narrow manner.
Harald Alvestrand (HA): I'd like to check the sense of the room on whether
or not something in this space is needed?  I think that it is.  We are
currently fielding about between 5 and 20 DNS extensions with various
flavors, we need  something 
Does the group agree?
(positive hum)
Mark: Want some way to sort out the option space, just which way to do it.
One or other of these (this or 0.5) has to die.

DHCID RR: Mark Strapp
MS: DHCID RR drafted for a little while now.  Specifies information for of
use with one population of DNS clients that are important users of the
DNS update protocol, in particular, in many DHCP environments, more
than one DHCP server allowed to make updates on behalf of clients.
May also be clients allowed to do their own updates. Need to coordinate
useful information among some population of updaters. 
Would need some out of band mechanism.  Only reasonable place for data
to go is in the DNS. This is a hash of the identifier and the FQDN.
Haven't seen any response since most recent publication.
OG: Is the doc ready for last call in your opinion?
MS: Yes, it's stable.
OG: I'll issue a last call after the meeting.

NIST DNSSEC implementation testing: Scott Rose SR: 
NIST is starting a performance test of DNSSEC.  Hoping to get a large
repository of statistics and a set of tools: workload generation,
stress testing.  Have email drop point and ask for anybody's help.
Interested in number of queries and types of queries.  Generate
traffic and feed it to various implementations.  Please contact Scott
if you have statistics and want to share them.  If you have
implementations that do DNSSEC, we'll take those, too, if you want us
to beat on them with the workload generation tools.  We won't issue
any certification, but we'll test interop.  Tools will be made
available.

Child SIG at the parent: Miek Gieben (MK)
These advantages:
- Makes key roll-over scale
- Reduces involvement of child zone DNS admin
- Make an unscheduled key roll over possible

DNSSEC resolver must be aware of this change.  Have somebody working on that
right now. 
Some discussion on the protocol and authority implications if SIG data
(and possibly KEY RRs) are stored in parent.
Miek is to update his draft and submit it to dnsext for discussion,
possibly trying to eliminate the NULL KEY definition in parent. 

NGTRANS requirements/IPv6 DNS operational needs: Alain Durand
AD: Follow up to what happened in DNSOP.  Started in San Diego at IETF 49.
NGTRANS asked by Area Director to specify some needs.
Yesterday, RB asked would this partition the DNS?  Now I'm presenting this
update, which is just an example.  Need a IPv6/IPv4 translator. 
Fall back translator: "last resort" solution when an IPv6 record is not
available to an IPv6-only DNS server
- Only accept IPv6 queries
- Would force RD bit off
- Forward queries in IPv4

- Fallback translator discovery?
- Integration of fallback mechanism in IPv6 DNS resolver?

IPv6 DNS transition and deployment: Rob Austein
- Problems: two complete IPv6 DNS Address record solutions
  - One standard, other deprecated
  - Known implementations using deprecated one
  - Becoming issue for IPv6 deployment
- Concern about complexity and scalability
- In untenable place.  Need to have something, rough consensus.
- Haven't made a strong case for the need for advanced features.
- Simple stuff "optimized for reads"--assume people look things up more
often than writing.  New stuff looks like it's optimized for writes.
- Proposed approach
- Already got AAAA deployed.  Can wave magic wand and make it go away.
Vendors seem to care about stub resolvers, don't want to replace the
stub resolvers. 
- Need to have transition plan to get from AAAA to A6.  Will require
protocol things, like synthesizing AAAA records.
- Need to make a case for A6 ("Case for A6" document)
- Need to do this soon, try to get it done by London
- Why A6 is worth keeping 
  - Provides features that AAAA can't do: nice to split the address in two
    pieces
    - Other issues like rapid renumbering
- If we find we need A6, it will be too late.
- Rob recommends using "degenerate" case (no chaining) form of A6.
- It's a paranoid thing to implement now in case we might need it.
- Overview of A6 transition plan
  - Use A6 in zone files
  - Anything that needs AAAA is assumed to be stub resolvers and we
    synthesize it
  - No AAAA in root or TLD zones
- Binary labels
  - Proposal: punt 'em
  - Get a FORMERR if any implementations it passes through don't understand
    it
  - Doesn't provide any fundamental new features
  - Have DNAME to assist
- DNAME
  - DNAME provides ways to do things that would be difficult to do things
    otherwise
    - For example, moving the entire ip6.int to ip6.arpa
  - Write strong text to say only use this if nothing else will work

Discussion on if there is need for the the case for AAAA as well,
conclusion was that the case for A6 should compare both. 

Discussion if it is reasonable to expect AAAA to die or if we will end
up with both forever, some comments about the capabilities or lack
there off in stub resolvers, AAAA might be retained as a meta query
forever. Chair to send out message about transition plan to all
relevant mailing lists.

(missing name) from FRNIC requested show on hands on the question how
many people thought killing A6 would speed up deployment of IPv6, few
hands raised. 
Some discussion on that existing base has not found any problems in
using AAAA, rebuttal was that IPv6 is not yet deployed in the large
networks using DNSSEC that motivated A6. Consensus was that there was
need for a study and report on this issue, chair is to facilitate that
by next IETF.

IPNG DDDT/DNS Discovery Discussion: Dave Thaler
- Problem is to enable a host to do name resolution in the absence of a DNS
  server, i.e., a zero-conf environment. 
  - Need to know:
    - 1 or more DNS server addresses, domain name, search list
  - Scope of discussion
    - Only discover information you need to know within the local site
     - Goal of team: discuss pros and cons and provide an analysis and
       recommendation
Bill Manning: I've done anycast service discovery and found OPCODE QUERY
  problem. Made proposal for a new OPCODE called DISCOVERY.  We're
  re-casting the I-D  we wrote about it.  Consider looking at
  DISCOVER: supports many answers better than QUERY.
Long discussion on the assumption that DHCP server is not needed,
given that hosts need more information about their information. 
Final document will live in IPng unless there are DNS protocol changes
needed, authors want to avoid protocol changes if possible.

ECC KEY record type: Donald Eastlake
- Describes new KEY and how to do an ECC SIG.  Gives specific format
  for a SIG for ECC.  Since SIGs specify a DNSSEC thing and not a
  general thing, Olafur will recommend that it be removed.  We also
  recommend text to discourage implementation in DNSSEC.
OG: This draft is explicitly requesting to be an official WG item.  I have a
  problem with defining a SIG format: people will start using it and
  lead to interoperabilty problems.  Have strongly recommended anything
  expect no signature format is defined. 
  What is consensus of the room on adopting this draft ? 
  (strong hum, no against)
OG: Should we adopt without signature definition?
   (no consensus)
Suggestion to advance the document for experimental status. 

Do not update TLD's,Levon Esibov
        draft-esibov-dnsext-dynupdtld-00.txt
Esibov: Don't send any updates to root or TLDs since they are being
	inundated with updates from some software.
Discussion: What about com.au. and other third level zones with the
	same problem?  How about a special label "_no-update" whose
	presence would indicate that no updates are accepted by a zone?
More discussion of alternatives on list needed.

Top Level private label name Levon Esibov 
	draft-coffeystrain-dnsext-privatednstld-00.txt
Proposes .pri as a private zone.
Discssuion: mixed.
Narten: Must co-ordinate with IANA.
Conclusion: Further discussion and bureaucratic steps needed.

Label management proposal Michael L. Macgowan Jr.
draft-macgowan-dnsext-label-intel-manage-00.txt
Not discussed due to lack of time.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.