Subject: draft IETF-50 DNSEXT meeting notes

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 9 Apr 2001 11:08:57 -0400 (EDT)

please send in comments by 2001/4/13
presenters please send in your slides ASAP if you have not done that
thanks
	Olafur (DNSEXT WG co-chair)

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.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 9 Apr 2001 21:08:00 -0000

djbdns grabs every record in the packet. BIND grabs every record in the
answer section.

Both of these approaches work. There's no dispute about this. The server
doesn't provide any authority records or additional records. (TSIG is an
exception, but the server doesn't use it except upon request.)

The BIND company is trying, through its ``AXFR clarification,'' to
prohibit the working djbdns behavior: ``Slaves MUST ignore any authority
section contents [and] any unexpected RRs in the additional section.''

This draft is in clear violation of RFC 2119, section 6, which says that
words such as MUST and SHOULD ``must not be used to try to impose a
particular method on implementors where the method is not required for
interoperability.''

The BIND company is misrepresenting the issue by asking ``Where should
AXFR records go? Entire packet or answer section only?'' Everyone agrees
that the _server_ is broken, and is violating the protocol, if there are
records in the authority section; but that's not the issue. The draft is
imposing unjustified restrictions on the _client_ behavior.

---Dan

---

From: [email-masked]
Date: Tue, 10 Apr 2001 15:07:51 +1000

The reason for saying to ignore the authority and additional
	sections is to allow the protocol to be expanded in the
	future without breaking things.

	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 10 Apr 2001 15:04:35 -0400

>section contents [and] any unexpected RRs in the additional section.''

Utter nonsense, Andreas is the editor of document for the working group,
if he was in any way trying to create a market opportunity for someone,
Randy and/or I would find another editor, period.
Andreas was drafted by me to write this document because of his skills,
knowledge and ability to express protocol issues clearly.
The goal is to write a extension to RFC1035 helps future developers in
writing AXFR code that interoperates with all implementations without
having to do the low level checking you had to do when you implemented
your code.

>particular method on implementors where the method is not required for

If there are slave servers that ignore data outside answer section then there
is an interoperabilty problem.

         Olafur (DNSEXT co-chair).

---

From: Sam Trenholme <[email-masked]>
Date: Tue, 10 Apr 2001 16:30:00 -0700 (PDT)

> having to do the low level checking you had to do when you implemented

On a similar vein, I would love to see a document which clarifies the
QDCOUNT issue.  In other words, a formal document that states "QDCOUNT
should be 0 or 1, otherwise you will not be able to send queries to 99%,
if not all, of the DNS servers out there".

I also have some ideas about how to allow binary strings to be in DNS
queries without having to worry about case folding.

- Sam (Who is, these days, spending too much time actually implementing
       DNS to have time to write up a draft right now)

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Apr 2001 22:42:43 -0000

> 	future without breaking things.

You are demanding that thousands of sites make changes to their working
servers, yet you claim that you're trying to avoid ``breaking things''?

It's fifteen years too late to start adding new forms of extensibility
to the AXFR protocol. We have an installed base now, and you have no
right to break compatibility with the installed base, even if you drop
the pretense that you're merely ``clarifying'' the existing protocol.
If you want a new protocol, use a new port.

---Dan

---

From: [email-masked]
Date: Thu, 12 Apr 2001 01:04:00 +1000

> servers, yet you claim that you're trying to avoid ``breaking things''?

	No.  I'm not demanding that any servers be upgraded.  I'm
	saying don't ship code in *future* that caches the authority
	and additional sections of a AXFR.  Natural attrition will
	take care of the existing servers.

	Old code does get replaced, usually when the machine dies
	or the OS is upgraded to the next release.  You can eventually
	make things the default that when you first started doing
	it you needed to be cautious to ensure that both ends were
	capable of handling otherwise thing broke badly.

	I seriously doubt we will ever use those sections for
	anything other than signing the AXFR stream.  However if
	there is another use found for them then I want to minimise
	the damage caused if such a AXFR stream is sent to a server
	that does not understand it.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 12 Apr 2001 08:35:13 -0000

[email-masked] writes:
> However if there is another use found for them then I want to minimise
> the damage caused if such a AXFR stream is sent to a server that does
> not understand it.

You're demanding that my users and I go to extra effort so that you can
someday run an incompatible protocol on the same port. This is absurd.

> Natural attrition will take care of the existing servers.

Natural attrition? You mean security holes that force people to upgrade?
Sorry, Mark, but my DNS implementation doesn't have that feature.

I've seen servers run for several _years_ without a software upgrade.

---Dan

---

From: [email-masked]
Date: Fri, 13 Apr 2001 10:09:48 +1000

> someday run an incompatible protocol on the same port. This is absurd.

	I'm not asking your users to do a single thing.  I'm asking
	you to change the way your server caches messages recieved
	on a AXFR stream.  I'm asking you to do something that
	would have taken less time to do than the time spent arguing
	over doing it.  I'm asking you to do something will have
	no impact on your existing customers.  I'm asking you to
	revisit the decision you made to cache all sections of a
	message and not just the answer section when you must have
	known that only the answer section was involved.  If I
	remember correctly you asked about what sections the answers
	went in and you were told only the answer section.

> Sorry, Mark, but my DNS implementation doesn't have that feature.

	Dan I meant what I said.  If you don't understand the phrase
	"natural attrition" look it up.

