Re: [dmarc-ietf] Draft 10 notes: NXDOMAIN

[Douglas Foster <[e-mail]>]

I agree that NXDOMAIN is the correct test to use for the NP policy, and as
close as we can get to perfection.

As for the reference to RFC 8020, whether NXDOMAIN does or does not exclude
subdomains, the effect on our specification is small.   But it does seem
important to not repeat information that appears to be occasionally
incorrect.

A relevant issue is whether NXDOMAIN is a valid test for non-existence of a
TLD or PSD.   I expected the answer to be NO, on the theory that some TLDs
or PSDs will not support DNS SEC and therefore not have RRSIG records, and
in many cases would not have reason to contain any other resource record
either.  However, in this week's testing, every TLD or PSD tested is
returning NODATA.   So I don't understand my results.

Doug


On Tue, Jun 28, 2022 at 2:03 PM Todd Herr <todd.herr=
[e-mail]> wrote:

> On Mon, Jun 27, 2022 at 8:36 PM Douglas Foster <
> [e-mail]> wrote:
>
>> My testing was done more than a year ago.   My recollection is that I
>> discovered it based on something in the wild, and then confirmed it with a
>> locally-configured experiment.   This time I am having trouble finding
>> examples.
>>
>> The only one I can verify is from a previous email exchange on this forum:
>>
>> mail.foodnetwork.com
>> returns NXDOMAIN
>>
>> but
>> _dmarc.mail.foodnetwork.com
>> returns DATA for type=TXT
>>
>
> Thank you for the further information.
>
> In regards to RFC 8020, rev -10 of DMARCbis currently reads as follows:
>
> 7.8.  <#m_-63867453221050999_section-7.8>Domain Existence Test
> <#m_-63867453221050999_name-domain-existence-test>
>
> RFC 7489 used the test specified in [RFC5321
> <#m_-63867453221050999_RFC5321>] to determine a domain's existence. This
> test requires up to three DNS lookups for the MX, A, and AAAA RRs for the
> name in question.¶ <#m_-63867453221050999_section-7.8-1>
>
> This version of the protocol relies solely on the test for existence as
> defined in [RFC8020 <#m_-63867453221050999_RFC8020>]. If a query for a
> name returns NXDOMAIN, then the name does not exist.
>
> <#m_-63867453221050999_section-7.8-2>
> But I'm not sure that this is correct, especially not the first sentence,
> because here's what RFC 7489 has to say on the topic:
>
>
>  <https://datatracker.ietf.org/doc/html/rfc7489#appendix-A.4>
>
> A.4 <https://datatracker.ietf.org/doc/html/rfc7489#appendix-A.4>.  Domain Existence Test
>
>    A common practice among MTA operators, and indeed one documented in
>
>    [ADSP <https://datatracker.ietf.org/doc/html/rfc7489#ref-ADSP>], is a test to determine domain existence prior to any more
>
>    expensive processing.  This is typically done by querying the DNS for
>
>    MX, A, or AAAA resource records for the name being evaluated and
>
>    assuming that the domain is nonexistent if it could be determined
>
>    that no such records were published for that domain name.
>
> *   The original pre-standardization version of this protocol included a*
>
> *   mandatory check of this nature.  It was ultimately removed, as the*
>
> *   method's error rate was too high without substantial manual tuning*
>
> *   and heuristic work.*  There are indeed use cases this work needs to
>
>    address where such a method would return a negative result about a
>
>    domain for which reporting is desired, such as a registered domain
>
>    name that never sends legitimate mail and thus has none of these
>
>    records present in the DNS.
>
>
> The first two sentences in the second paragraph from RFC 7489 seem to contradict the statement in DMARCbis that "RFC 7489
>
> used the test specified in RFC 5321 to determine a domain's existence."  This would argue for the text of "Domain Existence
>
> Test" in DMARCbis to be reworded.
>
>
> The "np" tag didn't exist in RFC 7489, and it's not clear to me that RFC 7489 cared all that much about whether a domain existed.
>
> In DMARCbis, however, the "np" tag does exist, and so it seems we must settle on a way to determine whether or not a domain exists,
>
> and RFC 8020 seems to be the more efficient method than RFC 5321, as it requires just one query, not three.
>
>
> As to the particulars of your example, I'm not sure there's any difference regardless of the method chosen, as queries for an A, AAAA,
>
> and MX records for the name "mail.foodnetwork.com" all return NXDOMAIN just as does a query for ANY. Those results are, for me,
>
> enough reason to reject a message prior to attempting any DMARC processing, because if the domain in the From: or Return-Path:
>
> header doesn't exist, then the message cannot be replied to and is therefore not worthy of being accepted. This is consistent with the
>
> above statement from RFC 7489 - "A common practice among MTA operators ... is a test to determine domain existence prior to any
>
> more expensive processing." The fact that AWS's DNS servers don't adhere to RFC 8020 and return an answer for _dmarc.mail.foodnetwork.com
>
> would be meaningless to me here, because I'd never ask the question.
>
>
> For those MTA operators who don't think like I do, DMARCbis is clear on which policy to use for a non-existent RFC5322.From domain:
>
>
> If the DMARC policy to be applied is that of the RFC5322.From domain, then the DMARC policy is taken from the p= tag of the
>
> record. If the DMARC policy is taken from either the Organizational Domain or the Public Suffix Domain and that domain is different
>
> than the RFC5322.From domain, then the DMARC policy is taken from the sp= tag (if any) if the RFC5322.From domain exists and
>
> the np= tag (if any) if the RFC5322.From domain does not exist. In the absence of applicable sp= or np= tags, the p= tag policy
>
> is used for subdomains.
>
>
> This would mean in this case that for those sites that adhere to the DMARCbis specification and elect to accept mail from non-existent
>
> domains, the policy published at "_dmarc.foodnetwork.com" would apply to this message (p=none), rather than the policy published
>
> at "_dmarc.mail.foodnetwork.com" (p=reject), and if the domain owner of mail.foodnetwork.com wanted different behavior, they would
>
> ensure that mail.foodnetwork.com passes an existence test in DNS.
>
>
> --
>
> *Todd Herr * | Technical Director, Standards and Ecosystem
> *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
>