2.3.2 DNS Extensions (dnsext)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

Chair(s):

Olafur Gudmundsson <ogud@ogud.com>
Randy Bush <randy@psg.com>

Internet Area Director(s):

Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>

Internet Area Advisor:

Erik Nordmark <nordmark@eng.sun.com>

Mailing Lists:

General Discussion:namedroppers@ops.ietf.org
To Subscribe: namedroppers-request@ops.ietf.org
Archive: ftp://ops.ietf.org/pub/lists/

Description of Working Group:

The DNSEXT Working Group has assumed the RFCs and drafts of both the DNSSEC and DNSIND working groups. DNS is originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are protocol issues, including message formats, message handling, and data formats. New work items and milestones may be added from time-to-time with the approval of the Working Group and the IESG.

Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of this Working Group's charter. These issues are considered in other venues, such as operational issues in the DNS Operations Working Group.
Broad topics under consideration in DNSEXT are dynamic update, notify, zone transfers, security and adjustments to address the requirements of IPv6 addressing. Security topics, mostly inherited from the erstwhile DNS Security Extensions Working Group, will be addressed in cooperation with the DNS Operations Working Group.
The principal task within this Working Group is to advance several documents describing proposed extensions to DNS. The current list of documents under consideration for advancement is:
Title RFC Status
DNS Server MIB Extensions RFC1611 Proposed
DNS Resolver MIB Extensions RFC1612 Proposed
Serial Number Arithmetic RFC1982 Proposed
Incremental Zone transfer RFC1995 Proposed
Notify RFC1996 Proposed
DNS SRV service location RFC2052 Experimental
Dynamic Update RFC2136 Proposed
Security for Dynamic Update RFC2137 Proposed
Clarification to DNS RFC2181 Proposed
Negative Caching RFC2308 Proposed
DNS Security Extensions RFC2535 Proposed
DSA KEYs and SIGs RFC2536 Proposed
RSA KEYs and SIGs RFC2537 Proposed
Storing Certificates RFC2538 Proposed
Diffie-Hellman Keys RFC2539 Proposed
Extensions to DNS0 RFC2671 Proposed
Non-Terminal DNS names RFC2672 Proposed
Binary Labels RFC2673 Proposed
Other specific work items are:
o TSIG - transaction signatures in (dnsind-tsig-xx.txt)
o TKEY - Secret Key establishment for DNS (dnsind-tkey-xx.txt)
o Securing dynamic update (dnsind-simple-secure-update-xx.txt)
o Protocol clarifications and corrections for DNSSEC (draft-ietf-dnsind-sig-zero-xx.txt) (draft-ietf-dnsind-zone-secure-xx.txt)
o Clarifications for IANA in DNS assignments (draft-ietf-dnsind-iana-dns-xx.txt)
o Documentation of the zone transfer protocol (AXFR)
o Retirement of DNS MIB's RFC's
New work items may be added from time-to-time with the approval of the Working Group and the IESG.

Goals and Milestones:

Dec 99

  

Advance RFC2052bis to RFC.

Jan 00

  

Advance RFC1996 for Draft standard.

Jan 00

  

Advance TKEY and IANA considerations for IESG consideration

Feb 00

  

SIG(0) advanced for IESG consideration

Feb 00

  

RFC1995bis and AXFR advanced for Proposed

Mar 00

  

RFC2136bis advanced for Proposed standard

Mar 00

  

IXFR (RFC1995bis) interoperabilty testing complete

Apr 00

  

Serial Number Arithmetic, Notify and DNS Clarify advanced to Draft Standard.

Apr 00

  

RFC1611 and RFC1612 status chaned to historic.

May 00

  

RFC2308bis advanced for IESG consideration.

May 00

  

Secure update completed and ready for IESG consideration

May 00

  

RFC2137 Obsoleted

Jun 00

  

Request that TSIG be advanced to Draft Standard

Jul 00

  

Revised DNSSEC submitted for advancement to Draft Standard

Internet-Drafts:
Request For Comments:

RFC

Status

Title

RFC2782

PS

A DNS RR for specifying the location of services (DNS SRV)

RFC2845

S

Secret Key Transaction Authentication for DNS (TSIG)

RFC2929

  

Domain Name System (DNS) IANA Considerations

RFC2930

PS

Secret Key Establishment for DNS (TKEY RR)

RFC2931

PS

DNS Request and Transaction Signatures ( SIG(0)s )

RFC3007

PS

Secure Domain Name System (DNS) Dynamic Update

RFC3008

PS

Domain Name System Security (DNSSEC) Signing Authority

Current Meeting Report

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

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

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.

Slides

Agenda
IPv6 DNS operational needs
GSS-TSIG
DNSEXT Status IETF-50
IPv6 DNS transition and deployment