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 Next Items 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 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: Michael Patton 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 dns-dynupd-testing@lists.tislabs.com 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) 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. (diagram) 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 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. Solutions: 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 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.