Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition of NP

Doug

In looking for domain presence most folks will look at the domain itself.
There are a few web tools to enumerate
such as https://dnschecker.org/

Some examples
https://dnschecker.org/#MX/dmarc.org
https://dnschecker.org/#TXT/dmarc.org
https://dnschecker.org/#TXT/_dmarc.dmarc.org

There are unix tools - such as 'dig' - which are also quite useful.

hope this helps
tim

On Thu, Nov 19, 2020 at 10:44 PM Douglas E. Foster <fosterd=
40bayviewphysicians.com@dmarc.ietf.org> wrote:

> Time to show my ignorance again.
>
> How do I check a domain for presence or absence of A, AAAA, or MX records?
> I thought most domains were protected from enumeration, so one had to know
> a name to find out if it is defined
>
> DF
>
>
> ------------------------------
> *From*: "Douglas E. Foster" <fosterd@bayviewphysicians.com>
> *Sent*: 11/19/20 9:27 PM
> *To*: "IETF DMARC WG" <dmarc@ietf.org>
> *Subject*: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd:
> Definition of NP
>
> Thank you for the pointer Eric.
>
> Can someone explain why the chosen algorithm, which requires testing
> multiple conditions, is preferable to a single query for a name server
> record?   Minimizing DNS traffic has been part of our recent discussion,
> and minimizing software complexity is always a good thing.
>
> Can someone also explain why the DMARC appendix takes such a strong stance
> against all queries for non-existent domains, regardless of technique?  It
> seems like the philosophical incompatibilities need to be addressed before
> both documents advance.
>
> DMARC is specified only as a test for the RFC5322.From domain.
> RFC5321.MailFrom domains may also be non-existent.  They will return SPF
> NONE, but that is an ambiguous result, and SPF has no organization default
> mechanism.
>
>    - Is there data to indicate whether evaluators have found that
>    checking the RFC5321.MailFrom for non-existence is useful?
>    - Suppose that the NP policy becomes generalized, and a domain has
>    asserted a "must-exist" DMARC policy.   Should a non-existent subdomain
>    used in the RFC5321.MailFrom address be treated skeptically?
>
> I can imagine a scenario where a spammer uses a bogus subdomain of a
> legitimate organization, in an attempt to get whitelisted by spam filters
> which primarily evaluate the RFC5321.MailFrom address.   This attack could
> be paired with an unrelated and non-DMARC RFC5322.From address which is
> newly minted or otherwise not generally known to be suspicious,   So my
> instinct is that some extension of DMARC to the SMTP address will be
> beneficial.
>
> Doug Foster
>
>
>
>
> ------------------------------
> *From*: "Chudow, Eric B CIV NSA DSAW (USA)" <eric.b.chudow.civ@mail.mil>
> *Sent*: 11/19/20 5:31 PM
> *To*: 'Doug Foster' <fosterd@bayviewphysicians.com>, 'IETF DMARC WG' <
> dmarc@ietf.org>
> *Cc*: "'dmarc-chairs@ietf.org'" <dmarc-chairs@ietf.org>
> *Subject*: RE: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd:
> Definition of NP
>
> Section 2.7. defines a non-existent domain as "a domain for which there is
> an NXDOMAIN or NODATA response for A, AAAA, and MX records. This is a
> broader definition than that in NXDOMAIN [RFC8020]." This should be
> sufficient for determining that the domain is not intended to be used and
> therefore could have a more stringent policy applied.
>
> The idea of looking for a "mail-enabled domain" based on if an "MX record
> exists or SPF policy exists" is interesting. Although there may be domains
> that send email but not receive email and so may not have an MX record.
> Also, even if there is no SPF record, the domain may still send email, but
> then it might be held to a more stringent DMARC policy that would further
> penalize it for not having an SPF record.
>
> Also, for the revision of the document I like the way that the three parts
> of the experiment are now laid out more clearly. My only comment is that
> the title of Appendix A is overly specific to just one of the experiments
> and so should be broader.
>
> Thanks,
>
> Eric Chudow
> DoD Cybersecurity Mitigations
>
> From: Doug Foster <fosterd@bayviewphysicians.com>
> Sent: Tuesday, November 17, 2020 9:46 AM
> To: 'IETF DMARC WG' <dmarc@ietf.org>
> Cc: dmarc-chairs@ietf.org
> Subject: Re: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd: Definition
> of NP
>
> I did not see a definition of a "non-existent domain" (the np policy).   A
> definition is needed.
>
> To my thinking, the obvious rule should be to query for a NS record for
> the domain.  If the record exists, then the domain owner could create a
> DMARC record for that domain, or could create a default entry for the
> domain at the organizational level.  If no record exists, it is because the
> domain owner chose to not create one.
>
> However, the DMARC Bis document conflicts strongly with this.  In section
> A.4, it suggest several ways to do a test of this type, then repudiates all
> of them.  NS lookup is not one of the mentioned options.
>
> There is a possible second-level policy test for a "mail-enabled domain".
> I would define that test as "MX record exists or SPF policy exists".
>  That could be an additional option to NP, but should not be a replacement
> for it.
>
> PSD for DMARC clearly intends for the NP policy to be a general solution
> to a general problem.    If there are still objections to it becoming a
> general solution, this should be addressed soon.
>
> Doug Foster
>
>
> From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Tim Wicinski
> Sent: Friday, November 13, 2020 1:42 PM
> To: IETF DMARC WG
> Cc: dmarc-chairs@ietf.org
> Subject: [dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd
>
>
> All
>
> During the IESG reviews of draft-ietf-dmarc-psd, there were several issues
> raised with some of the document.   Most of them are editorial but the one
> big item was the description of the Experiment.   The chairs sat down and
> broke out the experiment section into three separate experiments, and
> included language on how to capture the data to confirm how the experiment
> worked.
>
> It's enough of a change that we wanted to do a second working group last
> call to make sure the working group agrees with our changes. The diff of
> the current version with the previous version is here:
>
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-psd-08&url2=draft-ietf-dmarc-psd-09
>
> This starts a *one* week second working group last call for
>  draft-ietf-dmarc-psd
> Please review the changes and offer up comments to the working group.
>
> This working group last call 20 November 2020
>
> Thanks,
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>