> I've seen servers run for several _years_ without a software upgrade.

	So have I.  I'm taking the long view on this issue as well.

	Mark

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 12 Apr 2001 15:45:28 -0400

> someday run an incompatible protocol on the same port. This is absurd.

I don't know where you get off calling this "incompatible"; the use of
Authority and/or Additional sections in AXFR transactions for proprietary
extensions was never blessed or encouraged by an RFC. Anyone who
implemented such a thing did so at their own risk. We can't put standards
into stasis just because folks sometimes exploit the vagueness and/or
incompleteness of prior specifications, and then complain that it's too
hard to change their code or for their user base to upgrade. If you want to
minimize the possibility of having to change your code *EVER*, then stick
with the absolute most conservative interpretation of the RFC's that you
possibly can. Stuffing proprietary junk into AXFR Authority and/or
Additional sections does *not* strike me as a conservative interpretation
of RFCs 1034 and/or 1035. In fact, it strikes me as borderline reckless.

- Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: 13 Apr 2001 02:55:02 -0000

Kevin Darcy writes:
> stick with the absolute most conservative interpretation of the RFC's
> that you possibly can. 

The existing standards do not say ``read only the answer section.'' They
also do not say ``read the entire packet.'' Both methods work. Neither
method is ``most conservative.''

I chose the simpler method. The BIND company, in violation of RFC 2119
section 6, is trying to impose the other method.

> Stuffing proprietary junk into AXFR Authority and/or

I'm not putting anything into the authority section.

The BIND company is saying that _they_ might want to put things there.
They know that this won't work with some existing standards-compliant
servers. They are demanding that those servers be changed.

Kevin, you seem to have been fooled by their misstatement of the issue.
The issue is _not_ whether the server is allowed to put anything into
the authority section. We all agree that, if records appear there, the
server is violating the protocol.

The issue is whether the _client_ is violating the protocol by accepting
those records. Right now there is no prohibition on this. The BIND
company wants to prohibit it. I object.

---Dan

---

From: Brian Wellington <[email-masked]>
Date: Fri, 13 Apr 2001 11:31:18 -0700 (PDT)

> section 6, is trying to impose the other method.

Funny, when I implemented AXFR in a non-bind product, I chose to only
parse the answer section, because it was simpler.

Apparently the DJB company has a different view of simple.

> I'm not putting anything into the authority section.

And no one else is either.  So changing your software to only parse the
answer section would have essentially no effect except making it more
compliant.

> servers. They are demanding that those servers be changed.

No, individual people with many years of DNS experience are saying that
there may be protocol extensions in the future.  There have been
extensions before, and there may be again.

> company wants to prohibit it. I object.

This argument is going nowhere, since you're blatantly refusing to accept
that you're wrong.  Servers don't put any records in the authority section
anyway and this would be a 5 minute change to djbdns with no adverse
effects.

In the time it will take you to respond and disagree again (which I'm sure
you will), you could have fixed djbdns.

And there is no 'BIND company'.

Brian

---

From: Sam Trenholme <[email-masked]>
Date: Sat, 14 Apr 2001 01:25:03 -0700 (PDT)

[note from moderator: this will be the last post dealing with this issue]

While this debate is very quickly becoming a pointless argument, since I
am in the middle of the process of implementing a DNS server, I would like
to bring my two cents in to this debate.

First of all, here is the patch, which, when run against axfr-get.c in
version 1.05 of DjbDNS, makes axfr-get no longer consider records outside
of the answer section authoritative:

354a355
>     uint16_unpack_big(out + 6,&numanswers);
361c362,363
<     while (pos < packet.len) {
---
>     while (pos < packet.len && numanswers) {
>       --numanswers;

This patch has been tested against my "tuzona" zoneserver (included with
MaraDNS) modified to put some records in the "additional" section, and is
verified to work.

Second of all, even if Dan integrates this patch in to DjbDNS, and
releases this patched DjbDNS tomorrow, and encourages all users to use a
version of axfr-dns so patched, there will still be many machines out
there using the previous axfr-dns.

In light of this, I do not believe we should make this draft a RFC without
taking in to account the reality of thousands of DNS servers which
consider authority and additional records part of a zone.

There are ways to handle this situtation which do not affect
interoperability.

One is to require that records in the authority and additional section be
records that are deliberately "out of baliwick" records.  In other words,
we can create a special TLD called "ignore-me" (for example), and add this
suffix to the end of the domain labels.  Since axfr-get silently discards
any hosts with names not part of the zone being transferred, these zones
will be ignored by axfr-get.

For example, if someone suddenly decided that we should have NS records in
the authority seciton during a zone transfer, and was transferring the
zone example.com, the data for a single record would look like this
(dig-style output):

;; ANSWER SECTION:
host.example.com.		1H IN A 	192.168.99.99

;; AUTHORITY SECTION:
host.example.com.ignore-me.	1H IN NS	ns1.example.com.
host.example.com.ignore-me.	1H IN NS	ns2.example.com.

BIND will ignore these entries because they are not in the answer section.
Unpatched version of axfr-get will ignore these entries because they are
not part of the example.com zone.

Any new zone transfer client that wishes to use these records can truncate
the "ignore-me" before processing the records in question.  End of
interoperability problems.

Since the RFCs which currently exist do not specifically forbid adding
authority and additional records to a zone, I feel it did not "break the
spec", as the spec exists today, to have written clients which add these
records to a zone file.  On the other hand, it is not very difficult to
patch the existing software to have behavior more consistant with the
behavior specified in the proposed draft.

- Sam