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

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

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.

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

Ray