Re: [dnsext] SPF isn't going to change, was Deprecating SPF
On Sat, Aug 24, 2013 at 08:39:36AM -0400, Phillip Hallam-Baker wrote: On Fri, Aug 23, 2013 at 3:46 PM, manning bill bmann...@isi.edu wrote: the question is not that nobody checks type 99, the question is is the rate of adoption of type 99 -changing- in relation to type 16? As John pointed out, support for checking type 99 has decreased and continues to decrease rather than increase. So waiting longer is not going to solve the issue. that is unclear... we have second hand reports, but only actual data from very recent DNS logs. did those numbers increase or decrease? No evidence has been presented. Putting a statement in an RFC does not mean that the world will automatically advance towards that particular end state. ain't it the truth. -BUT- its still worthwhile documenting the best technical path and why it was abandoned. The issues wrt wildcards (thanks), DNSSEC considerations, and code overhead to demux type 16 vs. the temporary problem of two lookups -IF- type 99 is not used, plus past guidance from the IAB and the IESG really need to make it into a document in the RFC cannon. Forcing a WG to adopt a position to suit another constituency is not going to lead them to advocate for that position in deployment constituencies. Particularly when the original constituency does nothing to advance deployment. Dorthy Parker said: You can lead a whore to culture, but you can't make her think. Point the bias arrow either way youd like. And as stated elsewhere, if Yahoo, Google, Microsoft, AOL, et.al. were simply waiting for the IETF to settle on a solution, I'll raise O'Dells law; The installed base does not matter. End of the day, the SPFBIS wg is adament in their choice, document, explain and move on. Robert Heinlein: Never try to teach a pig to sing; it wastes your time and it annoys the pig. I think the SPFBIS folks are annoyed enough... -- Website: http://hallambaker.com/ ___ dnsext mailing list dns...@ietf.org https://www.ietf.org/mailman/listinfo/dnsext
Re: [dnsext] SPF isn't going to change, was Deprecating SPF
On Sat, Aug 24, 2013 at 6:43 PM, bmann...@vacation.karoshi.com wrote: On Sat, Aug 24, 2013 at 08:39:36AM -0400, Phillip Hallam-Baker wrote: On Fri, Aug 23, 2013 at 3:46 PM, manning bill bmann...@isi.edu wrote: the question is not that nobody checks type 99, the question is is the rate of adoption of type 99 -changing- in relation to type 16? As John pointed out, support for checking type 99 has decreased and continues to decrease rather than increase. So waiting longer is not going to solve the issue. that is unclear... we have second hand reports, but only actual data from very recent DNS logs. did those numbers increase or decrease? No evidence has been presented. We have statements from people who are involved in the industry concerned and no reason to believe that they are lying. This is not a reasonable objection and it is really not at all surprising that people are getting rude when people are refusing to accept what the WG considers established facts. Putting a statement in an RFC does not mean that the world will automatically advance towards that particular end state. ain't it the truth. -BUT- its still worthwhile documenting the best technical path and why it was abandoned. The issues wrt wildcards (thanks), DNSSEC considerations, and code overhead to demux type 16 vs. the temporary problem of two lookups -IF- type 99 is not used, plus past guidance from the IAB and the IESG really need to make it into a document in the RFC cannon. I don't think it was ever about the right technical path. It was about the DNSEXT group not caring to bother to get their DNSSEC infrastructure adopted by the constituencies they needed buy in from then trying to make that effort the problem of the SPF people. Forcing a WG to adopt a position to suit another constituency is not going to lead them to advocate for that position in deployment constituencies. Particularly when the original constituency does nothing to advance deployment. Dorthy Parker said: You can lead a whore to culture, but you can't make her think. Point the bias arrow either way youd like. And as stated elsewhere, if Yahoo, Google, Microsoft, AOL, et.al. were simply waiting for the IETF to settle on a solution, I'll raise O'Dells law; The installed base does not matter Its a stupid and wrong 'law'. The deployed base is all that matters because before you get to the 'viral marketing' network effects give you the 'chicken and egg problem'. The reason HTTP and the Web took off was because we actually designed it to take off fast. Meanwhile IPv6 and DNSSEC are still in the same state they were 15 years ago, on the cusp of deployment in 5 years time. A large part of the reason has been that the people pushing those initiatives have acted as if deployment was inevitable. I ran simulation studies of adoption to work out how to sell the Web. The companies you cite have no stake in DNSSEC deployment. So why expect them to favor a technical measure designed to facilitate DNSSEC deployment? -- Website: http://hallambaker.com/
Re: [dnsext] SPF isn't going to change, was Deprecating SPF
On Fri, Aug 23, 2013 at 3:46 PM, manning bill bmann...@isi.edu wrote: the question is not that nobody checks type 99, the question is is the rate of adoption of type 99 -changing- in relation to type 16? As John pointed out, support for checking type 99 has decreased and continues to decrease rather than increase. So waiting longer is not going to solve the issue. Putting a statement in an RFC does not mean that the world will automatically advance towards that particular end state. Forcing a WG to adopt a position to suit another constituency is not going to lead them to advocate for that position in deployment constituencies. Particularly when the original constituency does nothing to advance deployment. -- Website: http://hallambaker.com/
Re: [dnsext] SPF isn't going to change, was Deprecating SPF
Phillip Hallam-Baker wrote: On Fri, Aug 23, 2013 at 3:46 PM, manning bill bmann...@isi.edu wrote: the question is not that nobody checks type 99, the question is is the rate of adoption of type 99 -changing- in relation to type 16? As John pointed out, support for checking type 99 has decreased and continues to decrease rather than increase. So waiting longer is not going to solve the issue. However, the interest never disappeared. The issue is what are we waiting for now? The DNS infrastructure support? Why it that such a problem? Who goes to these IETF meetings? Where are the Microsoft DNS product managers in these discussions? What do they have to say? Putting a statement in an RFC does not mean that the world will automatically advance towards that particular end state. Thats correct. No one is forced to support RFC 4408bis. From my perspective, there are four basic major changes to BIS - all optional: 1 - Add Authentication-Result: 5322.header. 2 - Relax SPF HardFail Policy rejections to Accept-Mark operations. 3 - If 2 is perform, then add code to separate user failed messages. 4 - Remove any support for SPF type99 queries and publishing. For our SPF implementation, we never did #4 for lack of infrastructure readiness but are ready to support once the the backbone is ready for it. We will probably will do #1 for all non-HARDFAIL result but we won't do #2 because it will cause a high redesign cost with #3. Not performing #3 would be a major security loophole is you begin to support #2. Until we are ready to do #3 and close that security loophole, #2 won't happen. Forcing a WG to adopt a position to suit another constituency is not going to lead them to advocate for that position in deployment constituencies. Particularly when the original constituency does nothing to advance deployment. +1, but the decision makers really haven't ask the main DNS constituencies why they have not advanced their (DNS) software or made it flexible enough for another operators and administrators to add/manage new RR types or capable of passive and transparent handling of unknown type recursive passthru queries. To me, this should be a project leadership responsibility to make sure the protocol requirements are realistic are not. -- HLS
Re: [dnsext] SPF isn't going to change, was Deprecating SPF
Hector Santos wrote: Phillip Hallam-Baker wrote: Putting a statement in an RFC does not mean that the world will automatically advance towards that particular end state. Thats correct. No one is forced to support RFC 4408bis. From my perspective, there are four basic major changes to BIS - all optional: 1 - Add Authentication-Result: 5322.header. 2 - Relax SPF HardFail Policy rejections to Accept-Mark operations. 3 - If 2 is perform, then add code to separate user failed messages. 4 - Remove any support for SPF type99 queries and publishing. For our SPF implementation, we never did #4 for lack of infrastructure readiness but are ready to support once the the backbone is ready for it. We will probably will do #1 for all non-HARDFAIL result but we won't do #2 because it will cause a high redesign cost with #3. Not performing #3 would be a major security loophole is you begin to support #2. Until we are ready to do #3 and close that security loophole, #2 won't happen. I should add: 5- Deprecate PTR by removing PTR publishing support We won't advocate this because for our small to mid size market, this is the lowest cost setup for them - using a PTR. For all our domains, we use PTR as well. No need to change it. This is one of those Set it and Forget it SPF record setups. Using the PTR was the default arrangement for most small/mid operations provided by most if not all the SPF Web Wizards. This was removed in Scott's popular SPF wizard but not in other SPF wizards. Note: The overhead concerns are passe with the trend of SMTP receivers doing PTR lookups, thus any transaction SPF validator will not contribute to any PTR network overhead. -- HLS
Re: [dnsext] SPF isn't going to change, was Deprecating SPF
Hector Santos hsan...@isdg.net wrote: Hector Santos wrote: Phillip Hallam-Baker wrote: Putting a statement in an RFC does not mean that the world will automatically advance towards that particular end state. Thats correct. No one is forced to support RFC 4408bis. From my perspective, there are four basic major changes to BIS - all optional: 1 - Add Authentication-Result: 5322.header. 2 - Relax SPF HardFail Policy rejections to Accept-Mark operations. 3 - If 2 is perform, then add code to separate user failed messages. 4 - Remove any support for SPF type99 queries and publishing. For our SPF implementation, we never did #4 for lack of infrastructure readiness but are ready to support once the the backbone is ready for it. We will probably will do #1 for all non-HARDFAIL result but we won't do #2 because it will cause a high redesign cost with #3. Not performing #3 would be a major security loophole is you begin to support #2. Until we are ready to do #3 and close that security loophole, #2 won't happen. I should add: 5- Deprecate PTR by removing PTR publishing support We won't advocate this because for our small to mid size market, this is the lowest cost setup for them - using a PTR. For all our domains, we use PTR as well. No need to change it. This is one of those Set it and Forget it SPF record setups. Using the PTR was the default arrangement for most small/mid operations provided by most if not all the SPF Web Wizards. This was removed in Scott's popular SPF wizard but not in other SPF wizards. Note: The overhead concerns are passe with the trend of SMTP receivers doing PTR lookups, thus any transaction SPF validator will not contribute to any PTR network overhead. That's not correct. PTR is not removed from the protocol, so software support shouldn't change. I don't run an SPF wizard. It's not just about overhead. Scott K
Re: [dnsext] SPF isn't going to change, was Deprecating SPF
On 23August2013Friday, at 11:04, John Levine wrote: Nobody has argued that SPF usage is zero, and the reasons for deprecating SPF have been described repeatedly here and on the ietf list, so this exercise seems fairly pointless. the reasons for not deprecating SPF have been described here and on the ietf list repeatedly ... yet there has been little concrete data regarding deployment uptake. Sigh. We have RFC 6686. Since this is clearly an issue you consider to be of vital importance, it is baffling that (as far as I can tell) you did not contribute to or even comment on it when it was being written and published. work assignments occasionally take me away from active engagement in IETF matters. sorry for the few years absence. Those of us in the mail community have a lot of anecdotal evidence, too. Most notably, none of the large providers that dominate the mail world publish or check type 99, and the one that used to check type 99 (Yahoo) doesn't any more. You don't have to like it, but it's silly to deny it. not sure why you think the DNS data presented is anecdotal. Looked kind of empirical to me. i've not seen a yahoo person describe what they have or have not done or why. we have no data on why Microsoft may or may not support type 99 (see Jay's questions). Much of the mail community data seems anecdotal… very little first hand, empirical stuff. (and I thank you for your data) In any event, it's purely a strawman that nobody checks type 99. A few people do, the WG knows that, and we decided for well documented reasons to deprecate it anyway. demuxing type 16 records is a choice. using type 99, which was specifically designed for this use, is a choice. using application specific types have distinct technological advantages (see PHB comments). They may be small, but are real and have an impact on the DNS and the application. regarding the specific claims regarding adoption, I was asking for a brief period to collect more empirical data to track the magnitude and ratio of type 99 v. type 16 use (noting, as PAF has already noted, that not all type 16 == type 99, so for accurate understanding - someone needs to look at type 99 muxed into a type 16 format… if only to correctly understand the change in ratio. the question is not that nobody checks type 99, the question is is the rate of adoption of type 99 -changing- in relation to type 16? R's, John
