Subject: Non-terminal-wildcards Re: SRV records considered dubious

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 24 Nov 2006 18:46:31 +0100

Hello Phil,

I moved this discussion to namedroppers and BCC-ed the IETF list,  
please continue this part of the thread on namedroppers.

For namedroppers, the context is:
A discussion on draft-iab-dnsext-choices (the document) and the  
pointer mechanism as described in [1].

>> I also do not agree that the document should not proceed
>> without addressing the pointer mechanism. The document is not
>> of the type that specifies new solutions, it documents
>> tradeoffs. If your pointer mechanism would be more than
>> 'mail-ware' (i.e. had sufficient review and consensus) then
>> it could have been part of the equation. I think that its to
>> late for that.
>

On 23Nov 2006, at 5:18 PM, Hallam-Baker, Phillip wrote:
> How is it going to have review if the editors refuse to consider it?

It is not only the editors of dns-choices that need to review the  
pointer mechanism,  I think a wider review of the pointer mechanism  
is needed in order to assess the idea is actually a good alternative  
choice. The only thin I claim is that, as far as that happened, it  
did not come to a conclusion yet.

> Sounds to me like you are saying that you are not going to consider my
> proposal until after I persuade DKIM to adopt it.
>
> Fine.
>

No, that is not what I am trying to say. I think that if you want to  
'design' a more general extension mechanism you should actually try  
to pull this spec out of DKIM.

[1] doesn't look that DKIM specific and it doesn't specify the  
configuration directive you proposed on namedroppers in July [2] nor  
the discussion that followed. I think that it is time for a rev or  
maybe even a new draft in order to get closer to a conclusion.

So,  let us try to do justice to the whole "a suggestion for super- 
wildcards" discussion (thread starting at [4]).

Rereading that thread:
I think that most folk seem to agree that the "**" (terminal) super- 
wildcard could be implemented using a preprocessor [3], personally I  
think that such mechanism does not need a protocol action. I also  
think that there are still folk that would like to see a solution for  
the not-so-terminal wildcard (_foo.*.example.com) although we have  
not seen any concrete solutions and there is doubt that deployment of  
such (protocol) extension would ever happen.

On new RRs: We can continue to have long debates on how difficult it  
is to introduce a new RR and weather or not the problems that we see  
with a major systems vendor are real or not. I do not think that will  
lead anywhere. Having said that: This working group is wrapping up  
RFC2929bis which should ease the IANA process and at some point in  
the future, so my crystal ball predicts, all systems will support  
unknown RRs and their portable zone file representation.

Let us assume that whatever we design to deal with the problem at  
hand is so good that it will cause system updates on which support  
for RFC3597 piggybacks.

Back to the problem at hand as described in  section 3 of your  
document [1] and some parts of the email discussion. Paraphrased: An  
application (the DKIM policy client) wants to know all policy  
statements for application X (currently mail) that relates to domain  
Y. Since domain Y is an element in the DNS namespace the only  
sensible choice is to use the DNS to reach that information. Also, we  
need to design a generic mechanism so that we do not have to register  
new identifiers whenever X changes i.e. we do not want to go back to  
IANA. (do I paraphrase that correctly ?).

I have seen you argue against applying DDDS for this problem but I am  
not sure why DDDS and the 'terminal' super-wildcard generation  
mechanism does not provide the appropriate means to redirect to a  
'policy server' that is (potentially) outside the DNS? My gut feeling  
is that we have the building blocks available now. You indicated you  
dismissed the idea, could you elaborate a bit, or refer to the  
appropriate message in the thread in case I have overlooked the  
argument?

I'm also not sure if and how you can avoid namespace clashes for  
applications when you do not register the identifiers for "X". In  
that sense I think that the effort by Dave [5] is sensible.

> Just don't dare tell me that choices in any way prevents DKIM from
> considering my proposal. And don't dare suggest that choices does
> anything more than consider the four options it describes.

I have not told you anything, at this moment I am trying to listen.

Enjoy the turducken left-overs :-)

--Olaf

[1] http://www.ietf.org/internet-drafts/draft-hallambaker- 
dkimpolicy-00.txt
[2] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg00976.html
[3] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg01042.html
[4] http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg00989.html
[5] http://www.ietf.org/internet-drafts/draft-crocker-dns-attrleaf-02

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 25 Nov 2006 06:34:19 -0800 (PST)

On Fri, 24 Nov 2006, Olaf M. Kolkman wrote:

> Rereading that thread:
> I think that most folk seem to agree that the "**" (terminal) super-wildcard 
> could be implemented using a preprocessor [3], personally I think that such 
> mechanism does not need a protocol action. I also think that there are still 
> folk that would like to see a solution for the not-so-terminal wildcard 
> (_foo.*.example.com) although we have not seen any concrete solutions and 
> there is doubt that deployment of such (protocol) extension would ever 
> happen.

