PK> [...] the question of whether a prefix is necessary or not is of
PK> course closely related to the choice of RR type. TXT would need
PK> a prefix, a new type would not.
A new resource record type would require a "prefix" for exactly the same
reasons that the "TXT" resource record type would. The benefit of a
prefix in this instance is to reduce DNS response sizes, and it applies
both to abusing the "TXT" resource record type and to using a new
resource record type.
To see why this is, one needs to look at what DNS lookups SMTP Relay
clients and servers actually perform, and one needs to look at how the
"SRV" resource record type could have been defined but wasn't.
Even 3 years after the publication of RFC 2821, which obviated the
requirement that caused these to be done in the first place, many SMTP
Relay client softwares _still_ perform "ANY" DNS lookups instead of
separate "CNAME" and "MX" lookups (or, better yet in light of RFC 2821,
just "MX" lookups). By adding SPF-style information to, say, the domain
name "aol.com.", the size of the response to an "ANY" query for that
domain name is increased (and hence so too is the likelyhood of
incurring the overhead of falling back to using DNS/TCP).
Note two important points here:
* Everyone thinks of the DNS lookups that SMTP Relay servers will be
performing, but forgets that (because so many softwares lag more than 3
years behind the times), SMTP Relay _clients_ will be affected too,
since they perform "ANY" lookups on the very same set of domain names
(i.e. those that occur in the domain name portion of an SMTP mailbox name).
* The actual type of the resource record is irrelevant. A 128-octet
"TXT" resource record added to "aol.com." will have the same particular
effect of increasing the size of an "ANY" response as a 128-octet "FOO"
resource record would.
Now consider how "SRV" resource records could have been designed, but
weren't. "SRV" resource records _could_ have been designed to
incorporate the protocol and the service names in their data portions
example.org. IN SRV 86400 nicname tcp 0 0 43 whois.example.org.
example.org. IN SRV 86400 ldap tcp 0 0 389 dir.example.org.
example.org. IN SRV 86400 http tcp 0 0 80 www.example.org.
and service lookup would have involved performing a "SRV" lookup and
then scanning the resultant resource record set, which would have grown
with each new service defined and provided, for resource records with
names that matched the desired service. (Do this design and its
concomitant problems seem somewhat familiar, boys and girls?)
Instead, "SRV" resource records were designed so that the service and
protocol names were encoded in the owner domain name,
_nicname._tcp.example.org. IN SRV 86400 0 0 43 whois.example.org.
_ldap._tcp.example.org. IN SRV 86400 0 0 389 dir.example.org.
_http._tcp.example.org. IN SRV 86400 0 0 80 www.example.org.
and thus so that individual "SRV" resource record sets only covered
single services. Thus, looking up the locator information for an
individual service doesn't present one with a whole slew of information
about services that one wasn't interested in, that one then has to wade
through picking out what one wants; and, also, the sizes of "SRV"
resource record sets don't grow as "SRV" lookup is defined for further
services.
In database terms (and without going into detail about the DNS database
schema): The primary key for the global, distributed, DNS database is an
<owner-name,class,type> tuple, and service lookup encodes an
<service-domain-name,class,type,protocol,service> search key into that
tuple, thereby making use of the DNS lookup mechanism to ensure that the
lookup yields only those data that are actually relevant.
Client-restriction data in fact uses a very similar
<client-domain-name,class,type,protocol,service> search key, which can
be encoded in the same way. Ironically, this would have been clearer if
we didn't have "MX" resource records but had used "SRV" resource records
to find SMTP Relay servers. The pairing of
_smtp._tcp.example.org. IN SRV 86400 0 0 25 a.mx.example.org.
to locate the "example.org." SMTP Relay servers and
_smtp._tcp.example.org. IN SPF 86400 "-all"
to publish the restrictions on the "example.org." SMTP Relay clients
would have seemed relatively straightforward.