Subject: RE: a suggestion for super-wildcards

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 4 Aug 2006 08:41:46 -0700

> [mailto:[email-masked]] On Behalf Of Kevin Darcy

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

And what applications read these semantics?

The nice thing about following a PTR is that you get exactly the right semantics when you follow a PTR chain from the reverse DNS into the forward DNS. This is actually something I want to do in PINCH which is a peer to peer version of INCH that would allow a lot of the reporting work currently taking place over telephones to take place by Web service.

When you look through the administration requirements for extended policy management as I have done it is clear that you want to follow the PTR record in the first instance to discover a DNS name and then look for policy at the name.

If you are using the PTR records to associate one name with another then the chances are that if you are going to deploy policy records that you would find that the policy records would want to follow the same path.

A way that we can resolve this problem is to define a new record PPTR and specify that this takes precedence in the discovery process:

1) This does not affect your applications at all until you decide to use policy.

2) If you do have existing PTR records deployed and do not want to affect the semantics then you have a choice, either you don't deploy policy records or you upgrade your DNS server to a version that supports the new PPTR resource record in order to do so.

The modified discovery process is then:

1) Look for _policy.example.com
2) If not found look for PPTR(example.com)
2a) If present look for _policy.[PPTR (example.com)]
3) If PPTR(example.com) not found look for PTR
3a) If present look for _policy.[PTR (example.com)]

In this scheme you can disable any unexpected effects due to the policy discovery simply by defining a PPTR superwildcard.

But I don't see how it is likely that you would have a PTR record that would point to a node because you want to 'associate one name with another' and not want the policy associations follow the same path. As with the use in the reverse DNS I think you will find that the policy semantics you want would follow the same path.

What I need to achieve here is to define a mechanism for policy distribution that is compatible with legacy deployed DNS as far as is possible and does not make deployment of future policy extensions dependent on the whims of the maintainers of the major DNS servers.

Clearly breaking existing applications is not compatible with the legacy DNS but I do want to see a more extensive description of the application and explanation of the specific issues. I do not recognize the 'intestinal tract' veto that others have asserted in the past. If someone's intestinal tract is the reason for blocking progress I will be happy to buy them some Alka-Seltzer and a bottle of Pepto Bizmol. There is a Costco in San Diego I can stop off there on the way to the meeting and bring some for everyone.

--
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: Douglas Otis <[email-masked]>
Date: Fri, 4 Aug 2006 10:50:46 -0700

On Aug 4, 2006, at 8:41 AM, Hallam-Baker, Phillip wrote:

>
> A way that we can resolve this problem is to define a new record  
> PPTR and specify that this takes precedence in the discovery process:
>
> 2) If you do have existing PTR records deployed and do not want to  
> affect the semantics then you have a choice, either you don't  
> deploy policy records or you upgrade your DNS server to a version  
> that supports the new PPTR resource record in order to do so.

The PTR wildcard scheme is like building a super highway through a  
rural area, and this solution is like a declaration of eminent domain  
with instructions in how to build a detour sign, instead of offering  
compensation.  The reasons for electing not to take the PPTR path  
initially are the same reasons for a detour not being taken as well.   
Adding another step to this wildcard process also means this scheme  
comes fairly close to just searching the declared depth of where  
policy must reside.

Adopting a new RR type for policy has advantages beyond the use of  
wildcards.  When hunting, not needing a prefix to avoid colliding  
with other uses of a generic RR holding policy allows detection of a  
missing lower level.  A new RR type will allow the hunt to terminate  
before recursing to a maximal depth.  The wildcard issue is not  
really the sticking point with policy, it is the new RR type.  The  
concern is that a new RR type is not adequately supported within the  
desktop environment, and that this limited support will impede  
deployment.

-Doug

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 4 Aug 2006 11:12:13 -0700

The problem with Doug's approach is that he is proposing a new record for each and every policy that is declared. This is not scalable and creates a situation that has never existed before where the development of each new Internet protocol is dependent on IANA and IETF action.

I do not think that we want to put allocation of DNS resource records on a part with IANA port assignments. There lies the road to madness. That is why we have SRV and NAPTR. We already have a prefix scheme in the DNS all I am proposing here is to fix it so that it works as well as it can.