I believe (and said as much several times in the past) that terminal 
"super wildcard" ('**' for now) is quite useful and should be part
of the future DNS spec. I think doing it just as MACRO expansion by 
nameservers is not enough and would not fly with DNSSEC, so it does
need to be standardized if introduced though in practice it can work
just like "*" with DNS server doing expansion.

Regarding PPTR that Phillip suggested, I see his suggested use as
being quite similar to how DNAME is supposed to be used so it should
be looked at if DNAME can be properly expanded or its use explained
for that case rather then looking to create yet another ?NAME or
alike record type.

-- 
William Leibzon
Elan Networks
[email-masked]

--
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: Dave Crocker <[email-masked]>
Date: Fri, 24 Nov 2006 20:09:55 -0800

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Olaf,

Olaf M. Kolkman wrote:
> 'design' a more general extension mechanism you should actually try to 
> pull this spec out of DKIM.

I think I know what you actually meant, here, but one possible interpretation of 
your text prompts me to seek clarification.

I assume you meant something like "you should specify your proposal in a way 
that does not refer to -- or rely on -- DKIM.  That is, you should specify it as 
a standalone proposal for enhancing DNS.

But you language was "try to pull this spec out of DKIM", which implies that it 
is currently *in* DKIM.  So, the interpretation that I assume you did *not* 
mean, but I want to make absolutely sure is:  You should modify the existing 
dkim-base (or any of the working group drafts) to remove this feature.

To my knowledge, this thread concerns material that is not currently part of any 
DKIM wg documents. If that is not correct, please do clarify and cite the 
relevant wg document and section.

I do apologize for being so pedantic, but the downside of all this is just big 
enough to be worth verifying what you really mean.

> Rereading that thread:
> I think that most folk seem to agree that the "**" (terminal) 
> super-wildcard could be implemented using a preprocessor [3], personally 

The DNSext group is among the small set of folks who are certain to be quite 
clear about what the existing DNS wildcard mechanism does and does not do. My 
own view s that it does what it was intended to do just fine, although of course 
it is quite different from most other searching and matching mechanisms that are 
called "wildcard".  But, then, the DNS is a very specific kind of query engine.

It just happens that there is another form of wildcard -- and may more than one 
additional form -- that folks *wish* were in DNS, but aren't.

My suspicion is that discussion will be greatly aided by creating new names for 
each proposed new functions, and the new names need to have essentially nothing 
to do with the semantics of existing names.  Names like "super-*" don't really 
have any differential semantics.

No, I'm not nit-picking.  I think that IETF discussions frequently bog down by 
having discussions that are too vague or too confusing, and that terminology can 
help remedy that.

More generally, I believe that proposals are greatly aided by having names that 
provide useful semantic insight into what is being proposed.

Whether "wildcard" was a good name for the existing DNS mechanism doesn't 
matter.  It has almost 25 years of history, so we are stuck with it.  New 
features need new names with different meanings.

I would suggest one, for the current topic, but I don't understand it well 
enough to know what would might work.

> On new RRs: We can continue to have long debates on how difficult it is 
> to introduce a new RR and weather or not the problems that we see with a 
> major systems vendor are real or not. I do not think that will lead 
> anywhere. Having said that: This working group is wrapping up RFC2929bis 
> which should ease the IANA process and at some point in the future, so 
> my crystal ball predicts, all systems will support unknown RRs and their 
> portable zone file representation.

It occurs to me that this debate about adding -- or rather, about relying on the 
*use of* -- new RRs has happened often enough and for enough years to warrant a 
BCP that attacks concerns, documents realities, and encourages a serious, 
community-wide vendor and operator clarification of reality.  It ought to have a 
title like "What it REALLY takes to get a new RR deployed and used in wide scale".

> applications when you do not register the identifiers for "X". In that 
> sense I think that the effort by Dave [5] is sensible.

Given your second sentence, no one will be surprised that I believe that there 
is a long-term *certainty* that there *will be* collisions, absent a 
registration mechanism.

(I suppose the whole crypto/hash-based naming ideas that are being discussed for 
new Internet architectures could argue against this belief, but my understanding 
is that those statistical approaches are only for identifiers that are 
relatively short-lived.)

> Enjoy the turducken left-overs :-)

There seemed to be a foodie craze about that, a year or so ago.  And I've seen 
them pre-made and ready-to-cook in a nearby grocery store.

But somehow I cannot convince myself that the combination should produce a 
spectacular taste or texture.  So it seems like a clever idea, but not worth the 
effort.

Can anyone disabuse me of this naive belief?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Nov 2006 17:52:42 -0500

At 20:09 -0800 11/24/06, Dave Crocker wrote:

>It just happens that there is another form of wildcard -- and may more than
>  one additional form -- that folks *wish* were in DNS, but aren't.

This came up in when editing RFC 4592, I forget now, 2003 at least. 
(I'm sure that wasn't the first time, but still, it's been a while 
since even then.)

