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

1
EDNS0 - the need for speedltdraft-conroy-edns0-00.
txtgt

• Lawrence Conroy
• Roke Manor Research
• lconroy_at_insensate.co.uk

This draft has been produced by Lawrence Conroy
(lconroy_at_insensate.co.uk) and Jim Reid
(jim_at_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

3
Heads Up!

• From experience, there are a number of ENUM zones
  with data that wont 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
Whats 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, dont switch
  off the configuration option

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

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
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 havent 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