2.2.1 DNS Extensions (dnsext)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00

Chair(s):

Olafur Gudmundsson <ogud@tislabs.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)

Current Meeting Report

3 August 2000, DNSEXT WG

Meeting run by chairs Olafur Gudmundsson and Randy Bush
Minutes by Donald Eastlake and Mark Kosters (thanks to both of you)
Edited by Olafur Gudmundsson.

Agenda Bashing: three additions, Levon Esibov on A6 dynamic update problem, David Conrad on "Got DNSSEC?", Donald Eastlake on RSA-SHA1.

WG Status was given by Olafur Gudmundsson (OG):

RFC 2845 "Secret Key Transaction Authentication for DNS (TSIG)" is out. The IANA DNS, TKEY, and Secure Update drafts have all three been approved and should be out as RFCs in not too long. Secure Update and Signing Authority are at IESG, minor text needed to added to Secure Update. APL is pending Area Director action to bring to IESG.

The IXFR draft is in WG last call.

RFC status: a list of all the RFC's within the WG's charter area was given with their status.

New Items: standards track

Next Items

New Items

Michael Patton

(needs author, contact Olafur)

Knocking on the door

New Charter Items

Bill Manning: IETF 48 Interoperabilty Notes (Slides)
Cisco, CheckPoint, Lucent, Microsoft, Nominum, NAI Labs, hosted by ISI

Items to test:

1) construct an online testbed,
2) formulate standardized test suites, and
3) have scheduled testing sessions

IXFR Last Call
Bill Manning: some implementor concerns, to be provided in last call period

AXFR Clarify
Andreas Gustafsson: (01 draft posted to mailing list because it didn't make it out before the IETF meeting)

Draft version 00 provides the long missing specification of AXFR. For example, multiple answer records are permitted, specifies header fields of multiple messages, specifies when a question section is required, states that AXFR begins and ends with just SOA not all apex data.

01 adds security considerations section and definition of glue. Purpose of AXFR is to copy zone including necessary and unnecessary glue as originally loaded from master file. This requires servers to store zones in separate structures so glue in one zone can be distinguished from authoritative data in other zones. (This has actually always been required.) It was noted by observation that one implementation of AXFR advertised its ability to accept multiple answers by appending the two ASCII characters "MS" to the end of its AXFR query.

EDNS0.5
Harald Alvestrand (HA): "To Make sure that IDN and other rabid adders of DNS features can get what they want done without damaging the stability of the Internet". Some discussion if this should be renumbered to be EDNS1 rather than ENDS0.5 no consensus. Question on what features should be enumerated, answer was only the ones t added since 1034/1035, and features that might be obsoleted or replaced.

Message Size

Olafur Gudmundsson: Current DNS restricts UDP answers to 512 bytes, DNSSEC & A6 answers are bigger and frequently need more space resulting in unnecessary TCP transfers, etc. EDNS0 provides a way to indicate readiness to receive a bigger answer.

This draft says that if you support DNSSEC or A6 your MUST support EDNS0. Minimum EDNS0 indicated MTU in draft is set at 1280 bytes. Next version will have 1220 or 1240 (IPv6 MTU is 1280 bytes and you need to subtract the UDP header size.) Will revise draft based on comments. Number people voiced opinions on the size, IPv6 people argue for 1024 to avoid fragmentation, DNS people argue for large number to maintain number of nameservers high.

Kazu Yamamoto (KY): EDNS0 is needed for IPv6. 512 bytes is too small. The root zone needs NS RRs +A/AAAA/A6 "glue". AAAA/A6 only meaningful for IPv6 transport ready resolvers Mandate EDNS0 for IPv6. No objections to this idea at IPng WG yesterday. This should be put in the IPv6 host requirements. Olafur and Kazu to bring issue on how to address IPv6 requirements up on the IPng mailing list.

Masataka Ohta (MO):Number of root servers is a DNSOP matter. Anycast is the answer. Five roots is enough using Anycast.

Bill Manning (BM) wants to see the calculations of packet size.

GSS TSIG (slides)

Some questions about performance implications and delays using this, compared to MD5 TSIG, no answers available at this time. Olafur mentioned that two other people are implementing this, in addition to MS, and this document will not leave WG until there are interoperable implementations.

Clarification on Zone Status
Ed Lewis (EL): Motivation is that RFC 2535 talks about securing a resolver, not about how a server secures itself. The server point of view is not given. If a server uses an obscure algorithm, it has done a bad thing in terms of getting its data securely into the hands of most resolvers. And administrator can leave a zone secured, can secure it as part of the secure DNS tree, or secure it and still not be part of the tree, depending on algorithm used, parental vouching, etc.

Changes this draft makes to RFC 2535:
1) Definition if a zone is secured or not secured. RFC 2535 says per algorithm. Changed to per zone.
2) Protocol octet in KEY has to be DNSSEC or ANY. RFC 2535 permits it to be zero in a KEY used for DNSSEC.
3) Dropping the "experimentally secure" status. If desired, it can be achieved in other ways, such as limited public key distribution.

