1. EDNS0 - the need for speed Lawrence Conroy Roke Manor Research lconroy@insensate.co.uk This draft has been produced by Lawrence Conroy (lconroy@insensate.co.uk) and Jim Reid (jim@rfc1035.com) - please complain to them at these mail addresses, or on the ENUM listlconroy@insensate.co.ukjim@rfc1035.com

2. 8th November 2005Lawrence ConroyIetf64-lwc: 2 Topics  Heads Up! - EDNS0 needed for ENUM  What is in it? - for the hard of reading  Issues  What is Reasonable? - size matters  Why This Matters to You - Actions/Requests

3. 8th November 2005Lawrence ConroyIetf64-lwc: 3 Heads Up!  From experience, there are a number of ENUM zones with data that won’t fit into “RFC1035 basic” messages –This is true for ANY queries, as well as NAPTR-specific ones –For ENUM (a.k.a. “user” ENUM) this is unlikely to go away –For “carrier” or “private ENUM”, this will also be a problem  Supporting a significant chunk of queries using TCP is: –Slow, due to delayed TCP fallback –Generates much more network traffic –Places major load on DNS servers that are not designed for it –For most TCP stacks in servers, limits rate of responses  Solution - use EDNS0 (RFC2671) with Size Option set

4. 8th November 2005Lawrence ConroyIetf64-lwc: 4 What’s In It?  Resolvers (both “Stub” and “Recursive”) will send EDNS0-aware queries with the size option set to a reasonable value –This just consists of tagging 11 fixed octets onto the end of a request, and bumping a counter in the query to 1 - hardly rocket science  All DNS Servers queried in an ENUM resolution need to respond to such EDNS0 “sized” queries –As an aside, the root servers and those responsible for.arpa. and.e164.arpa. do this already, so this means that all ENUM “Tier 1” and “Tier 2” servers must be configured to support the EDNS0 size option - basically, don’t switch off the configuration option

5. 8th November 2005Lawrence ConroyIetf64-lwc: 5 Issues - I  A DNS server holding RRsets larger than will “fit” in an “RFC 1035 basic” UDP response and that does not respond to queries using TCP is broken/misconfigured –The “fallback” mechanism in RFC 1123 and in RFC 2671 (EDNS0) implies that TCP is used - if the server does not support this, there is no way to resolve the query. This is true with or without EDNS0 support  Supporting EDNS0 will avoid using TCP for most queries, and will improve performance for ENUM queries that exceed the “RFC 1035 basic” size, but…

6. 8th November 2005Lawrence ConroyIetf64-lwc: 6 Issues - II  The intervening network may have a small MTU, and so EDNS0-aware responses MAY result in fragments –This is an obscure point, but it is both Bad and Wrong for a DNS server or intermediate node to assume that fragments will never occur for DNS messages carried over UDP transport  Of course, anything “in the middle” should not break valid DNS queries –This is “stating the obvious”, but it does warrant a reminder From painful experience, it is hard to debug such brokenness

7. 8th November 2005Lawrence ConroyIetf64-lwc: 7 What is Reasonable? - size matters  This draft mandates EDNS0 Size Option support and use  It does not specify what the minimum reported size should be in such ENUM queries  In the authors’ humble opinions, this is an operational advice issue, and so is a suitable subject for the BCP (Experiences) draft - i.e. there is no deterministic answer –(our bet is 1280 bytes, but YMMV - comments welcome) –As an aside, over time this may need to increase, as support for the OK bit (and DNSSEC) introduces larger responses

8. 8th November 2005Lawrence ConroyIetf64-lwc: 8 Why This Matters to You - Actions/Requests  Please can this be made an ENUM WG draft and progressed rapidly on the standards track  Please can we get DNSOPS gurus to check this draft, to ensure we haven’t broken anything  IF this is done, THEN we can up-issue the Experiences draft “one more time”: –To remove duplication in its section 6 (referring to this draft) –To insert discussion of appropriate minimum size option values