Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]