On 5/25/2004 10:45 AM, Greg Connor wrote:
Right, the assumption here is that the "closest SOA" would be a logical
place to stick a "catchall" record, if you want one record to cover
all hosts in your domain or subdomain.
It's not a bad idea, because it keeps people from having to create TXT
records to match all the MX and A records that already exist, but in
cases where they already have a wildcard for A or MX, they may still
want a wildcard TXT (since it may be different from the base MX)
See rfc2308, $2.1. Most modern servers return SOA with NXDOMAIN, but not
all of them do that (the DNS server in NT4 does not return SOA according
to my recollection, and there are plenty others).
You're also into custom resolver code in those cases where the native API
doesn't return enough information for you to make the distinction.
It should be pointed out, according to my tests, if you have a wildcard
TXT, that would cover any made-up name that doesn't have any other
records, but if you have names with A or MX but no TXT, the wildcard
TXT doesn't apply to those.
That's the way wildcards work -- they only match against owner names that
do not exist. See rfc1035 $4.3.2, step c.
Someone should probably check my results. If this is true, that
decreases the value of wildcards even more (but you still need them if
you have A or MX wildcards).
Wildcards will have to work for orgs that use them to describe other
resources (such as dynamic hosts/subdomains), but they shouldn't be used
to match against resources that do exist.
Technically, you can explicitly query for the wildcard domain name (eg,
"MARID:*.example.com"), but that will overload other functionality and
should be avoided.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/