Re: wildcards and n-send NAPTRs

Jim Reid said:
> 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?

They don't. No change to the semantics of wildcarding is being proposed.

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

If an application is not specifically interpreting SEND-N (and this
includes all DNS servers and anything other than an overlap-dialling
switch), then these records have no effect on that 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?

The DNS implementation? Nothing.

The specific application interpreting SEND-N records needs to take a
teeny-weeny bit of care. A wildcard record like:

    * IN NAPTR ( 100 10 "u" "E2U+pstndata:send-n"
                            "!.*!pstndata:send-n/2!" . )

is in effect an infinite loop: it tells the application to fetch 2 more
digits and then query again, whereupon it hits the same record again
(assuming there isn't an explicit record there as well that overrides it).
The application therefore needs to have some kind of loop detection and
limit, whether testing for wildcard records, putting a limit on the number
of dialled digits, putting a limit on the number of SEND-N records it reads
for a single call attempt, or whatever. [Ray: you could perhaps put in a
usage note to that effect.]

But anyone else reading those records *will not be affected* as far as I
can see.

-- 
Clive D.W. Feather  | Work:  <[email protected]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email protected]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |