Re: [dmarc-ietf] NXDOMAIN

[Douglas Foster <[e-mail]>]

I am happy to have the concept optimized.  Your comments make sense to me.

  I just believe strongly that these documents teach implementers best
practices and that this particular document is the time and place to begin
teaching best practices around non-existent domains.

It is swell that postfix is widely used and responds appropriately to
non-existent domains  But clearly we have a lot of implementers who need
coaching.

DF

On Fri, Apr 9, 2021, 9:09 AM Todd Herr <todd.herr=
[e-mail]> wrote:

> 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.
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>