>> When I talk about scale [1], it's not just a matter of doing DNS lookups. >> That's important, but it's not what I worry about because we can solve >> it by adding more hardware [2]. Instead, by "scale" I mean "management", >> that is, having humans manage the process, or needing humans to do something.
> But thats the same problem for everything. How will MS work it out > for your hotmail.com SPF operations? For SPF, hotmail.com has a > relaxed SPF policy with a long list of DNS lookups. Lots of > processing waste here. For DMARC, thousands, perhaps millions, high > volume of mail are getting NXDOMAIN on the expectation there is a > DMARC record. Hi, Hector, sorry to derail your point, but I don't understand your point as it relates to what I was saying. At Microsoft, there's a dedicated team (handful of people) who manage the SPF record and there's a change review process, and expertise moves out of the team gradually. Still, there are people that are assigned to it. In addition, Hotmail.com fits into the 10 DNS lookup limit as required by the RFC. My point was that Hotmail can inventory what all of its IPs are, and updates its DNS records manually. But plenty of others don't know what their IPs are; furthermore, Office 365 does email hosting for small, medium, and large businesses. The part that doesn't scale is the following: 1. For Hotmail, every mailing list that our users are signed up for would result in a new DNS entry. How do we manage the lifecycle around that? Should we automate its addition? Should we automate its removal? Do we delay email before the DNS entries are published? Should we thereby bypass the change review process? If so, how do we audit what's going in and what's coming out of the Hotmail zone? 2. For Office 365, we can't publish DNS entries for most of our customers. We could tell them what to publish but I guarantee you almost none of them would for every single mail list their users signed up for, if they had to do it every day. Most of them probably wouldn't even do it once. That's the part that doesn't scale. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Hector Santos Sent: Tuesday, April 14, 2015 2:48 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Publishing and Registration Concerns On 4/14/2015 3:03 PM, Terry Zink wrote: > Hi, Doug, > >> TPA-Label operates within its own sub-domain. This >> sub-domain can be delegated or use DNAME. >> How is the scaling issue really worse than the changes >> currently required for SPF? In fact, SPF often entails more >> DNS transactions per use > > When I talk about scale [1], it's not just a matter of doing DNS lookups. > That's important, but it's not what I worry about because we can solve it by > adding more hardware [2]. Instead, by "scale" I mean "management", that is, > having humans manage the process, or needing humans to do something. But thats the same problem for everything. How will MS work it out for your hotmail.com SPF operations? For SPF, hotmail.com has a relaxed SPF policy with a long list of DNS lookups. Lots of processing waste here. For DMARC, thousands, perhaps millions, high volume of mail are getting NXDOMAIN on the expectation there is a DMARC record. Are we at a point where all DNS TXT-based solutions will need to be converted to in-band mail only solutions and we eliminate DNS from the picture? if ADID == SDID DO DNS_DMARC else DNS PROBLEM TOO HARD. Is that what we going to tell the DNS folks on last call? The better solution was punted because interfacing with DNS people is a tough problem. That is what is astonishing me the most here. Billion dollar corporations saying this problem is too hard for them to address. Wow. I'm sorry, but it seems odd that we were going for a far more complex workaround that has security holes just because the we can't get the DNS folks involved as part of the solution package when DNS is required in the first place. This all seems very strange to me to read this. I don't mind an In-band solution as an OPTIONAL alternative to the more optimized, more secured, more technically feasible, time tested simple DNS lookup solution. The IETF, this WG, the chairs owes it to the interested industry participants to offer and provide a solid solution, even if it involves getting DNS administration involved. -- HLS _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
