ietf-mailsig
[Top] [All Lists]

Re: wildcards, was dkim technology?

2005-07-15 11:11:56

John R Levine wrote:
What I've never been clear on is whether zone cuts can't
be used as an *optimization* in many cases such that normally
you'd be doing a max of two lookups, but in some pathological
cases you'd have to do the tree walk. From what I've seen looking
at the authority record seems to often be what you want for
deeply nested subdomains. It's been a while since I've had
this problem swapped in though.


The answer was pretty clearly no.  Zone boundaries aren't supposed to be
interesting to applications, and sometimes aren't even visible if the
authority record doesn't fit in the response.

Considering that no scheme like this has been widely deployed,
arguments from authority are not very helpful.

As far as I can tell there are two cases. For a.b.c.d.example.com,
to do a policy lookup you'd query for:

_policy._domainkey.a.b.c.d.example.com

this would produce an NXDOMAIN and assuming that it fit,
an authority record. There are two cases that I can think
of:

1) the authority record is a superdomain of a.b.c.d.example.com
(say, example.com)

In this case, recursing with _policy._domainkey.example.com
would yield you the policy record at the zone cut. (or not).
The only downside I can see is that you wouldn't get to have
finer grained policy within a single zone (ie, you couldn't
have a different policy record d.example.com and e.example.com.
This doesn't sound like a horrible problem in reality though
and you could always add a zone if it were a problem.

2) the authority record is *not* a superdomain of a.b.c.d.example.com
(say, outsourcedns.com)

In this case, you'd have no choice but to do the subdomain
walk.

So as I said, as an optimization it looks like it has some
favorable properties IMO. It also has the nice propety that
the make-work factor is limited to 2 rather than 5 on the
non-outsourced case.

                Mike


<Prev in Thread] Current Thread [Next in Thread>