Re: [Enum] draft-bellis-enum-send-n-00

["Clive D.W. Feather" <clive at demon.net>]

Jim Reid said:
> 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.

Sheesh.

Firstly, the application is already going to be querying for NAPTR records,
so this means it gets back the desired information without any more effort.
Secondly, adding new RR types should be limited to major new issues that
can't be met with the existing types.

> [1] It is simply unacceptable to say this NAPTR service type MUST NOT  
> be used with a wildcard.

This could be reworded, but it's still an issue.

> Well, let's not go down the wildcard SOA  
> and NS ratholes.
[...]
> 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".

Why not? What are the semantics of a wildcard SOA?

As someone else said, this is a usage guide not a technical prohibition.

> [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 "!^.*$!". :-)

In both cases, "don't do that".

What does it mean if I have two SOA records at the same node in a DNS tree?
What does it mean if the regexp substitution in an ENUM record is "^ at .*$"?
The fact that a record can be misused doesn't make it a bad thing.

> 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?

Good point. Ray, this needs to be spelled out: the record lowest down the
tree overrides any higher up (since it can generally be more accurate).

Thus
    4.4.e164.arpa             would say     send-n/7-10
while
    0.0.5.4.4.e164.arpa       would say     send-n/6-6

although the earlier record implies only send-n/4-7.

> [3] The hierarchical structuring of E.164 numbers and the DNS means  
> the scheme as proposed is vulnerable to all sorts of nasties.

Not so.

> 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.

No it doesn't.

The client picks up this record. It accepts one more digit (since digitsmin
is 1) *and then does an ENUM query*. If it gets back another send-n, that
overrides the 1-15. If it gets back a full record, it uses it. If it gets
nothing, it accepts another digit and tries again. If it accepts 15 more
digits and *still* doesn't get any records back, it signals that no record
was found.

The way I see these records being used is something like this:

    Set min to 1 and max to infinity.
    While max > 0
    {
        While min > 0
        {
            Accept another digit
            * On digit timeout, break from this inner loop
            * On overall timeout, break from the outer loop
            Decrement min and max (decrementing infinity has no effect)
        }
        Do a DNS lookup for NAPTR records.
        If you get the type you're looking for, return it.
        Otherwise, if you get a send-n record:
        {
            Set min to the digitsmin value.
            Set max to the digitsmax value, or infinity if there isn't one.
        }
        Otherwise set min to 1.
    }
    Return failure to find any record.

[First attempt; there may be errors.]

Ray, feel free to steal this if you think it helps.

> 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.

Only if the record says that the maximum number of digits is so small the
lower information can't be reached.

> 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.

It doesn't.

> 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.

Right (though the device may hold an implicit top-level record of, say,
"send-n/6-15").

> 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.

I don't understand what you're getting at here. The user dials "78". The
internal configuation of the device converts that to "+44195478" or to
"+121278". Should the device do an ENUM lookup yet, or wait for more
digits? How many more?

Outside a few places like the NANP, this information is complex, hard to
get completely correct without help, and subject to change. Keeping all of
that information in every single device is a completely broken idea; the
same DNS tree as the target ENUM records appears to be the obvious place.

> 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.  

See above.

> 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.

It takes a *lot* of information to describe E.164.

> Once that's been done, they can configure  
> themselves with information about any local dialling plans that are  
> revelant.

Unless I'm misunderstanding you, this isn't particuarly about local
dialling plans, it's about *national* dialling plans.

Which of these numbers are genuine and which are the wrong length?

    +448003634083
    +44800363487
    +448003635291
    +44800363587

On what date will the answer change?

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum