ENUM Implementation Experiences

1
ENUM Implementation Experiences

• ltdraft-ietf-enum-experiences-04.txtgt
• Lawrence Conroy
• Roke Manor Research
• e-maillconroy_at_insensate.co.uk

2
Topics

• Changes to Experiences-04
• Summary
• Section 6 (General DNS Issues)
• Request for Publication
• Related Work
• Backup - Issues covered in Experiences
  document
• Characters/Character Set Support
• ORDER PRIORITY field values
• Non-Terminal NAPTRs (NTNs)
• General DNS Issues
• Backwards Compatibility

3
Summary

• Corrected Typos
• Expanded acronyms
• Changed some sentences to make them clearer
• Restructured Section 6 on General DNS issues

4
Section 6 - General DNS Issues

• Clarified why we need EDNS0 support and use
• Added size recommendations for EDNS0 support
• (Checked alignment with upcoming BIND 9 defaults)
• Intermediary Systems (SBC/Firewall/DNS Proxy)
  heads up Clarified
• Added clearer dont break DNS (TCP) or EDNS0
  and beware that some Internet access providers
  dont
• Added section on TTL and ANY (255) queries
• Note that this is a general DNS issue, but has
  been a problem for ENUM implementation (Many
  thanks for the debug reports)

5
Request For Publication

• This is as far as we should go for now, ready
  to roll
• Please read and Review
• it may help you avoid the pitfalls that others
  have encountered
• If there is an issue that is wrong, please holler
  now
• If it is right (but you didnt hit a particular
  issue), then lets leave it in there - others
  will
• Lets publish it
• An update can (and should) be created when we
  have more deployment experience, as seems likely
  with the number of Tier 1 Delegations popping up
  recently

6
Related Work

• EDNS0 is recommended here
• In practice, you will have problems if it is not
  supported
• Particularly over long pipes such as cellular
  access networks, using TCP fallback is painful,
  and will result in unacceptably long delays
  (seconds)
• Given that some territories regulate the maximum
  time before a call is placed, this may be a
  problem unless EDNS0 is available
• Parallel Effort to produce a document just for
  EDNS0
• Status is still under discussion with DNSOPS
  Reviewer (Lars-Johan Liman) to decide on
  capitalisation of MUSTs
• New version will be issued once this is completed

7
Backup - List of Issues Covered
8
Characters/Char. Set Support - 1

• ASCII-UTF8 - So what (and where)?
• REGEXP repl sub-field is only place where
  non-ASCII can occur. We strongly recommend
  against that, and suggest that URI/IRI escaping
  should be used.
• Character Case - Sensitivity needed?
• Again, repl sub-field is the only place where
  case sensitivity matters, as case of static text
  in this field should be used in URI. All else is
  case-insensitive.
• REGEXP i flag - Dont do it
• i flag has no required effect on ENUM NAPTR
  some clients dont expect it, so dont insert it
  into a NAPTR

9
Characters/Char. Set Support - 2

• REGEXP delimiter - should use !
• Some clients expect ! (as it is used in
  examples )
• character in REGEXP match sub-field - escape
  it
• The character may well exist in the match
  sub-field, it is the start of International
  format telephone number. It is a reserved
  character in REGEXP, so must be escaped with a
  preceding \ character
• printable ASCII characters only, please
• ENUM programs may need to present NAPTRs to end
  users - if a NAPTR contains non-printable
  characters, they cant, and may reasonably reject
  the NAPTR

10
ORDER and PRIORITY

• Use a fixed value of 100 for ORDER in ENUM NAPTRs
• NAPTRs within a zone should not normally have the
  same ORDER and PRIORITY field values. If these
  are received, process in the sequence they appear
  in DNS message.
• Process Enumservices in a compound NAPTR in
  left-to-right sequence
• Consider ORDER and PRIORITY values only within
  the current zone. Recalculate if entering another
  zone
• If Non-terminal NAPTRs are supported, then sort
  the NAPTRs in each zone separately

11
Non-Terminal NAPTRs (NTNs) - 1

• NTNs add code complexity and so are a difficult
  for small footprint devices, and many existing
  clients dont support them, so beware(but if you
  do want to use them, and you know that the
  clients will support them )
• Non-terminal loops can exist, must be
  detected/handled
• No chain of NTNs should be more than 5 deep,
  so traversing 5 zones automatically may be
  considered as a potential loop
• If you do detect a loop, do something about it!
• Abort processing the NTN that would cause a loop
  and continue with any remaining NAPTRs in the
  referring zone

12
Non-Terminal NAPTRs (NTNs) - 2

• NTNs - what they meant to say in the standards
• Note RFC 3402 section 3 and RFC 3404 give the
  option of using either the REGEXP or the
  replacement field to generate or hold a domain
  name - no ENUM client handles this, so dont
  provision NTNs with REGEXP field, as they will be
  ignored (at best )
• AFAICT, no DDDS client actually implements this
  (other DDDS applications do not need/use NTNs)
• ENUM NTNs have empty flags and services fields
• ENUM NTNs have a non-empty replacement field
  (holding the target domain to look for more
  NAPTRs), and so must have an empty REGEXP field

13
General DNS issues that bite for ENUM

• In practice, EDNS0 is needed
• Recommended reported size of 4000 bytes, with
  1220 as a bare minimum
• TCP should also be supported, as it is a key part
  of DNS resolution
• Beware Stupid Network intermediary nodes that
  disable TCP and/or EDNS0
• Dont do Stupid Network/Firewall/SBC/
  configuration!
• Times To Live must be the same for all NAPTRs in
  a zone
• Dont use DNS (QT255) ANY queries unless you
  are really sure what you are doing

14
Backwards Compatibility

• We Recommend ENUM client support both for old
  style (RFC 2916) as well as new style (RFC
  3761) NAPTRs
• We strongly discourage provisioning old style
  NAPTRs - RFC 2916 style service fields may well
  be rejected by clients
• Dont try to register an Enumservice E2U as it
  would cause chaos
• (This should be obvious to everyone except
  perhaps those who configure Stupid Networks
  Firewalls/SBCs )