On Thursday 26 August 2004 11:10 am, Hallam-Baker, Phillip wrote:
While David is right, there is also the corollary that *.example.com
will only match nodes that do not exist at all. So there are two issues,
do wildcards work as expected, is the wildcard useful at all. The matching
behavior means that the wildcard is not useful for the use cases given.
i.e. if we have
a.example.com
*.example.com. IN TXT "v=spf1 ..."
Will match _marid.b.example.com, b.example.com but not a.example.com
regardless of whether a has TXT records or not.
This is correct.
So you can't use a wildcard to give a default SPF record for DNS
names of hosts that exist. Only the hosts that don't exist will match.
I don't know what happens for _marid.a.example.com, I think it should
not match but one of the DNS people can say for sure.
You are correct, it does not match. The existence of names block wildcards at
that name, and for any name below that name. To be explict, if your zone
has:
*.example.com. IN TXT "spf2.0/..."
a.example.com. IN A 1.2.3.4
but does not contain:
b.example.com.
Then queries for "b.example.com. IN TXT, _marid.b.example.com. IN TXT,
something-else.b.example.com. IN TXT", will all return the TXT record.
Queries for "a.example.com. IN TXT, _marid.a.example.com. IN TXT,
anything-else.a.example.com. IN TXT" will not return the TXT record.
IF _marid.a.example.com did match the wildcard then it would be a way
to make the wildcards useful.
For some use cases. It is true that wildcards are not useful as a default
"fall-back" record solution. They never were.
To my mind, the paramount issue of wildcard wrt MARID is that for folks who
*currently* use wildcards (i.e., for wildcard MX records), the MARID solution
should be deployable, and it is, with or without a _marid prefix.
--
David Blacka <davidb(_at_)verisignlabs(_dot_)com>
Sr. Engineer VeriSign Applied Research