The problem I have is not so much with the decision to deprecate SPF
rrtype, it will remove this particular SPF protocol dual SPF/TXT call
overhead in the network, but more so about what it says for future
applications.
There will no incentive to design DNS applications with specific types,
or it will always be a specific sub-domain TXT record. Is that good or bad?
In many ways, the industry has gotten "comfortable" with overall
non-compiled, non-binary, text-based applications. Improvements in
hardware and software has made it all feasible.
Consider that once upon a time Microsoft's Caller-ID Policy (now
SenderID) considered XML-formatted TXT record before merging with SPF. [1]
Consider that a SMTP receiver is now faced with new overheads and
redundancy with at least 4-8 DNS Calls, and except for one, they are all
TXT:
o RFC5321 SMTP level (before DATA state)
- Growth in PTR requirement (rDNS) for connecting SMTP client,
- SPF HELO/EHLO domain check (optional) (RFC4408),
- SPF MAIL FROM domain check (RFC4408)
- SPF MAIL FROM SUBMITTER domain check (RFC4405)
o RFC5321 SMTP level (DATA) or RFC5322 Post Acceptance processing:
- DKIM Trust Domain public key check (RFC6376)
- ADSP Author Domain Policy check (RFC5617)
- VBR Trust Domain Check (RFC5518)
- SenderID PRA domain check (RFC4406/4407)
- Possible future new fast track DMARC proposal [2]
And they all have one common application need; get domain
attributes/information.
Lets consider that these new TXT applications are authored by the same
few folks with the same engineering mindset to use TXT since it is the
most practical and offers the fastest entry point to the market and
proof of concept.
There are many integration issues to consider. We should look at a
better solution where minimal calls can be made to extract domain
operational information. I have a few ideas in this area and have even
drafted yet another TXT-based solution. What the above redundant domain
information lookup did do was force us to redesign, update and single
source our DNS resolutions across all components in our
application/service servers. That is because many of the above open
source protocols come with libraries with their own DNS resolvers
clients software. So we wrote our own and implemented each of the above
protocols to use a single DNS API. This allowed us to offer a local DNS
cache to remove all overhead in the redundancy. This also remove most
of any doubt with customer's uplink DNS resolvers which can be behaving
differently - a big savings in support cost.
I would like to have the option to support the SPF rrtype when and if we
implement RFC4408BIS as deployment options to customers. There are
already new changes to the spec that will promote implementation changes
(Accepting SPF Failed Message deployment option and a new
Authentication-Result: trace header).
I believe the decision to pull SFP rrtype at this time (for RFC4408BIS)
was premature and would like to see the design opportunity to support
not only SPF rrtype but others. I suggest to keep the migration path in
RFC4408BIS with new implementation details.
I would also like to believe that the IETF can help get the DNS
infrastructure updated to help support these modern DNS application
requirements. To my surprise, Microsoft DNS v5.0 which is what we have
for our primary DNS server on a Windows 2003 machine, does not support
RFC 3597 "Handling of Unknown DNS Resource Record (RR) Types" and it did
not offer a method to add new ones.
Why is that? Don't they have a stake in all this too? Are they reading
these IETF forums?
Maybe this could be a plenary topic for you guys to talk about at these
IETF meetings - "Supporting new DNS Applications: Improving the Quality
of the DNS infrastructure."
--
HLS
[1] nslookup -query=txt _ep.hotmail.com
Non-authoritative answer:
_ep.hotmail.com text =
"<ep xmlns='http://ms.net/1'
testing='true'><out><m><indirect>list1._ep.hotmail.com</indirect><indirect>list2._ep.hotmail.com</indirect><indirect>list3._ep.hotmail.com</indirect></m></out></ep>"
[2] http://www.dmarc.org/draft-dmarc-base-00-02.txt
[3] http://tools.ietf.org/html/rfc3597
On 4/30/2013 8:45 PM, Sam Hartman wrote:
I think I understand this issue well enough to comment and so I will.
1) I totally believe it is reasonable to consider operational challenges
when designing protocols. "Just upgrade your infrastructure, just use
another registrar, just upgrade the infrastructure of the people you
communicate with," are not generally reasonable advice to give people;
ingoring these concerns tend to lead to things that cannot be deployed.
2) I think it's fine to come up with a solution that is harder to
implement because it is easier to deploy given the sorts of concerns in
1.
3) having reviewed the DNS arguments, I generally would recommend txt
records with distinct owner names over new RR types for most
protocols. I understand there are residual issues with that approach.
4) Using txt RRs the way SPF does--where the owner name is shared
potentially with other applications is kind of unfortunate. I don't
know it's unfortunate enough to push for the SPF RR. But the issues
people have brought up with regard to updates and RR order are very
real.
But so are the operational issues with SPF.
So my personal opinion is that this is a valid discussion to be having
even if we're having it again in IETF LC. However, to be successful we
need to get new participants and to ad more respect for arguments to the
discussion.