Re: a new RRype instead of send-n NAPTRs

Jim

Jim Reid <[email protected]> wrote on 22/07/2008 20:22:03:

> Rubbish. The DNS has never, ever cared about "ownership of labels" 
> whatever that means. A client does a lookup and gets a response. It 
> doesn't have the slightest interest in who "owns" the label or 
> operates the name servers for it.

I'm sure you know this, but just in case ... in DNS a parent never makes 
an authoritative statement about a child's data.  If you have a new RR 
Type like this that can apply to any part of DNS then it will allow a 
(grand)parent to make an authoritative statement about a (grand)child's 
data.

> Aha! I suppose you mean delegation points and zone cuts. Well what you 
> say is true up to a point: though our DNSSEC friends have done a good 
> job of demolishing that. DS records, anyone?

Sorry. maybe you do know it.

> Even so, your point Jay is a diversion. IIUC, there won't be 
> delegations in this behind-closed-doors version of 4.4.e164.arpa. This 
> list has been told about a monolithic name space, database driven DNS 
> records and even responses being generated on the fly. This doesn't 
> look anything like a conventional delegation model where longer labels 
> are handed out to distinct "owners". Or am I missing something?

Yes you are missing something - the whole point from what I can see.

In many instances of ENUM it is acceptable for a parent to make an 
authoritative statement about a child.  So that's why doing this for ENUM 
is acceptable, whereas a new RR type is not.


> Indeed. This is why I privately suggested to Ray that he replace send- 
> n with a new RRtype template that should sail through the 2929-bis 
> process.

'sail through' - you're having a laugh!

> Aside from all the heat that's being generated here, I think send-n is 
> in trouble because it does not define a URI. I'm still far from 
> convinced about the alleged benefits of saving the odd DNS lookup: the 
> latency is one valid point, but some extra queries, so what? The 
> resolving entities will presumably acquire a rich cache very quickly, 

In the telephony world there is increasing pressure towards changes of 
routing (such as porting) to be reflected very quickly.  Mainly to avoid 
circular routing or failed calls.  So caching is much less a useful tool 
than you might imagine.

So what do you think of Lawrence's sensible suggestion of making 
pstn/numbering meta-data into a new DDDS application - equally dismissive?

Jay