Subject: RE: a suggestion for super-wildcards

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 31 Jul 2006 15:43:47 -0700

> From: Doug Barton [mailto:[email-masked]] 

> Yeah, and they are getting worse.

Fortunately you are reading the description of the alternative.

> > It's the heuristic that gives me the heebeejeebees of the screaming
> variety. Either you walk the tree and allow attackers to 
> stick you with 60 lookups or you add in some constraints and 
> you change the semantics of the DNS delegation as Olafur 
> pointed out in the meeting.
> 
> I wasn't sure I really understood what you were asking for 
> here when I first read this. Now that you've clarified it 
> further, I am sure I don't like it.

Me neither, the idea of super wildcards is to avoid the need to do this.

> There is an enormous difference between a super-wildcard that 
> synthesizes a response for something that doesn't exist, and 
> one that _overrides_ the records in a child domain. (BTW, I 
> have a hard time following your use of "upper" and "lower," 
> you might want to stick with the DNS terms of art "parent" 
> and "child.") I could muster up support for a good 
> implementation of the former, but I cannot imagine a scenario 
> where I would support the latter.

What I want to see is the former.

**.example.com would match responses where there is no record of a given type at a node. If there is a record of the given type at the node it always take precedence, if there is a closer wildcard match it also takes precedence.

I don't see this being different in principle to existing wildcards. 

> Changing "the semantics of 
> the DNS delegation" as you describe is too revolutionary a 
> change in my mind. Not only because it breaks with the entire 
> tradition of the deployed DNS (and therefore loses on POLA 
> grounds alone), but also because I can see this type of 
> record leading to nightmare debugging problems with anything 
> other than very simple delegations.

Hence my desire to avoid the need for the heuristic altogether. 

The point to defining the ** wildcard is to make it clear that people do not need to do this type of thing even though they may think they need to.

> This is the kind of problem that needs to be solved at layer 
> 8, where the parent zone administrator makes the requirement 
> of proper DKIM records a condition of receiving the 
> delegation, and if that policy is breached, they pull the 
> delegation. I am sure that other solutions are possible that 
> do not entail radically changing "the semantics of the DNS 
> delegation." Although it has its own drawbacks, e-mail 
> headers could be used to specify where to find the DKIM 
> policy, for example.

That is pretty much what I would want to see. Not least because domain delegation itself implies a pretty substantial handover of control.

> Also, Mark gave you a really good answer on this point, which 
> TMK you did not respond to. I would really like to see an 
> explanation of why what Mark suggested doesn't help, or isn't 
> suitable.

Have not seen the post.

> I'm not sure what set of problems you're concerned with here, 
> but my concern is for the debugging nightmare that these 
> super-wildcards you propose would cause for DNS in general, 
> not specifically related to the DKIM case.

Again, you have confused super wildcards with the description of the hack around they are intended to avoid.

There is no tree walking in my scheme, every lookup takes a maximum of three queries.

> > A lot of mail originates from addresses that are not externally 
> > visible
> due to split DNS and the use of DNS wildcard MX records.
> 
> If I understand what you're saying here correctly, I would 
> suggest that this is an error in any case. If you're sending 
> me mail with the expectation that I should be able to reply 
> to it, then I need an address to reply to that is visible in 
> my view of the DNS. If your From: address isn't visible to me 
> in DNS, the message is probably spam anyways.

The folk who have done the empirics on this disagree.

> > The problem with the heuristic is that it results in yet 
> another set 
> > of
> semantics to deal with and possibly end up with conflicts.
> 
> If I understand you correctly, the conflicts you are 
> concerned about result from your premise that child domains 
> should not be able to set a DKIM policy that is different 
> from that of their parent(s). 

No that is not the concern. Again, you are tilting at the wrong opponent here.

> Hallam-Baker, Phillip wrote:
> > There are two parts to my proposal:
> > 
> > 1) Define a 'wilder card' ** that matches a node if the 
> result would 
> > otherwise be NO-DATA and which acts on subdomains as well
> 
> As I said above, I do not support the latter in the way that 
> you are proposing it.
> 
> > From a protocol point of view I think that we should do the 
> first in 
> > any case since it will ease the transition from non-compliant 
> > wildcards to compliant wildcards when DNSSEC is in use.
> 
> Can you please flesh this out a bit, preferably with examples?

> > In particular many existing
> > DNS implementations already implement the ** semantics 
> since this is 
> > what  administrators need to define MX records.
> 
> Once again, can you give examples, preferably with reference 
> to documentation?

