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

Lawrence ConroyRoke Manor Researchlconroy@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

8th November 2005 Lawrence Conroy Ietf64-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

8th November 2005 Lawrence Conroy Ietf64-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

8th November 2005 Lawrence Conroy Ietf64-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

8th November 2005 Lawrence Conroy Ietf64-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…

8th November 2005 Lawrence Conroy Ietf64-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

8th November 2005 Lawrence Conroy Ietf64-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

8th November 2005 Lawrence Conroy Ietf64-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