Subject: Re: a suggestion for super-wildcards

From: Douglas Otis <[email-masked]>
Date: Tue, 01 Aug 2006 05:06:33 -0700

On Mon, 2006-07-31 at 18:48 -0400, David Blacka wrote:
> Doug Barton wrote:
> 
> > In short, I've tried to understand what you are proposing and why, and I do
> > not think that the benefits of your proposal outweigh the costs.
> 
> The way I read Phill's proposal was that he was merely defining:
> 
>  1) a new zone preprocessor rule (perhaps confusingly called **.example)
>  2) a new use for PTR in the forward space.
> 
> Am I wrong?  If I'm not wrong, I am at a loss to understand what is so
> controversial about either part of the proposal.

Rather than defining a new RR type, semantics for a new label are
defined and applied to an existing RR type.  This is not just a new use
for the PTR type in the forward space, it prohibits other applications
from also using the PTR RR.  This scheme would be a mess when the **
label is used in the reverse space, for example. 

Ultimately this proposal will require new RR types to prevent collisions
within a common prefix when the ultimate automation of this scheme
attempts to synthesize desired answers for the initial query.

This wildcard scheme is a bit less than super by requiring two
additional transactions, while also reusing existing RR types to
overcome a "new type" limitation imposed by a particular vendor.  This
scheme uses a macro expanding **.<this-domain> into:

*	PTR <this-domain>  ; at _every_ label

where a query for (_prefix.<some-domain>, RR-TYPE)
may require a fixup query for (<some-domain>, PTR) followed by
a query for (_prefix.<this-domain> RR-TYPE).

When fully automated to satisfy the initial query of
(_prefix.<some-domain>, RR-TYPE) the _prefix label will also need to
include a synthesis of the RR-TYPES at that location.

_prefix.<this-domain> 	RR-TYPE-A
			RR-TYPE-B
			RR-TYPE-C

This calls into question the use of the unique label rather than a
unique RR type.  For example, a unique RR type of PWCARD could be
defined to include three fields:

_prefix.<this-domain> PWCARD <list-of-RR-types><><this-domain>
_prefix.<this-domain> RR-TYPE-A <blah>
_prefix.<this-domain> RR-TYPE-B <blah>

When the RR type PWCARD is discovered with a null prefix field a macro
then expands this to:

*	  PWCARD <><_prefix><this-domain>; at _every_ label

This would allow a PWCARD RRset of various prefixed labels to be
constructed and pointing to the desired locations.  When the list of RR
types or the prefix field is null, it would signal how this new RR type
is being used, and whether it should be expanded.  A fully automated use
of this new PWCARD RR type could then always return the desired RR type
at the initial query (better than super).  Until then, a manual
work-around similar to the current proposal can be used for existing
implementations.

This alternative using a new RR type will not conflict with existing
uses of the ** label, the PTR RR, and provides a cleaner method to fully
automate the synthesis of the desired answer at the first query.  The
transfer of PWCARD RRs can be selective when the receiving server
understands the expansion rules for the PWCARD RR where the prefix field
is null. This filtering would not be as simple when reusing PTR where
the forward and reverse space must follow different rules.

-Doug

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 03 Aug 2006 22:04:50 -0400

> label is used in the reverse space, for example.
I don't like the direction in which this seems to be heading. PTR has 
always been defined as a *generic* way to associate one name with 
another in DNS (syntactically identical to CNAME, but without the 
special hooks into the standards-defined nameserver and/or resolver 
algorithms). PTR has *never* been restricted to only providing 
reverse-DNS resolution. As such, I use PTRs for purposes other than 
reverse-DNS resolution, and I'm sure I'm not the only one. They are 
preferable to TXT RRs when associating names to names because they can 
benefit from label compression.

So, if you invent a new restriction on the use of PTR RRs, you're likely 
to break my app, and quite likely other people's apps too. All in the 
name of what? Circumventing "a 'new type' limitation imposed by a 
particular vendor"? Great, so we solve one legacy problem and create 
another. This is progress?

								- Kevin