Subject: RE: a suggestion for super-wildcards

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

--
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: "william(at)elan.net" <[email-masked]>
Date: Fri, 4 Aug 2006 11:27:28 -0700 (PDT)

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>

---
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Sun, 6 Aug 2006 00:42:25 -0700

On Aug 5, 2006, at 6:38 PM, Danny Mayer wrote:

> Hallam-Baker, Phillip wrote:
>>
> TSIG on BIND 9 for Windows works fine. Maybe you can ask the  
> question with more specifics.

Bind is not required. TSIG is a predefined Windows 2000 structure. See:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/ 
cnet/cncf_imp_afpf.mspx?mfr=true

Can a shrink-wrap version of an XP Windows OS within a shrink-wrap  
Windows domain handle undefined RR types by type numbers in the API,  
and then allow parsing the results into an application's structure?  
It does not look promising after reviewing windns.h.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 7 Aug 2006 11:59:22 -0700

On Aug 6, 2006, at 4:21 PM, Danny Mayer wrote:

> Douglas Otis wrote:
>> http://www.microsoft.com/technet/prodtechnol/windows2000serv/ 
>> reskit/cnet/cncf_imp_afpf.mspx?mfr=true
>>
>
> No, that's GSS-TSIG which is not the same thing at all. Phil was  
> asking about TSIG. I have no idea what it has to do with  
> namedroppers. Rob Austein has a draft to modify the GSS-TSIG RFC  
> 3645 but I haven't seen it discussed here.

I believe the issue is related to the wildcard scheme being proposed  
per the subject line.  This scheme reuses an existing RR type.  This  
reuse was to avoid a new RR type for enabling an effect of a wildcard  
being placed below a prefix.  My understanding for the reuse was due  
to deployment concerns related to Windows.  The relevance can not be  
determined without knowing why it was asked.  The linked article  
refers to RFC3645 that updates RFC2845 or DNS RR TYPE 250.

-Doug