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....@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" <fost...@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....@mail.mil> > *Sent*: 11/19/20 5:31 PM > *To*: 'Doug Foster' <fost...@bayviewphysicians.com>, 'IETF DMARC WG' < > dmarc@ietf.org> > *Cc*: "'dmarc-cha...@ietf.org'" <dmarc-cha...@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 <fost...@bayviewphysicians.com> > Sent: Tuesday, November 17, 2020 9:46 AM > To: 'IETF DMARC WG' <dmarc@ietf.org> > Cc: dmarc-cha...@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-boun...@ietf.org] On Behalf Of Tim Wicinski > Sent: Friday, November 13, 2020 1:42 PM > To: IETF DMARC WG > Cc: dmarc-cha...@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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