Plus the superwildcard scheme requires fewer resource records than for Doug's suggested approach.

Incidentaly, does anyone know the extent of support for TSIG in Windows? 

> -----Original Message-----
> From: Douglas Otis [mailto:[email-masked]] 
> Sent: Friday, August 04, 2006 1:51 PM
> To: Hallam-Baker, Phillip
> Cc: Kevin Darcy; [email-masked]
> Subject: Re: a suggestion for super-wildcards
> 
> 
> > A way that we can resolve this problem is to define a new 
> record PPTR 
> > and specify that this takes precedence in the discovery process:
> >
> > 1) This does not affect your applications at all until you 
> decide to 
> > use policy.
> >
> > affect the semantics then you have a choice, either you 
> don't deploy 
> > policy records or you upgrade your DNS server to a version that 
> > supports the new PPTR resource record in order to do so.
> 
> The PTR wildcard scheme is like building a super highway 
> through a rural area, and this solution is like a declaration 
> of eminent domain with instructions in how to build a detour 
> sign, instead of offering compensation.  The reasons for 
> electing not to take the PPTR path  
> Adding another step to this wildcard process also means this 
> scheme comes fairly close to just searching the declared 
> depth of where policy must reside.
> 
> Adopting a new RR type for policy has advantages beyond the 
> use of wildcards.  When hunting, not needing a prefix to 
> avoid colliding with other uses of a generic RR holding 
> policy allows detection of a missing lower level.  A new RR 
> type will allow the hunt to terminate before recursing to a 
> maximal depth.  The wildcard issue is not really the sticking 
> point with policy, it is the new RR type.  The concern is 
> that a new RR type is not adequately supported within the 
> desktop environment, and that this limited support will 
> impede deployment.
> 
> -Doug 
>     
> 
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 4 Aug 2006 11:35:19 -0700

> From: william(at)elan.net [mailto:[email-masked]] 

> On Fri, 4 Aug 2006, Hallam-Baker, Phillip wrote:
> 
> > The problem with Doug's approach is that he is proposing a 
> new record 
> > for each and every policy that is declared. This is not 
> scalable and 
> > creates a situation that has never existed before where the 
> > development of each new Internet protocol is dependent on 
> IANA and IETF action.
> 
> <sarcasm>
> 
> It never existed before? Really?
> 
> </sarcasm>

If you think that the IETF is a place to come for permission you do not understand why it exists.

Jon Postel did not consider his function as a gatekeeper, he regarded his IANA role as being an archivist.

Empirically there are other standards bodies that are creating Internet protocols that the IETF neither has a liason with nor shows any interest in having such a liason.

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 4 Aug 2006 12:02:11 -0700 (PDT)

> understand why it exists.

It exist to provide technical forum with multi-area review for
developers of new internet protocols/services and to provide
central point to consider updates to existing protocols. This
isn't of course all, but is my understand about the core of it.

> his IANA role as being an archivist.

Yes, I was talking about /etc/services, /etc/protocols, which
sure sounds like IANA is needed to get new protocol deployed
to anything but minimum testing stage. And if you come to think
of it if protocol needs special type of DNS records IANA and
IETF are again needed. Similarly if protocol need to use services
of some other protocol, etc.

I'm not saying this is all good, but I have hard time when somebody
says that IANA is not needed to get new protocol deployed (with
possible exception of peer-peer especially if it is implimented as 
broadcast discovery with incoming port number of neighbors being
advertised in that way), but I view it as more of exception at
least in the current internet.

> Empirically there are other standards bodies that are creating Internet 
> protocols that the IETF neither has a liason with nor shows any interest 
> in having such a liason.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 4 Aug 2006 12:38:32 -0700

> to anything but minimum testing stage. And if you come to 
> think of it if protocol needs special type of DNS records 
> IANA and IETF are again needed. Similarly if protocol need to 
> use services of some other protocol, etc.

Its been almost a decade since I used a machine that had such files.

It has always been possible to get a port assignment without IETF involvement. There are more port assignments than RFCs.