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
Olafur Gudmundsson <firstname.lastname@example.org>
Randy Bush <email@example.com>
Internet Area Director(s):
Thomas Narten <firstname.lastname@example.org>
Erik Nordmark <email@example.com>
Internet Area Advisor:
Erik Nordmark <firstname.lastname@example.org>
To Subscribe: email@example.com
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:
Advance RFC2052bis to RFC.
Advance RFC1996 for Draft standard.
Advance TKEY and IANA considerations for IESG consideration
SIG(0) advanced for IESG consideration
RFC1995bis and AXFR advanced for Proposed
RFC2136bis advanced for Proposed standard
IXFR (RFC1995bis) interoperabilty testing complete
Serial Number Arithmetic, Notify and DNS Clarify advanced to Draft Standard.
RFC1611 and RFC1612 status chaned to historic.
RFC2308bis advanced for IESG consideration.
Secure update completed and ready for IESG consideration
Request that TSIG be advanced to Draft Standard
Revised DNSSEC submitted for advancement to Draft Standard
Request For Comments:
A DNS RR for specifying the location of services (DNS SRV)
Secret Key Transaction Authentication for DNS (TSIG)
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
- For advancement to Draft Standard
- SRV Interoperation testing needed
- Notify needs minor technical changes
- IXFR interoperation testing needed
- Neg Caching interoperation report needed
- Advance AXFR clarify & Msg Size to Proposed Standard
- retire SNMP RFC's to historic: Rob Austein to write up
- continue clarify and simplify off DNSSEC.
- Advance other lower priority items
- A few new items
- Message Size document by Olafur Gudmundsson
- GSS API Stewart Kwan
- DNSSEC awareness ENDS option David Conrad
- EDNS0.5 (Austein & Alvestrand)
- DNS Server expectation & clarification document:
- DNS Resolver expectation & clarification document:
(needs author, contact Olafur)
Knocking on the door
- DNSSEC Roadmap Glen Rose
- NO Record (NXT replacement)
- Multicast DNS
New Charter Items
- Multicast DNS
- local link scope and/or enterprise wide
- IDN - being handled in a separate WG, but DNSEXT will handle all DNS protocol changes. Possibilities include:
- new label types
- EDNS flags, EDNS options
- New record types
- Chair has dropped hints in IDN working group, that teams creating new solutions SHOULD use EDNS and leave DNS header alone.
Bill Manning: IETF 48 Interoperabilty Notes (Slides)
Cisco, CheckPoint, Lucent, Microsoft, Nominum, NAI Labs, hosted by ISI
Items to test:
- NCACHE & SRV have test suites
- All other testing was ad-hoc
- NCACHE - three interoperable versions and may proceed to Draft Standard pending some clarification
- All SRV implementations passed XFR, RELOAD, and compression Ad-hoc testing
- EDNS0 worked between two implementations in one direction
- SIG/KEY/NXT would pass between all implementations but did not share assumptions
- Two parties tested some TSIG with limited success
- Three implementations have working client & server code for IXFR
- We should:
1) construct an online testbed,
2) formulate standardized test suites, and
3) have scheduled testing sessions
- people interested in testing implementations should subscribe to the testing mailing list firstname.lastname@example.org
IXFR Last Call
Bill Manning: some implementor concerns, to be provided in last call period
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.
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.
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)
- Levon Esibov (LE): draft-dnsext-gss-tsig-00.txt
- Original draft submitted three years ago.
- Authentication between clients and servers as well as between servers.
- Generate shared secret key using TKEY & GSSAPI.
- Then authenticate using TSIG & GSSAPI.
- Draft does NOT cover authorization of DNS requests.
- GSS-TSIG developer need not develop a security infrastructure, just piggy backs on GSSAPI infrastructure.
- Security mechanism independence since its accessed via GSSAPI.
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,
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
- Levon Esibov (LE). Some requirements come out of zeroconf.
- Will talk about what the draft isn't.
- Goals: resolve when no DNS server or no DNS server that hosts all the local names.
- Not service location. Not a substitute for dynamic DNS.
- Not for use on global Internet or in Enterprise nets.
- For home/ad-hoc networks and the like.
- Query under lcl.arpa to link-local scope for IPv4 or IPv6.
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.
- Everyone does ENDS0.
- Client can indicate it doesn't want DNSSEC.
- Forget DNSSEC?
BIND v9 uses the AD bit in the query for this purpose.
Pro: Does not require EDNS0, really simple.
Con: Uses a scarce bit, doesn't promote EDNS0
Con: May screw up caches/forwarders
Use a bit in the EDNS0 header
Pro: Doesn't use a scare bit, simple, encourage EDNS0
Con: Disadvantage of requiring EDNS0
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.
DNS Security Document Roadmap
IETF 48 Interoperability Notes