EDNS0 - the need for speed - PowerPoint PPT Presentation

Edns0 the need for speed draft conroy edns0 00 txt l.jpg
Download
1 / 8

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

Related searches for EDNS0 - the need for speed

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

EDNS0 - the need for speed

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Edns0 the need for speed draft conroy edns0 00 txt l.jpg

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


Topics l.jpg

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


Heads up l.jpg

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


What s in it l.jpg

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


Issues i l.jpg

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


Issues ii l.jpg

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


What is reasonable size matters l.jpg

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


Why this matters to you actions requests l.jpg

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


  • Login