Non-terminal-wildcards Re: SRV records considered dubious

["Olaf M. Kolkman" <[e-mail]>]

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/