1 / 8

EDNS0 - the need for speed <draft-conroy-edns0-00.txt>

EDNS0 - the need for speed <draft-conroy-edns0-00.txt> Lawrence Conroy Roke Manor Research lconroy@insensate.co.uk

ostinmannual
Download Presentation

EDNS0 - the need for speed <draft-conroy-edns0-00.txt>

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EDNS0 - the need for speed<draft-conroy-edns0-00.txt> 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 list

  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 Lawrence Conroy

  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 Lawrence Conroy

  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 Lawrence Conroy

  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… Lawrence Conroy

  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 reminderFrom painful experience, it is hard to debug such brokenness Lawrence Conroy

  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 Lawrence Conroy

  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 Lawrence Conroy

More Related