An important point of this draft is to define "fully secured" and "privately secured". Probably "Fully" secured should be "Globally" and "Privately" should be "Locally". To be globally secure, it is required that your parent says you are secure. (If your parent isn't secure, then you have to give everyone who will trust you your public key in some secure fashion they will trust.)

This draft depends on the Signing Authority draft.

Gone from earlier versions of this draft is the NXT hack. That would have gotten rid of NULL keys. But operators indicate that these do not seem to actually be a problem.

Draft needs a further revision of the English, due to misunderstandings but non English readers.

Draft will go for WG Last Call after these revisions.

DHCID: DHCP needs a semaphore RR...
Want their own RR so DHCP servers can mark names so others will know who set them. They have tried to specify using TXT, SIG, and KEY to store the data they want in the DNS but those are misuses of RRs intended for other purposes. Lively discussion about the need for this and why DHCP people want this. The final consensus was that this is not a good idea but if DHCP wants to store some information to arbitrate between servers and/or clients this is harmless from DNS perspective.

NXT RR -> NO Record
Simon Josefson (not here) (Olafur gave a summary)
Uses hashes of names. List of integers instead of bit map.
Discussion to the list.
Question if this is extra work for WG and if it should be allowed in
Olafur: This can fit under the fixing of DNSSEC umbrella which is on the charter. Admit document as WG document,

DNSSEC Roadmap
Scott Rose

Purpose of the document is to help inform people about what it's all about and where it is. Similar to IPSEC Roadmap. First part lists documents and what they cover. Second part tries to give a unified overview of what it all means.

Document will have to be frequently revised and should stay as a draft for some time. Perhaps become an Informational RFC at some point. Might be extended to include all the DNS extensions...

Chairs: take it on, it's useful, keep it small and restrict to DNSSEC only (including TKEY and TSIG).

Multicast DNS (MDNS), draft-aboba-dnsext-mdns-01.txt

Number of comments, replace lcl.arpa with local.arpa. Stewart Cheshire of Apple has reserved an multicast Address for this purpose, question if zeroconf people are happy with link local only scope?

Anycast DNS, draft-manning-dnsext-mdns-06.txt
Bill x: Draft has been cut down to three pages. Study shows that traffic impact is not a problem. Comment that this is a problem in global networks with slow links, as scope off local is not restricted by many organizations. Number of questions on why an organization would want to do this as if it has infrastructure it most likely has DNS servers configured.

Add Multicast DNS to WG items ? (Olafur)
Comments included "Against taking this on because we get rat holed on multicast issues, not DNS.", "limit to link local", consensus was to accept both at this point for future work and be careful how these proposals grow.

A6 Dynamic update problem: (Levon)
Need technique for clients to find out prefix info for non-zero prefixes for A6 updates. No standardized way to find this out. Matt Crawford will take this issue up with IPNG wg.

David Conrad, Got DNSSEC?
Non-DNSSEC aware client can't say it doesn't want DNSSEC additional RRs including SIG and spontaneous KEYs.
So server will always send big packets which may result in unnecessary truncation and TCP transfers.
Solutions:

BIND v9 uses the AD bit in the query for this purpose.

Use a bit in the EDNS0 header

Use EDNS0.5
Pro: Doesn't use a scarce bit, encourages EDNS0, finer grained
Con: Requires EDNS0
New Denial of Service
Bad guy spoofs a response indicating the server does not support DNSSEC??
What to do?
It is late to make much change in BIND v9.0.0

Consensus was to add this to the working group tasks.

Donald Eastlake, RSA-SHA1.
If you are using RSA, most of the data in the DNS is probably adequately protected by the RSA-MD5 of algorithm 1 specified in RFC 2537. But MD5 is showing its age and the most sensitive root/TLD/etc. data deserves the protection of SHA1 and any better padding techniques that have been deployed for a while. The additional computation for SHA1 versus MD5, etc., is trivial compared with the main RSA modular exponentiation.

Mark Andrews and others: Not only should RSA-SHA1 be added, it should be MANDATORY to implement, and RSA-MD5 should be obsoleted. RSA SHA1 draft (to be submitted by Donald Eastlake) approved as a work item.

Slides

DNS Security Document Roadmap
GSS-TSIG
IETF 48 Interoperability Notes
Multicast DNS
Message Size-00
Progress Notes