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

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:

1. IN SPF _smtp._tcp.fred.example.co.uk.
2. IN SPF _smtp._tcp.example.co.uk.
3. IN SPF _smtp._tcp.co.uk.
   
4. IN SPF _smtp._tcp.uk.
5. IN SPF _smtp._tcp.