ENUM Implementation Experiences

1. ENUM Implementation Experiences <draft-ietf-enum-experiences-04.txt> Lawrence Conroy Roke Manor Research e-mail:lconroy@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 “don’t break DNS (TCP) or EDNS0” and “beware that some Internet access providers don’t” • 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 didn’t hit a particular issue), then let’s leave it in there - others will • Let’s 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 - Don’t do it • ‘i’ flag has no required effect on ENUM NAPTR; some clients don’t expect it, so don’t 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 can’t, 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 don’t 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 don’t 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 • Don’t do Stupid Network/Firewall/SBC/… configuration! • Times To Live must be the same for all NAPTRs in a zone • Don’t use DNS (QT=255) “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 • Don’t 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 :)