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

> If this information must go in DNS I agree with everyone else that
> suggested this should get it's own DNS type, it would if nothing else
> reduce the size of the DNS packet substantially, as well as not
> interfere with NAPTR wildcards.

I don't believe there's anything like consensus on this.  For example I 
recall Lawrence specifically agreeing that getting the Send-N response as 
an automatic side-effect of an ENUM lookup was a good thing.

Also see Roy's message of 30/06 where it was explained how using a 
different RRtype doesn't affect wildcard processing - a more specific 
RRset containing *any* RRtype will prevent any wildcard expansion that 
would otherwise have succeeded.  However it's perfectly acceptable to put 
the Send-N in the wildcard RRset, or in a less specific RRset.

Personally I don't like the bloat of NAPTRs either, but for performance 
reasons we (NICC that is) consider that getting an answer back in one 
round-trip is more important than the size of the response.

If someone can propose a way to use a new RR-type which works with an 
optimal number of packets (i.e. 1) rather than size of packets then I'm 
open to it.

Jim Reid had suggested (off-list) that the Additional Section could be 
used for this.  However that would require any DNS server software 
implementing Send-N to be engineered to return this data there if the 
requested NAPTR doesn't exist.  The DNS clients would also need to be 
engineered to actually look in that Additional Section if there's nothing 
in the Answer Section.
 
> Although I thought it was a weak argument about offloading processing,
> since the processing has to be done somewhere no matter what.
> 
> Having a new DNS type it would only need 1 byte for data, which would
> speed up processing of the information since it doesn't need to deal
> with regex and so on.
> 
> DNS Type SENDN ID to be assigned by IANA, packet structure:
> 
>  0 1 2 3 4 5 6 7
> +-+-+-+-+-+-+-+-+
> |MinDig |MaxDig |
> +-+-+-+-+-+-+-+-+
> 
> Since the maximum length can only be 15 this fits perfectly inside a
> nibble :)

Except for flags to indicate absolute vs relative :)

Ray