[ietf-dkim] draft-iab-dns-choices-05 and tree climbing (fwd)
fenton at cisco.com
Sun Mar 2 20:55:53 PST 2008
John Levine wrote:
> The question is whether that small amount of coverage is worth the
> pushback we will certainly get from the IAB when they see the tree
> crawling in our draft. If bad guys know that foo.cisco.com is covered,
> why won't they just use foo.bar.cisco.com instead?
Great example. Let's see what ASP does with that.
foo.cisco.com is, as it happens, a CNAME for some random internal web
server. So it's unlikely to have an explicit ASP record. The first
query, for _asp._domainkey.foo.cisco.com TXT will return a NXDOMAIN
response. So we next query for foo.cisco.com MX which
returns...er...the CNAME (maybe we need to tighten up the spec to handle
CNAMEs better). Querying the thing it points to, ptlm-www.cisco.com,
returns noerror/nodata to an MX query. So then we query for
_asp._domainkey.cisco.com TXT, and get its ASP record. So far so good.
Now suppose the bad guy uses foo.bar.cisco.com. The first query for
_asp._domainkey.foo.bar.cisco.com TXT returns NXDOMAIN, so we next query
for foo.bar.cisco.com MX and also get NXDOMAIN. The algorithm
terminates with an error indicating that the domain doesn't exist. It's
up to the implementation what happens next, but I would expect that
would bias the evaluation of the message negatively. That's why the bad
guy wouldn't want to use foo.bar.cisco.com.
> Also, keep in mind that if you really truly want to cover every possible
> subdomain, it's not out of the question to use a DNS server that
> synthesizes the necessary records on the fly using a different wildcard
> expansion process from BIND.
Let's explore that. This means that every domain publishing an ASP
record that wants this coverage would have to change *all* of its
authoritative DNS servers to implementations that synthesize these
responses. I'm not aware of any DNS servers that do this right now.
Even if they do exist, given the requirement to have multiple
authoritative servers on different networks and resulting cooperative
DNS service arrangements, the requirement that they all do this is a
huge barrier to effective deployment.
More information about the ietf-dkim