Re: wildcards and n-send NAPTRs

> Sorry Clive, you're wrong. There are. The draft makes wildcard 
> processing conditional on the RDATA that's in one of these nsend 
> NAPTRs. This *is* a change in semantics and the consequences of that 
> have still to be worked through. You even go on to concede the 
> semantics are changed by pointing out a corner case where a badly 
> structured nsend NAPTR causes an infinite loop.

To clarify, it's our belief that the semantics of wildcards w.r.t standard 
DNS clients and servers are not changed by this one iota.

As per my message yesterday, and one of Clive's today, the only thing that 
changes is the ENUM client code, and then only in those clients that need 
to support overlapped-dialing via Send-N.

> Now it's one thing having applications playing in this nsend world 
> perform loop detection. [How? And where is this documented?]

I'll look at including a more detail description of the Send-N algorithm 
than is currently in Section 5.  In practise there wouldn't actually be an 
infinite loop because E.164 numbers can't exceed 15 digits.

> But are there scenarios where name servers, espeically full service 
resolvers, 
> could end up having to do loop detection?

No, there are not, IMO.  I don't believe that I can *prove* that's the 
case, but I know that I cannot think of any such scenario.  Nor can our 
in-house DNS gurus.  If anyone *can* think of an example please let me 
know.

These are *just* RRs after all.  All the DNS server has to do is serve 
them, using the existing rules.

> Some further analysis is required. IMO, the proponents of nsend need
> to do that work and convince this WG and dnsop that there is no impact
> on either the DNS protocol or implementations.

My experts say it doesn't - I'm happy to ask Peter and Rob for second 
opinions.

> It's all very well for the draft to say nsend SHOULD NOT be used with 
> wildcards. But it really has to say something about what happens if/ 
> when that advice is not followed.

It does - but I'll try and make it clearer.

Ray