Re: SPF isn't going to change, was Deprecating SPF

In message <[email protected]>, Andrew Sullivan writes:
> Hi,
> 
> Thanks for the outline of the transition strategy.  Let me walk
> through it, piece by pice, and see how it works.  I'm going to use
> "SPF-99" and "SPF-16" in what follows to disambiguate the query cases.
> I'll call the existing SPF implementations "SPFCheck" -- no matter
> what they do -- and the new implementations that prefer SPF-99 first,
> then SPF-16 "SPFCheckNG".
> 
> On Sat, Aug 24, 2013 at 12:36:57PM +1000, Mark Andrews wrote:
> 
> > You say MUST query for SPF and if there is a NO DATA response you
> > MAY query for TXT.  Modern spf libraries already do this.  Legacy
> > SPF checkers are no longer compliant.  Even checkers running under
> > Windows can meet this MUST.
> 
> I am an SPF validator.  On day 0, there are very few people publishing
> SPF-99 records, and many publishing SPF-16 records.  I have a lot of
> mail volume coming in.  What is my incentive to embrace SPFCheckNG?
> Please address the latency effects for large mail operators.

Most of the latency should be handled be handled in app / on machine
DNS caches.  Add dns hammer support in the caches and almost all
of the rest of the latency is gone.

> > You say that nameservers SHOULD synthesis SPF records from TXT
> > v=spf1 records.  This helps registrars stuck with broken web
> > interfaces.  Code for this is written.
> 
> I'm an operator of a DNS zone.  I publish TXT and SPF records.  On day
> 0, there are very few people publishing SPF-99 records.  What is my
> incentive to deploy code that aoutomatically increases my storage cost
> and my opportunity for bugs, given that everyone who accepts my mail
> is satisfied with SPF-16?

Given there is code that synthesizes SPF records at query time that
is a essentially a subset of DNS64 code (only looks at answers being
retrieved from zone data).  I would say there are zero storage costs
and the code to do SPF synthesis is simple so there really is
extremely low risk of bugs here.  Would you like to audit it?

DNS64 was 100x more complicated than SPF record synthesis yet we
have RFC's for how to do that.

> > You say that nameservers SHOULD reject loading of zones without SPF
> > records when there are v=spf1 TXT records.  This provides education
> > for everybody else.  Code for this is written.
> 
> I'm an operator of a DNS zone.  On day 0, my zone works.  What is my
> incentive to accept a new DNS server software update that makes my
> zone broken, given that it was working on day 0-1?
>
> I offer my thanks in advance for your investigation of the answers to
> the above.
> 
> Best,
> 
> A
> 
> -- 
> Andrew Sullivan
> [email protected]
> _______________________________________________
> dnsext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email protected]
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext