Here are the tests that I am looking to define:
*The existence / non-existence test:* Given an identifier which is presumed to be a DNS domain name, perfrom a DNS lookup based on that name. The query may: - return results using data from the identifier domain - return results using data from a parent domain - return NXDOMAIN If the result is definitely from the identifier domain, the domain name exists If the result is NXDOMAIN, the domain does not exists If the result is from the parent domain, the results are uncertain. Is there a query or collection of queries that can ensure that we only accept results from the identifier domain and not from the parent? *Wildcard DNS:* Wildcard entries create intentional ambiguity. How do we suggest that wildcard results should be factored into the evaluation? *The mail-enabled test:* Once existence / non-existence is determined, is it desirable to test for "mail enabled"? If so, what role should parent-domain results play in answering this question? If "Mail Enabled" is relevant, why is the existence of an SPF policy irrelevant? If "mail enabled" is used, this creates implicit DNS configuration requirements on the domain owner. New requirements should be stated quite explicitly. On Fri, May 7, 2021 at 3:06 PM Murray S. Kucherawy <[email protected]> wrote: > On Thu, May 6, 2021 at 5:02 PM Douglas Foster < > [email protected]> wrote: > >> I have begun data collection on the effectiveness of the MX and A tests. >> Wildcard DNS entries increase the frequency of false positives and reduce >> the usability of the test. For example, "msaqq189.ford.com" returns a >> set of MX results, but I rather doubt that I made a lucky guess and found a >> mail domain that Ford Motor actually uses. >> > > There's no need to guess. You can query for wildcard records: > > $ host -t mx '*.ford.com' > *.ford.com mail is handled by 10 cluster4.us.messagelabs.com. > *.ford.com mail is handled by 20 cluster4a.us.messagelabs.com. > > -MSK >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
