I am arguing for the position that all unregistered domains are inherently
invalid, because they are not registered.
PSD for DMARC proposes that non-existent domains should be blocked. In their
discussions, I remember the UK government reporting that they had registered
27,000 domains simply so they could publish SPF -ALL, in an attempt to block
spammers from spoofing their government agencies. I have a problem with the
definition they chose in their document, but I fully agree that this is a
problem that should be fixed.
They have also suggested that their "np" policy has general applicability, an
argument which I find compelling. By "general", I mean non-existent TLDs,
non-existent public suffixes below the TLD, non-existent organizations, and
non-existent subdomains of organizations.
Their experience demonstrates that an undefined domain is very difficult to
protect.
....
On tree walk, I was working from John Levine's proposal, which assumes that a
tree walk has to be distance limited for performance reasons. He tentatively
proposed four levels. If you walk up the tree and find no DMARC entry, the
walk stops with the conclusion that no policy has been issued. This approach
works if (and only if) the tree exists, so that the organization can place a
policy at every fourth level. The approach cannot work if the tree can be
extended with non-existent domains. It also conflicts with the PSD proposal
which requires checking the top of the tree structure.
I had considered the top-down approach also, for the same reasons as you
mentioned. I assumed that it would be rejected because of the load placed on
upper levels of the DNS hierarchy.
But when mulling the PSD problem with the tree-walk problem, I realized the
unifying problem in all of these scenarios was unregistered domains.
Eventually the problem became further defined as, "Why should unregistered
domains be considered acceptable by default, despite a network-wide requirement
for all domains to be registered."
For the moment, it is a DMARC issue to me because DMARC has accepted the notion
that unregistered domains are acceptable by default. If that can be changed,
I agree that there are other documents that need to be updated as well.
DF
----------------------------------------
From: "Murray S. Kucherawy" <superu...@gmail.com>
Sent: 11/21/20 8:05 PM
To: Doug Foster <fost...@bayviewphysicians.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP
On Sat, Nov 21, 2020 at 5:02 PM Murray S. Kucherawy <superu...@gmail.com> wrote:
On Sat, Nov 21, 2020 at 3:12 PM Douglas E. Foster
<fosterd=40bayviewphysicians....@dmarc.ietf.org> wrote:
- 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"?
Why is this a DMARC problem that needs solving?
- 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.
You're going to have to give us an example of what you're imagining here.
Presumably fabricating a few levels of non-existent subdomains of paypal.com
would look like foo.bar.baz.paypal.com; a simple tree walk then would be to
look for records in these places:
foo.bar.baz.paypal.com
bar.baz.paypal.com
baz.paypal.com
paypal.com
I would expect a policy to be present at least at "paypal.com", so the walk
stops there. How is that "unusable"?
Someone in DNSOP, I think, proposed doing the tree walk in the other direction.
The reason: If you're going to get an NXDOMAIN, it is more likely to come
earlier, and it's dispositive that way. For instance, if the above sequence is
reversed, you would probably get an NXDOMAIN at the second query
("baz.paypal.com") and then you know you don't need to look any further.
-MSK
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
