Re: wildcards and n-send NAPTRs

[email protected]
Newsgroups gmane.ietf.enum
Message-ID <OF4B4DAC7B.8895BB3B-ON80257474.003B36F5-80257474.003D6CC7@nominet.org.uk>
> Could the proponents of n-send please explain why the semantics of 
> wildcarding have to undergo further complication by making them 
> conditional on the RDATA of an existing resource record? Not ony that, 
> they're conditional on a subtype of the RDATA. This goes to the core 
> of the stability of the DNS protocol. It's incumbent on those 
> proposing this change to explain that it won't break anything or 
> require yet more corner cases in wildcard handling/processing by 
> servers, resolvers and end applications. Saying "we're doing this in 
> private between consenting adults" is not an answer.

I'm not proposing (IMO) any changes to the semantics of wildcarding. 

The use of Send-N in wildcards neither imposes nor requires any changes in 
wildcard handling in any DNS server, resolver, or application.

> Saying n-send SHOULD NOT use wildcards is all very well. But what if 
> someone does do that? Even behind closed doors? What operational 
> impact would that have? What sort of action would those DNS 
> implementations need to take? Will it require extra code? If so, where?

As per the draft, the worst case if someone published a Send-N record in 
an I-ENUM tree that was incorrectly high is that it might result in the 
numbers covered by that record not being reachable.  That's true even if 
wildcards aren't used, and irrespective of whether this is a NAPTR record, 
some other RR-type, or **any** other sort of Send-N database (whether 
real-time or hard-wired).

This *is* a risk, but it's along the same lines as any other 
misconfiguration of DNS data - "don't do it".

The only reason that wildcards are an issue is because a relative-form 
Send-N record in a wildcard could result in the ENUM client repeatedly 
continuing to expect more dialled digits until the 15 digit E.164 maximum 
is reached.  In effect, a relative-form record in a wildcard is 
automatically "incorrectly high".

The only place any code is required is in ENUM clients, but only in those 
that specifically want to support Send-N, such as I-ENUM enabled switches.

As far as any DNS server is concerned, it's just another NAPTR record. 

Ray
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.