Re: Send-N draft: draft-bellis-enum-send-n-02 published

On 27 Jun 2008, at 13:52, Clive D.W. Feather wrote:
> Brian Rosen said:
>> Implement something else (i.e. a client to another database which  
>> has length
>> information) in the same server.
>>
>> It's possible that we'll decide the protocol for this new database  
>> is DNS.
>
> And if we do decide this, it ought to minimize the number of DNS  
> lookups.
> Which means returning NAPTR records.

It's not entirely obvious that using NAPTR records this way would  
result in any fewer DNS lookups than by providing a new RR type.  
Either way the zone record still needs to be loaded, and with a  
request for NAPTRs the client could in theory get a larger data set  
back which would then need to be processed locally: probably a trivial  
cost, but still a consideration for implementers.

Also in terms of the actual usage, one question does arise: what  
happens if a send-n NAPTR is provisioned as an NTN? Given the  
restriction to digits only beneath .e164.arpa, it's hard to think of a  
use case where that NTN could possibly point to a meaningful target  
without leading outside of the ENUM hierarchy. This then leads me to  
consider an obvious cache poisoning attack where:

	IN NAPTR 100 10 "u" "E2U+pstndata:send-n" "!.*!pstndata:send-n/=11!" .

is replaced with:

	IN NAPTR 100 10 "u" "E2U+pstndata:send-n" "" call.capture.arbitrary.tld

or

	IN NAPTR 100 10 "u" "E2U+pstndata:send-n" "" [premium rate  
number].e164.arpa

and the call is funnelled off elsewhere. This is obviously at a  
tangent to the main point of the current discussion, but unless you  
can think of a good NTN use case with send-n they should probably be  
explicitly forbidden.

>> I have no opinion on that yet.  I have an opinion that we should  
>> have a
>> database with length information that all services, and all  
>> devices, can
>> make use of.  Send-n is too limited, in my opinion.
>
> What doesn't it do that your proposed new protocol would do?


You've identified an interesting problem: how to validate the depth/ 
shape of namespace tree branches allowed given an intermediary point  
on that tree. A general case solution using a new RR type could be  
useful in places other than just ENUM, and if that's the case your  
send-n proposal will either lead to the proliferation of copycat  
solutions in other hierarchies or else be an evolutionary dead-end  
when an RR does get defined. Therefore you have nothing to lose by  
proposing an appropriate RR in the first place.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason