draft-bellis-enum-send-n-00

On Apr 3, 2008, at 08:05, Duane wrote:
> If not ENUM, then where does this best fit?

IMO the issue of putting numbering plan information in the DNS is  
best solved with a new DNS RR type that's designed for that specific  
purpose and probably not with a NAPTR. So that probably means writing  
up something for the dnsext 2929bis process. How that hypothetical  
new RRtype could be used in e164.arpa is something that this WG could  
pick up.

However this draft is deeply flawed. There are many problems:

[1] It is simply unacceptable to say this NAPTR service type MUST NOT  
be used with a wildcard. This violates DNS fundamentals: all RRtypes  
are the same and the same semantics apply to them wrt wildcard  
processing and the likes. [Well, let's not go down the wildcard SOA  
and NS ratholes.] In fact it's worse than that because the  
restriction on whether a wildcard can be used or not depends on a  
*subtype* of an RRtype. This is very bad.

Although I am no fan of wildcard DNS labels, it makes no sense to say  
"wildcards are OK for this RRtype but not that RRtype". It's even  
worse to say "wildcards can be used for these NAPTR service types,  
but not for these other ones". It's also exceptionally bad protocol  
design to make that a requirement.

[2] The draft says nothing about how a client should behave when  
there are many of these proposed send-n (sub) service types and what  
they would mean. Suppose a lookup returns:

	.... NAPTR 10 10 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/5-6!" .
	.... NAPTR 10 20 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/3-9!" .
	.... NAPTR 20 10 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/1-5!" .
	.... NAPTR 20 20 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/4-7!" .
	.... NAPTR 20 30 "E2U+pstndata:send-n" !^.*$!pstndata:send-n/6-9!" .

What does this mean and how are clients and applications expected to  
behave? For extra bonus points, add in funky regexp substitutions  
instead of a boring "!^.*$!". :-)

And what if there are other E2U+pstndata:send-n NAPTRs higher up the  
tree that conflict with these entries? Does a E2U+pstndata:send-n  
NAPTR for e164.arpa covering a 15 digit number over-ride one at  
1.2.3.4.5.6.7.8.9.e164.arpa? Which is definitive?

[3] The hierarchical structuring of E.164 numbers and the DNS means  
the scheme as proposed is vulnerable to all sorts of nasties. IIUC  
introducing one of these "E2U+pstndata:send-n" at the apex of the  
tree could nuke all the others at any leaf nodes in the tree. Suppose  
someone puts "E2U+pstndata:send-n" ""!^.*$!pstndata:send-n/1-15!" at  
the zone apex. It's game over. Any local or national dialling plan  
info that was submitted will never be found even though it's in the  
DNS because clients would have picked up the entry at the apex which  
tells them not to go looking for more localised dialling information.

And if one of these NAPTRs gets inserted at a higher node of the  
tree, it can break clients who depend on local dial plan info that  
was stored lower down. That violates another DNS fundamental. Apart  
from delegations and maybe DNSSEC, nothing that goes into a parent  
zone should have any impact on what's in a child zone or on the  
responses from the DNS. And when we're not talking about delegations,  
an RR for some domain should have no impact on any RRs at any  
subdomains.

[4] The concept of using the DNS to store numbering plan information  
is a good one. How it's been proposed here is broken. As is the  
application of that proposal IMO. For ENUM, the lookup is done on a  
complete digit string. Hitting the call button on a mobile phone is  
analagous in ENUM to "lookup the number that's just been typed". An  
ENUM lookup only takes place once the full number -- for some  
definition of full number -- has been dialled and translated into a  
domain name. To do the equivalent for overlapped dialling, a DNS  
lookup would be done for each digit in the number as it was typed or  
dialled until the client hits one of these n-send service types that  
has info about the number that's being dialled. I just don't see the  
point. Any device that has the intelligence to do a DNS lookup  
probably already has some sort of directory/call routing/address book  
capability and would be able to do The Right Thing when something  
dialled 3 or 4 digits on a steam phone or whatever.


To my mind, a cleaner scenario would be for numbering plan info to be  
stored in the DNS using an RRtype that was designed for that purpose.  
Clients like SIP servers and SBCs could query for this at start up  
and maybe have to navigate through a bunch of these RRs at different  
points of the tree. Once that's been done, they can configure  
themselves with information about any local dialling plans that are  
revelant.