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.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html