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= [email protected]> wrote: > 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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
