Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

"Kurt Andersen (b)" <kboth@drkurt.com> Thu, 18 July 2019 15:42 UTC

Return-Path: <kurta@drkurt.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96081200E3 for <dmarc@ietfa.amsl.com>; Thu, 18 Jul 2019 08:42:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyTgQD1S3Q6j for <dmarc@ietfa.amsl.com>; Thu, 18 Jul 2019 08:42:51 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7088312008B for <dmarc@ietf.org>; Thu, 18 Jul 2019 08:42:51 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id o9so52225179iom.3 for <dmarc@ietf.org>; Thu, 18 Jul 2019 08:42:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yWIm5L6kr37zCOm2u+Bcfa2HP4OZBIQGlOmmtFVLjjE=; b=fs8NbyOmZFM/70uw2Zk+3/MmoeirSSMAX64tg7SpdDI8nd5I3c29eDiH/p1wNcrwNi +7t3xi89Z0Ydji4Cg3UUzpOjVRdjtEbc/JRpEy5bLlRPwgwP018MY+YkB8WAuTRzN17d SJ8KWU5iVnZmmkGko/NOdscxMONyc/RC36ZAM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yWIm5L6kr37zCOm2u+Bcfa2HP4OZBIQGlOmmtFVLjjE=; b=nsYk1QYNbGLHB4dqeyicdAQaWmpEGGdmN9PS8fh1YvKus8JbfD1K2MZg8x0MZS2BoU UiuGGME0+k8qbCA8icEXIqzSBHgcB3bhhkhoWuLcvvTBNqzPGwYThcBoz3rgcFviN00p jY+LxXCliQ+uGLogEyty//wQqrbjcCthefcARPlrJcV75qGJEAgAzNwtUHZaQWWL69i5 vsv+F8S9MfKvVPorR7jne3+6416uesnTkuhi5/hVovgiVQO7DARERDFHIZ/q1OgS584p TaFGIRqrjBZQQHa4wUbAhivtrHFCNAK20Bobx5rtMOH7qPFDresOnReapP1fAT2xFKlh Qx4Q==
X-Gm-Message-State: APjAAAU+1zSt7HwLs84XnU0uSO7Iy2GU3HCk8OpZhgFVvdhb/fzjq3UO /UO7E2FmggxehmIVwbi4rF1wK6AvQEDSo+dMnkyU05gXK+g=
X-Google-Smtp-Source: APXvYqw10Ao+p680Iv7/wDWVTicLlrpxBRJvLudvWFepjCl8vCEgwGmEQSU0netVmMrp/WqFRvHRXTcnqICVXXwaaHk=
X-Received: by 2002:a6b:fb10:: with SMTP id h16mr34196590iog.195.1563464570409; Thu, 18 Jul 2019 08:42:50 -0700 (PDT)
MIME-Version: 1.0
References: <CAL0qLwbbz_UhBLsURg=eXhRBC2g9OghiN==T9Uq9pFuLtd=b7w@mail.gmail.com> <CABuGu1rSyifv0B9RtD3_R2ex-sh+nVrh4Q3H=kU=ZsDWzVRAgQ@mail.gmail.com> <E272FCC0-1616-4172-9B2D-D397EC2024FB@kitterman.com> <4249121.lBB2AW0kmB@l5580>
In-Reply-To: <4249121.lBB2AW0kmB@l5580>
From: "Kurt Andersen (b)" <kboth@drkurt.com>
Date: Thu, 18 Jul 2019 08:42:36 -0700
Message-ID: <CABuGu1qGJq2fes9B1vwb1v=JMi3HcydvzDvoi0+ZrEwC4rYk1A@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000056af92058df67622"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/1OUQ0fUeQTUBQX8JVeyw5tqnIk4>
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2019 15:42:54 -0000

On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman <sklist@kitterman.com>;
wrote:

> > On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)" <kboth@drkurt.com>;
> > wrote:
> > >Firstly, I'm a little concerned with the sentence which says 'Note that
> > >"np" will be ignored for DMARC records published on subdomains of
> > >Organizational Domains and PSDs due to the effect of the DMARC policy
> > >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.' I
> > >don't
> > >think that is an accurate portrayal. When DMARC evaluation libraries
> > >are
> > >updated to do both PSD lookups and handle the np tag, I would expect
> > >the
> > >presence of np tags below the PSD level would be processed exactly the
> > >way
> > >that any other tag in a DMARC record is processed. np will only be
> > >ignored
> > >(per the terms of the DMARC spec) when it is an "unrecognized" tag. I
> > >realized that this text is sort of picked up from the current
> > >description
> > >of "sp", but the inclusion of "and PSDs" makes it inaccurate. You can't
> > >publish an np record on a non-existent Org domain or any subdomain
> > >thereof
>
> At first, I thought Kurt was right, but after further thought, I don't
> think
> so.
>
> To review the 'sp' definition that I took this from:
>
> Imagine sub.sub.example.com where example.com is the org domain.  If
> sub.sub.example.com has no DMARC record, then the next lookup is for a
> DMARC
> record at the org domain (example.com).  If sub.example.com has a DMARC
> record
> with an 'sp' tag, it's never retrieved.
>
> The same thing would apply to 'np' when used in a non--PSD context.  No
> different.
>
> Keeping in mind that our definition of non-existent is a domain that has
> none
> of A, AAAA, or MX.  It could have other types.  It could also have
> subdomains
> called "_dmarc" that have TXT records.  Non-existent domains (in our
> context)
> can have DMARC records, so I think the description is correct, but
> narrowly
> focused.
>

Most MTAs will also follow CNAMEs. Should they be included (along with
other things like DNAME records) within the scope of existence? I'm a
little concerned that we are making a special definition of "non-existence"
which differs from the standard DNS concepts of NODATA and NXDOMAIN without
having a correspondingly special name.


> Modifying the example I used above slightly:
>
> Imagine sub2.sub1.org.example where example has a PSD DMARC record with
> 'np',
> org.example has no DMARC record, sub1.org.example also has a DMARC record
> with
> 'np', and sub2.sub1.org.example has no DMARC record.  In this case, the
> policy
> lookup is for sub2.sub1.org.example (exact domain), org.example (org
> domain),
> and then example (PSD).  Just as with 'sp' and regular DMARC, 'np' (or
> 'sp')
> in non-org subdomains of PSDs don't get discovered.
>

I was considering the case of a domain such as
subX.sub1.org.pub2.pub1.example:
* subX (and sub1) domains would only have direct lookup DMARC records
applied if they exist and would fall back to org
* org would be direct unless it doesn't have a record in which case if fall
back to LPD (pub2's record)
* pub2, pub1, and example would only have direct lookups since they are
already above the PSL line <-- this is where my concern with the "and PSDs"
phrase resides

I'm not sure how well this maps to what we describe. I'm also concerned
that a wildcard null MX record at the org level would end up having all
subdomains "exist", but the policy that should be applied would be the more
restrictive "np" policy, not the (possibly) more permissive "sp" policy.

--Kurt