on 8/5/04 9:39 AM, wayne at wayne(_at_)midwestcs(_dot_)com wrote:
Another common misunderstanding of DNS wildcards:
Yet another misunderstanding of DNS wildcards:
Given...
*.example.com TXT "blah"
foo.bar.example.com A 192.0.2.1
...people might think that the wildcard will synthesize...
bar.example.com TXT "blah"
..and...
gold.bar.example.com TXT "blah".
This is, however, not always true.
For RFC 1034/1035 compliant servers such as BIND 8 an empty node blocks a
wild card, resulting in an empty answer for the first and a NXDOMAIN for the
second.
Complicating the matter is that servers that support the DNS Security
Extensions (DNSSEC) such as BIND 9 follow RFC 2535, and RFC 2535 doesn't
allow for empty nodes. For such servers both of the above queries will
result in answer containing a TXT record synthesized by the wildcard.
Really, DNS wildcards are almost completely useless.
In the case of SPF, it is probably best to restrict the use of wildcards to
a subdomain specific to SPF because of the way other records "obscure" a
wildcard. However, even in that case you can run into the inconsistency I
describe above. For an 'off the top of my head' example, imagine a domain
example.com which has many users, but one of their users, an account named
joe.friday, sends mail via isp.net's servers in addition to sending via
example.com's own servers. In such a case the domain owner might choose to
publish SPF records using a wildcard:
example.com. IN TXT
"v=spf1 redirect=%{l}.user._spf.{%d}"
default._spf.example.com. IN TXT
"v=spf1 mx -all"
*.user._spf.example.com. IN TXT
"v=spf1 redirect=default._spf.example.com"
joe.friday.user._spf.example.com. IN TXT
"v=spf1 ?include:isp.net redirect=default._spf.example.com"
In this example someone who sends with a PRA of <account AT example.com>
will need to comply with "mx -all", while someone who sends with a PRA of
<joe.friday AT example.com> can use the relaxed restriction of
"?include:isp.net mx -all". However, note that the domain owner has to
watch out for the PRA of "friday AT example.com" or "iam.joe.friday AT
example.com" since these PRA's could trigger the inconsistency I describe
above - possibly permitting an unscrupulous sender to bypass the domain's
SPF restrictions.
-Richard