Re: The state of DNS support, was Deprecating SPF
Jay Daley <[email protected]>
| Newsgroups | gmane.ietf.dnsext |
|---|---|
| Message-ID | <[email protected]> |
Hi Douglas On 28/08/2013, at 5:10 PM, Douglas Otis <[email protected]> wrote: > 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. An interesting point of view, but orthogonal to my proposal. People are already using TXT in the way you caution against and we aren't going to stop that except by deprecating TXT. My proposal does not address whether or not this usage is a good idea but how we tidy split out some of that usage into a more manageable form. >> = 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. It's not an alias for TXT, it's a semantically different record. Disruption is prevented by use of a prefix registry. >> 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. What are those? >> 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. The hashed list of labels is only appropriate in ATPS because a Verifier has a signature and wants to check the originator of that signature. That's quite different from this case where the SPF verifier has an email from sub.example.com and wants to know what policy to apply. It can't just take a punt that the policy to use is that of example.com and then construct a hash of that and check to see if it is listed. BTW the irony of ATPS using a TXT record for this hashed label list may have escaped you. Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley _______________________________________________ dnsext mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsext