ENUM Implementation Experiences Lawrence Conroy Roke Manor Research

IETF64-ENUM-Experiences: 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

IETF64-ENUM-Experiences: 3 Summary Corrected Typos Expanded acronyms Changed some sentences to make them clearer Restructured Section 6 on General DNS issues

IETF64-ENUM-Experiences: 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)

IETF64-ENUM-Experiences: 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

IETF64-ENUM-Experiences: 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

IETF64-ENUM-Experiences: 7 Backup - List of Issues Covered

IETF64-ENUM-Experiences: 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

IETF64-ENUM-Experiences: 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

IETF64-ENUM-Experiences: 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

IETF64-ENUM-Experiences: 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

IETF64-ENUM-Experiences: 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

IETF64-ENUM-Experiences: 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

IETF64-ENUM-Experiences: 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 :)