spf ent txt records.

Vernon Schryver vjs at rhyolite.com
Mon Mar 18 15:35:08 UTC 2013


> > I'd go along with that, if they can't get their act together within 3
> > years, then that IS pure laziness.

I think "laziness" better fits answering port 443 with HTTP/TLS-SSL
and not publishing DANE RRs with existing certs or fingerprints.
The contrib/dane directory in current versions of BIND has a shell
script that I think makes doing that easy.

Also, those who are not lazy, who think RFC 4408bis is wrong, and want
to use type 99 without violating RFC 4408bis will go to the IEFF.


> Laziness can be not reading RFC6686 Appendix A: about how it is not
> rational to keep SPF RRTYPE99 and how things got confusing in part
> because of pressure from some DNS experts.

I agree that laziness can be pontificating without bothering to read,
but that text mostly blames SPF enthusiasts in points #1-#4.  The
complaints about DNS experts concern future RRTYPE problems.



} From: Mark Andrews <marka at isc.org>

} MX records took over a decade before one could have a MX only domain
} safely.

MX records have significantly benefits.  Switching from TXT to type
99 has no foreseeable operational benefit.  There never has been and
never will be flag day for MXs.

}                                                            RFC 4408
} failed to set a sunset date.

It would be the same if RFC 4408 had a sunset date, because RFC 4408
came too late.  In hindsight today, the relevant error among many far
worse and always obvious errors was not using a label like _spf.
Regardless of all of that, RFC 4408 did not set a sunset date,
and RFC 4408bis does deprecate type 99.


} It's not that is is esthetically pleasing to put SPF data into its
} own RR type.  It's that TXT has been hijacked and contining to add
} more uses to TXT does not scale.  TXT is a reasonable record for
} proof of concept.  It isn't and never has been a good long term
} choice.

I can't argue with that, but reality is that switching from TXT to
type 99 has costs and no benefits other than what most people see
as mere esthetics.  There are many features in the DDN Protocol
Suite that could have been better including scaling better, but
even 25 years ago was too late for flag days for anything in use.
All that can be done is designing something better with very low
transition costs and/or significant practical benefits and hoping
people won't be too lazy.  (e.g. DANE again)


} Turning off lookup for TXT record lookup for SPF would have very
} little negative impact.  You would have some additional spoofed
} email getting through and some additional blow back (which could
} be eliminated by publish SPF records).

I agree with this translation of that statement:

  Google, Hotmail, AOL, and the other large inbox providers could
  agree with the ESPs to ignore RFC 4408bis and switch to type 99.
  They are already violating RFC 4408 and RFC 4408bis with DMARC
  with far more operational significance.

However, my bet is that Google et al will do as many others have done.
They will care about the costs that you label "very little negative
impact" and ignore those hypothetical TXT abuse scaling problems...not
to mention complying with RFC 4408bis.
Whatever is done by vanity domains and by domains that publish ~all
or ?all without _dmarc will remain irrelevant.


Vernon Schryver    vjs at rhyolite.com



More information about the bind-users mailing list