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

On 18 Jul 2008, at 10:41, [email protected] wrote:
>> You use the new DNS RR in the same way(s) you are proposing to use a
>> NAPTR record. As I said in my previous email, a new RR type wouldn't
>> have all the regex/text processing overhead so using binary parsing
>> would speed things up considerably.
>
> Sory - I think you missed my point.
>
> With overlapped dialling, one would send a DNS query with QTYPE =  
> NAPTR to
> see if a full ENUM record is available.
>
> With Send-N, the full record isn't available, but a Send-N NAPTR is
> returned in its place.  This is the standard DNS behaviour, with no
> special processing required at either end and it's all done in one DNS
> request round-trip.

I interpreted his comment to mean 'no regular expression processing'  
as obviously this has a processing cost. Perhaps using an S-NAPTR  
style scheme with static data might alleviate this?

> If a different RRtype is used for Send-N, the DNS client receiving  
> NOHOST
> for the QTYPE = NAPTR lookup would need to send a second DNS request  
> with
> QTYPE = SENDN.  That's specifically what we're trying to avoid.

Indeed latency will be the single biggest cost, especially for mobile  
devices. It's all too easy to forget this. Of course there's no reason  
why the client can't send two DNS requests at the same time, one for  
NAPTRs and one for another RRTYPE, then act depending on which brings  
back a meaningful result, but this of course would double the number  
of requests to be handled by the DNS server relative to the number of  
ENUM queries required.

> The alternative would be to send QTYPE = ANY, but that's definitely
> considered bad practice.

Although in this particular instance it might be appropriate...


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
http://www.linkedin.com/in/eleanormchugh