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

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

> >The solution I would suggest is to put spfv2/pra records in 
> a sub-domain
> >such as _marid.company.com.  While it would be nice to recommend that
> >people begin allowing TCP DNS queries, it is unlikely that 
> the highest
> >volume sites would ever want to implement such.
> 
> I think it was brought up earlier that using a prefix like 
> _marid would break the use of wildcards (can't do 
> _marid.*.example.com).  But it wasn't clear (to me, at least) 
> whether wildcards would work in this application, even 
> without the prefix.  Wildcard support would be very nice to 
> have, to provide symmetry with wildcard MX records for 
> incoming mail.  Can anyone clear up whether adding the prefix 
> breaks wildcards, or were they already broken?

The situation with the prefix is as follows:

1) Standard (i.e. AXFR communicatable wildcards) do not work for ANY 
	Sender-ID use case. A wildcard only produces a match if there is
	no data whatsoever in a node. This means that this type of 
	wildcard cannot be used to make any assertions about machines
	that have a domain name entry.

2) Synthetic wildcards work fine, but are not supported in the AXFR 
	interchange format.

3) Prefixing does not prevent the use of wildcards, but if a 
	wildcard is used the advantage of using a prefix is lost.
	I.E. *.example.com will match _spf1.example.com and 
	_spf2.example.com

4) Some tools do not support prefix use - this is not a major concern
	since I would expect sender-id to be promoted mainly through 
	purpose driven tools not through grovelling TXT entries.

My opinion is that we should move to a prefix if we introduce a new 
version identifier. Otherwise we should not. There is a value to 
using a prefix but it is not by itself sufficient to make a change 
worthwhile.