What are the complications to DMARC of tolerating unregistered domains? - If unregistered domains are tolerated, PSD for DMARC helps address the problem of a unauthorized domains underneath a public suffix, such as "example.uk". But what DMARC policy will solve the problem of an invalid TLD, such as "example.q"?
- If unregistered domains are tolerated, then a limited-scope tree walk becomes unusable. A spammer would be able to fabricate a few levels of non-existent subdomains, and suddenly PayPal.com becomes a domain tree with no detectable DMARC policy. Besides, a scope-limited tree walk conflicts with the requirements of PSD for DMARC. An unlimited-scope tree walk has performance risks to both the evaluator and the DNS infrastructure. Doug Foster ---------------------------------------- From: "Murray S. Kucherawy" <superu...@gmail.com> Sent: 11/21/20 2:12 PM To: Doug Foster <fost...@bayviewphysicians.com> Cc: Doug Foster <fosterd=40bayviewphysicians....@dmarc.ietf.org>, IETF DMARC WG <dmarc@ietf.org> Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP On Sat, Nov 21, 2020 at 9:02 AM Douglas E. Foster <fosterd=40bayviewphysicians....@dmarc.ietf.org> wrote: Restating what we all know: - The Internet is dependent on the reliable operation of the DNS name system. - The DNS name system is dependent on the reliable operation of the name registration processes. - The registrars are given ownership of all unregistered domain names within their portion of the hierarchy. - The public evidence of registration is the existence of a DNS entry, and a NS record is always the first one configured. Conclusions - Unregistered use of any domain name is an attack on the architecture of the Internet. - PSD for DMARC is asking us to give public suffix operators what they are supposed to already have: control over unregistered names. - We should implement new and universal policies:- Unregistered names used as SMTP addresses MUST generate SPF FAIL and SHOULD be rejected. That is certainly a defensible assertion, but I would claim it is out of scope for DMARC. You're talking about a detail of SPF or perhaps of SMTP in general, although one could also even argue that this is a local policy decision and outside the scope of those protocols. I suspect the SMTP greybeards would claim that this is not part of SMTP, but rather an enforcement choice made by implementations. I believe this falls within the realm of what the IETF calls an Applicability Statement, which would be a standards track document (if you could get consensus for it). You could also include this in the DMARC usage document, or as non-normative advice in DMARC itself with an explanation of why it's a good idea, if you can develop consensus to do so. You also need to account for transient DNS outages. If your resolver temporarily thinks "gmail.com" doesn't exist, you will bounce all mail coming from that domain, and you might seriously piss off your users. There's a backscatter problem here too: If I send mail to a list you're on and you temporarily think my domain doesn't exist and you bounce mail coming from me, the list will unsubscribe you. - Unregistered names used as message From header addresses MUST generate DMARC FAIL and SHOULD be rejected. This is more in scope for DMARC discussions, though also arguably outside of the protocol itself, for the same reasons. I would suggest that it's a viable discussion for the DMARC usage document, whenever we get around to working on that again. But you could certainly test the working group opinion on this point. Protecting the integrity of the name registration system is not an optional activity to be implemented by a few organizations with the most sophisticated implementations of the DMARC specification. It should be a mandatory duty of every legitimate participant on the network. Starting from the assumption that unregistered domains might be allowable creates many problems when trying to design solutions for protecting the names that are registered. This assumption needs to be rejected. These are both probably true statements, but is DMARC the right place to wage this battle? For example, isn't it also true for TCP connections for which PTR records make false claims (or no claim)? Addressing some straw-man questions: Q: The idea is fine for public suffixes, but my organization doesn't need to do that for subdomains under its control. A: Every level of the DNS tree needs coordination of name usage. Publishing an NS record for an organization subdomain proves that the organization's process has been followed. Besides, the boundary between public suffixes and organizational domains is imprecise, so recipients cannot be expected to apply differential expectations. I still don't understand what the presence or absence of NS tells you that the presence or absence of MX/A/AAAA doesn't. If you have a message that fails the latter test but passes the former, does that change your handling decision? If not, why do it? Q. How do we get all incoming filters to change to default block for unregistered domain names? A. I would suggest using the CVE/CCE process. That seems like a big hammer, and certainly outside of the IETF's purview. We're not the protocol police. You might try having this discussion in a context like M3AAWG though; many large operators congregate there to discuss stuff like this. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
