Re: [dmarc-ietf] NXDOMAIN

[Todd Herr <[e-mail]>]

On Thu, Apr 8, 2021 at 4:51 PM Douglas Foster <
[e-mail]> wrote:

> DNS Examples that Murray requested, which should also addresses John's
> question about relevance to DMARC:
>
> nslookup
> > set type=txt
>
>
> > _dmarc.junk.thisisjunk.com
> *** <server> can't find _dmarc.junk.thisisjunk.com: Non-existent domain
>
> Domain has no DMARC policy.
> Is this because it chose not to deploy one, or because it does not exist?
>  That answer requires a second query.
>
> > junk.credcontrol.com
> *** <server> can't find junk.credcontrol.com: Non-existent domain
>
> The TXT query demonstrates that this is a non-existent domain, and
> therefore not under the full administrative control of any parent domain.
> The message is DMARC NOT_VERIFIED even if domain alignment occurs with a
> DKIM signature or SPF PASS.  Since there is no domain-level policy record,
> disposition depends on local policy related to non-existent domains and
> this particular domain name.    The organizational policy record may be
> useful if its requested action is more stringent than the local policy
> default action for non-existent domains.
>
> > junk.thisisjunk.com
> *** <server> can't find junk.thisisjunk.com: Non-existent domain
>
> Domain has no DMARC policy.
> Is this because it chose not to deploy one, or because it does not exist?
>  That answer requires a second query.
>
> >thisisjunk.com
>         primary name server = ns1.dreamhost.com
>         responsible mail addr = hostmaster.dreamhost.com
>         serial  = 2018071003
>         refresh = 19193 (5 hours 19 mins 53 secs)
>         retry   = 1800 (30 mins)
>         expire  = 1814400 (21 days)
>         default TTL = 14400 (4 hours)
>
> The TXT query demonstrates that the domain exists.   This is true whether
> the result returns data or NODATA, and in this case the result is NODATA.
> The message can be DMARC-verified using domain alignment to a DKIM
> Signature or SPF PASS.
>
> Doug Foster
>
>
> I think you may have a cut and paste error here:

> junk.thisisjunk.com

*** <server> can't find junk.thisisjunk.com: Non-existent domain

Domain has no DMARC policy.
Is this because it chose not to deploy one, or because it does not exist?
 That answer requires a second query.


The above isn't a query for a DMARC policy record.

To your larger point though and your claim of a second query being required
to determine if a domain exists if there is no published DMARC policy, I
think you've got the order of the queries exactly backward.

My expectation for any policy rules that are based on a domain's existing
and/or a domain having published an MX or A/AAAA record is that such
queries will be done *before* any attempt to suss out a DMARC policy record
and perform DMARC validation checks, not after.

For example:

   1. Client connects to my server. At this point I know the source IP of
   the client, and so I can apply any policy rules I may have in place for the
   source IP, such as rejecting the connection due to the IP's being blocked,
   refusing the connection if the IP has no corresponding PTR record, refusing
   the connection if the PTR record matches a pattern of names from which I
   don't want to accept mail (such as the naming pattern being generic or
   indicating that it's dynamic space), perhaps throttling the connection
   based on a lack of FCrDNS for the IP or other rules based on local
   reputation data known about the IP.
   2. If the connection is still open, the client issues a MAIL FROM
   command. At this point I now have a domain (RFC5321.From) and I can run
   checks to make sure the domain exists in the DNS and publishes either an MX
   or A/AAAA record and do any DNSBL lookups for the domain. I can also, if I
   wish, do the SPF check here and reject if there's a failure and the record
   ends in "-all".
   3. If the connection is still open, the client issues one or more RCPT
   TO commands. I can answer "250 ok" or "550 5.1.1 user unknown" as
   appropriate.
   4. If the client has exhausted its RCPT TO commands and has gotten "250
   ok" in response to at least one of them, then it will issue a DATA command,
   and I can respond "ok" if I still potentially want to accept a message from
   this connection.
   5. Client transmits the message, ends with "."
   6. Before I reply with "ok", I will definitely do step 1 below, and
   might do either or both of steps 2 and 3:
      1. Test for existence of the RFC5322.From domain in DNS and do any
      DNSBL lookups on the domain.
      2. Run the message through an anti-spam filtering engine, if I'm the
      type to reject mail based on its content. If instead I'd just route it to
      the spam folder if the engine says it's spam, I may do this step
at a layer
      closer to my message delivery/storage layer.
      3. Do DMARC validation checks, if I'm the type to honor a domain's
      published policy and reject mail that fails DMARC checks if
that's what the
      policy asks me to do. If instead I'm the type to apply a quarantine
      disposition to anything with p=reject or p=quarantine, I might accept the
      message so that the connection can be closed and I can do DMARC
processing
      at a layer closer to my message delivery/storage layer.

Now, I could be wrong here, but I've always viewed DNS queries as
computationally cheaper than content scanning and DKIM hash validation
(note that I'm going to do DKIM hash validation regardless of the existence
of a DMARC policy record, but it's all a matter of where in my
infrastructure I do the validation). DNS queries that allow me to make an
immediate yes/no decision on message acceptance (IP or domain on block
list, domain exists and has an MX or A/AAAA record) get done before DNS
queries that might cause me to do more work. A DNS query for a DMARC record
can result in additional work for me if the DMARC policy record exists, not
just going through the validation steps but also recording the results in
the data store that supports my reporting engine, so I'm going to do that
one last, not first.

But that's just me.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [e-mail]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.