If you have the following nodes:

a.example.com   A  10.1.1.1
*.example.com   MX 1 1 email.example.com

The MX record does not match a.example.com because there is an a record at the node. So if you want to direct all mail delivery to email.example.com you have to add in explicit wildcards:

a.example.com   A  10.1.1.1
*.example.com   MX 1 1 email.example.com
a.example.com   MX 1 1 email.example.com

If you have fifty odd hosts this is a PITA. So some DNS servers actually specify wildcard semantics that have a looser match.

> > Regardless of whether you think DNS policy distribution is 
> a good or a 
> > bad thing, I think it is clear that the discovery mechanism for 
> > finding out where to find the policy has to be supported by the 
> > signalling infrastructure that supports the name space in 
> use. On the 
> > Internet that is the DNS, not LDAP, not NIS, not X.500.
> 
> So, we have to support it whether we think it's a good idea 
> or not? (And no, you don't get any points for trying to make 
> a meta-distinction between policy discovery and policy 
> discovery discovery.)

I think it is clear that the DNS will be the infrastructure chosen to support this function.

What do you mean by 'we have to support it'? The proposal is entirely compatible with the legacy deployed infrastructure. The whole point is not to need any support from DNS infrastructure providers.

--
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: Mon, 31 Jul 2006 15:57:36 -0700 (PDT)

> I don't see this being different in principle to existing wildcards.

Could you explain what will happen when the zone file has to be exported
to another server. Specifically these 2 cases:
  1. AXFR (or IXFR if you like)
  2. DNSSEC retrieval of signed domain zone

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Doug Barton <[email-masked]>
Date: Mon, 31 Jul 2006 16:19:12 -0700

> Fortunately you are reading the description of the alternative.

Well that's good news. :)

>> synthesizes a response for something that doesn't exist, and one that
>> _overrides_ the records in a child domain. (BTW, I have a hard time
>> following your use of "upper" and "lower," you might want to stick with
>> the DNS terms of art "parent" and "child.") I could muster up support
>> for a good implementation of the former, but I cannot imagine a
>> scenario where I would support the latter.
> 
> **.example.com would match responses where there is no record of a given
> type at a node. If there is a record of the given type at the node it
> always take precedence, if there is a closer wildcard match it also takes
> precedence.

That is a much more cogent explanation, thanks. I'm still not sure I support
it, but at least now I understand it better.

> I don't see this being different in principle to existing wildcards.

The main difference I see is that crosses delegation points, which still
leads to confusion and problems of the "how did something get into the
foo.example.com zone that is not in the foo.example.com zone file?" variety,
although in the more limited form that you describe, those questions may be
in the "trainable" category.

>> If I understand what you're saying here correctly, I would suggest that
>> this is an error in any case. If you're sending me mail with the
>> expectation that I should be able to reply to it, then I need an
>> address to reply to that is visible in my view of the DNS. If your
>> From: address isn't visible to me in DNS, the message is probably spam
>> anyways.
> 

Can you give some references? I'd love to educate myself more on this topic.

>> As I said above, I do not support the latter in the way that you are
>> proposing it.
>> 

Did you intend to fill something in here?

>>> In particular many existing DNS implementations already implement the
>>> ** semantics
>> since this is
>> Once again, can you give examples, preferably with reference to
>> documentation?
> 
> a.example.com   A  10.1.1.1 *.example.com   MX 1 1 email.example.com
> 
> The MX record does not match a.example.com because there is an a record
> at the node. So if you want to direct all mail delivery to
> email.example.com you have to add in explicit wildcards:
> 
> a.example.com   A  10.1.1.1 *.example.com   MX 1 1 email.example.com 
> If you have fifty odd hosts this is a PITA.

Thanks, I'm glad to see that on this point at least I understood you
clearly. I solved this problem a long time ago with preprocessors, so I
stopped caring. :)

> So some DNS servers actually
> specify wildcard semantics that have a looser match.

Which DNS servers?

> I think it is clear that the DNS will be the infrastructure chosen to

I think it's clear that the DKIM folks would like DNS to be where the
function is supported. What I would like to understand better is what the
problems are exactly, and where the solutions to those problems are best
found. I still have a gut feeling that you're looking to place some
solutions in the DNS space that are best found in the DKIM space, but I'm
willing to listen to reasons that I'm wrong.

I've now reached my personal quota of two messages per day on this topic, so
I'll let some others respond, and think about this some more. Thanks for
your efforts in helping to clarify things.

Doug

-- 

	If you're never wrong, you're not trying hard enough