On Thu, Apr 8, 2021 at 4:51 PM Douglas Foster <
[email protected]> 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:* [email protected]
*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.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
