Re: [dmarc-ietf] NXDOMAIN

[Douglas Foster <[e-mail]>]

No typo.   I was looking to do better than SPF NONE, and NXDOMAIN was the
first thing that came to mind.

If the SPF Policy lookup returns NXDOMAIN, then we are at a full stop with
all the information needed to make a decision.   (The sender is violating
ICANN name registration policies).   Ignoring NXDOMAIN and continuing to
look for MX/A/AAAA is a waste of information and a waste of resources.

But clearly, the norm in this group is to check MX/A/AAA because it seems
likely to be a more powerful filter.   I wonder if that is actually true.
1)  A/AAAA is a pretty weak test, since many domains have A/AAAA records on
the domain name for web purposes.
2) Existing domain names that are being used for attacks are likely to have
an MX record, if for no other reason than updating a LetsEncrypt
certificate.
 Will someone collect data on frequency that a domain fails MX/A/AAA when
the domain exists?

Additionally, the connection between mail sending (SPF) and mail receiving
(MX/A/AAAA) seems tenuous to me.   Well-run domains do not send automatic
messages to unauthorized return paths, for fear of backscatter.   Many
domains seem to discard incoming automatic messages, either for fear of
attack or because the reply is too hard to integrate into automated systems.

I do respond to SPF NONE by applying a best-guess SPF policy which includes
MX and A, and sometimes produces SPF PASS.   But I no longer do that for
non-existent domains.

I can imagine collecting MX and A existence data while evaluating the
default SPF policy, but I worry about the complexity of doing so, and doubt
the benefit.   Doing it as a separate step is easy enough, but adds
unwanted overhead.

Overall, we have these result partitions for domains with SPF NONE:
1) Domain does not exist, NXDOMAIN
2) Domain exists but MX/A/AAAA do not exist
3) Domain exists and MX/A/AAAA exist but do not validate the source IP
4) Domain exists and source IP can be validated with MX/A/AAAA, producing
an inferred SPF PASS.

I want to be convinced that result #2 is a non-trivial volume of messages.
  If #2 is a trivial volume, then there is no loss from combining it with
#3, which makes the extra MX/A/AAAA test unnecessary

Convince me.

Doug.


On Mon, Apr 5, 2021, 9:07 PM Murray S. Kucherawy <[e-mail]>
wrote:

> On Mon, Apr 5, 2021 at 2:02 PM Douglas Foster <
> [e-mail]> wrote:
>
>> As a result of earlier discussions, I have been investigating NXDOMAIN as
>> an email filtering criteria.
>>
>> One question from those discussions was the best way to detect NXDOMAIN.
>> I realized that I needed a query which specifically returns NXDOMAIN as a
>> result, not simply the absence of a particular result.   Additionally, a
>> lookup on A/AAAA with results could represent either a domain name with no
>> host segment, or a host segment and a parent domain..   Consequently, the
>> best test seems to query for type=TXT, match=domainname.
>>
>> I have applied this rule to incoming RFC5322.MailFrom addresses and found
>> the test to be useful.  For my mail stream, 20% of the messages with
>> SPF=NONE have this result because of NXDOMAIN.  The percentages were
>> roughly equal whether evaluating unique domain names or unique messages.
>>
>> While both SPF=NONE and SPF=NXDOMAIN are indicators that the message is
>> probably unwanted, NXDOMAIN has a higher probability of being unwanted.
>>
>> I have not yet begun evaluating NXDOMAIN on the RFC5322.From address, but
>> hope to get that done in the weeks ahead.
>>
>> Is anyone else collecting data on NXDOMAIN, and able to share experience?
>>
>
> Due to terminology pedantry, I'm having trouble understanding this.
> Someone please check my math here:
>
> If I ask for MX records for example.com, NXDOMAIN comes back as the
> response's error code not if there's no MX record for that name, but rather
> if there are no records of any kind for that name.  On the other hand, if
> there's no MX but there is an A or AAAA, I'm going to get a success error
> code (NOERROR), but with an answer count of 0.
>
> So I don't know what "detect NXDOMAIN" means: Your DNS reply either has
> that error code, or it doesn't.
>
> If instead you're trying to determine whether a name can receive mail, at
> least according to DNS data, it seems to me you query one record type (MX)
> and see if you get >0 answers, 0 answers, or NXDOMAIN.  If you got
> NXDOMAIN, you're done; there's no way to route this message.  If you got 0
> answers, you should query A and/or AAAA and send there.  If you got >0
> answers, now you have to resolve the names you got to addresses; assuming
> at least one of those resolves, you have someplace to send the message.
> This is what RFC 5321 says to do.
>
> I don't think querying TXT would tell you anything more.
>
> What am I missing?
>
> -MSK
>