Subject: Re: DEPLOY: Over-running TXT dataspace in FQDN (-protocol I belie ve)

From: Jonathan de Boyne Pollard <[email-masked]>
Date: Mon, 13 Sep 2004 16:39:30 +0100

The existence of names block wildcards at that name, and for any name below that name.

True for wildcards when one follows the RFC 1034 algorithm, and the
operation of wildcards on some content DNS server softwares in some
configurations.  However, not true in the general case.  Wildcards
operate differently in several content DNS server softwares.

For example 1: With Dan
Bernstein's tinydns, the existence of mx.example.org.
does not prevent *.example.org. from matching a.mx.example.org..
Only an explicit a.mx.example.org. record, of any type,
does that.

For example 2: With Microsoft's DNS server configured
to use "loose wildcarding", the existence of mx.example.org.
does not prevent *.example.org. from matching a.mx.example.org..
Only an explicit a.mx.example.org. record of the
requested type does that.

Ironically, these both provide the behaviour that people often actually
want (and ask for, again
and again)
when they set up wildcard "MX" resource record sets, but that the RFC
1034 algorithm does not give them.

It is true that wildcards are not useful as a default "fall-back" record solution. They never were.

One better fallback mechanism would be to adopt the same fallback
mechanism as used by nsupdate and the
de facto WHOIS service DNS lookup scheme, namely if the domain name
in question is fred.example.co.uk., perform the following
lookups:

IN SPF _smtp._tcp.fred.example.co.uk.

IN SPF _smtp._tcp.example.co.uk.

IN SPF _smtp._tcp.co.uk.

IN SPF _smtp._tcp.uk.

IN SPF _smtp._tcp.