Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

[Douglas Foster <[e-mail]>]

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 <[e-mail]>
wrote:

> On Thu, May 6, 2021 at 5:02 PM Douglas Foster <
> [e-mail]> 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
>