"Wildcards" is a term used to define a particular form of answer 
synthesis that appears in RFC 1034.  The synthesis is woven into the 
base level zone replication protocol (AXFR), woven in to the base 
level answering algorithm (RFC 1034, 4.3.2).  Since then it is also 
woven into DNSSEC and synthesizing negative answers at caches (maybe, 
I think, I forget how the debate tilts).

There is clearly a demand for a more feature-rich form of answer 
synthesis in DNS.  Wildcards are not intentionally an obstacle to 
meeting that demand.  The biggest obstacle has been the lack of any 
documented proposal that has stood the flames of the WG.

If I were to judge a synthesis approach, here are my rough 
guidelines.  The first step to defining any approach to answer 
synthesis is to determine what is to be achieved.  How are the 
synthesis rules included in a zone transfer?  (I don't especially 
care if the rules appear in the zone file, but they have to be 
transmitted to the slaves.)  What role does the synthesis take in the 
way in which a server prepares an answer?  How is DNSSEC impacted, as 
well as any potential synthesis at caches?

There may be many synthesis approaches that can be accommodated.  The 
approaches may require all authoritative servers for a zone using the 
synthesis to meet an new RFC, this would be acceptable so long as 
caches do not have to perform special processing.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Nov 2006 10:22:13 +1100

> I think, I forget how the debate tilts).

	Not for wildcards as the cache doesn't have enough information
	to decide when it can do it.

	You are thinking of DNAME which was designed to allow for
	synthesis in caches.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Nov 2006 22:33:18 -0500

>	You are thinking of DNAME which was designed to allow for

Ah, yeah...

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 29 Nov 2006 15:41:38 +0100

On 25Nov 2006, at 5:09 AM, Dave Crocker wrote:
> Olaf M. Kolkman wrote:
>> No, that is not what I am trying to say. I think that if you want  
>> to 'design' a more general extension mechanism you should actually  
>> try to pull this spec out of DKIM.
>
> I think I know what you actually meant, here, but one possible  
> interpretation of your text prompts me to seek clarification.
>
> I assume you meant something like "you should specify your proposal  
> in a way that does not refer to -- or rely on -- DKIM.  That is,  
> you should specify it as a standalone proposal for enhancing DNS.
>
> But you language was "try to pull this spec out of DKIM", which  
> implies that it is currently *in* DKIM.  So, the interpretation  
> that I assume you did *not* mean, but I want to make absolutely  
> sure is:  You should modify the existing dkim-base (or any of the  
> working group drafts) to remove this feature.
>
> To my knowledge, this thread concerns material that is not  
> currently part of any DKIM wg documents. If that is not correct,  
> please do clarify and cite the relevant wg document and section.
>
> I do apologize for being so pedantic, but the downside of all this  
> is just big enough to be worth verifying what you really mean.

Thank you for bringing this up.

I did try to say that the design of the DNS extension mechanism  
should be specified so that it can stand on it own. Application  
neutral, so to speak.

> The DNSext group is among the small set of folks who are certain to  
> be quite clear about what the existing DNS wildcard mechanism does  
> and does not do. My own view s that it does what it was intended to  
> do just fine, although of course it is quite different from most  
> other searching and matching mechanisms that are called  
> "wildcard".  But, then, the DNS is a very specific kind of query  
> engine.
>
> It just happens that there is another form of wildcard -- and may  
> more than one additional form -- that folks *wish* were in DNS, but  
> aren't.
>
> My suspicion is that discussion will be greatly aided by creating  
> new names for each proposed new functions, and the new names need  
> to have essentially nothing to do with the semantics of existing  
> names.  Names like "super-*" don't really have any differential  
> semantics.

Good point. I tried to carefully draft the functionality, but today I  
lost the ability to write comprehensively in a non-native  
language .... Ed, this is your queue ;-)

(...skip...)

> There seemed to be a foodie craze about that, a year or so ago.   
> And I've seen them pre-made and ready-to-cook in a nearby grocery  
> store.
>
> But somehow I cannot convince myself that the combination should  
> produce a spectacular taste or texture.  So it seems like a clever  
> idea, but not worth the effort.
>

Off-list pleas (But do CC me, epicurean experiments have my interest)

---

From: Edward Lewis <[email-masked]>
Date: Wed, 29 Nov 2006 10:42:32 -0500

At 15:41 +0100 11/29/06, Olaf M. Kolkman wrote:

>Good point. I tried to carefully draft the functionality, but today I lost the
>ability to write comprehensively in a non-native language .... Ed, this is
>your queue ;-)

Cue not queue.  Oh, what's that about native languages? ;)

I ain't about to say "let's get requirements together" (#2 on the 
list of stalling comments, #1 being "read the archives") but if 
anyone has a concrete idea, document it - the good old-fashioned 
tradition of running code is very helpful.  And give it a cool name.