Re: The state of DNS support, was Deprecating SPF

On Aug 27, 2013, at 9:00 PM, Jay Daley <[email protected]> wrote:

> On 26/08/2013, at 1:28 PM, Andrew Sullivan <[email protected]> wrote:
> 
>> This isn't religion: I'm as sickend by
>> this use of TXT as anyone.  But the world makes us as much as we make
>> the world, and I think the TXT fight _in this case_ is lost.
> 
> Having thought about this for a few days I've changed my mind and I'm happy to see SPF(99)  go.  What clinched it for me was this note from Andrew above as it helped me realise my issue is with the misuse of TXT and not the solution of a new type specific to SPF.  So let's let it go and I'm sure with a bit of thought we can find a way to fix the overloading of TXT and try to sell that as a better migration path for "v=spf1" in TXT than SPF(99) ever was.

Dear Jay,

The current SPF specification may require receivers to emit as many as 222 DNS transactions in an effort to aggregate required data.  In contrast, a well considered APL scheme should offer the needed data within one RRset transaction in binary form to support a store and forward protocol.

> =  We know the issues can be summarised as:
> 
> 1.  The key benefits people find from using TXT are
> - it is well supported
> - it is free form so any experimentation is possible and no standards body engagement is needed

Running complex scripts just above DNS is a security risk, especially when it represents experimentation where support is often limited a few advocates. 

> 2.  The key issues with the use of TXT are
> - people not using prefixes and so conflating various uses (and as Hadriel points out, no prefix registry)
> - the wildcard issue, which I'm going to restate as how to define a policy at one level that applies to lower levels, is a key reason for not wanting to use prefixes.

A prefix approach kills wildcard schemes.  Since overwhelming use of SPF establishes outbound address ranges for an email domain, TXT represents a remarkably inefficient approach.  Even the policy "all" is largely ignored.  DNS was never intended to offer heavily formatted textual data in the manner of HTTP.  Bulky data requires a reliable transport that introduce significant delay.  This would be silly since that is what is expected of the message transport.  In other words, bulk data is being carried by the wrong transport.

> = So here's an example solution (and I mean an example since I'm sure there is a lot more to consider):
> 
> 3.  Create a new generic record for free form policy data that must be prefixed by protocol.  For example:
> 
> _spf	.example.com.	POL	"a:mail.example.com -all"

Why? If POL is an alias for TXT, this disrupts _dmarc, _adsp, _atps that convey concise and small amounts of data at a prefix.

> If we provide that one record then anyone can use it for any policy info without further need to change the DNS.  To me that seems much more utilitarian than a protocol specific RR.
> 
> = A solution for the wildcard issue is a bit more complex, but here's an example
> 
> 4.  Add an rdata field to the POL record that if set to "*" (asterisk) applies this policy to the next level
> 
> _spf.example.com. 	POL	*	"a:mail.example.com -all"

Already being done as an "alignment" flag in other policy records.

> This record is then used to synthesise the POL record in exactly the same way that a wildcard is.
> 
> 5.  Or we could add a record under each sub-domain that refers back up a level:
> 
> _spf.sub.example.com.	POLPTR	example.com.

sub.example.com could offer authoritative  policy for sub.example.com?  atps offers authorization for a list of domains using a hash label list.  Both small and fast. 

Regards,
Douglas Otis


_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext