DMARC mitigation fails if TXT record name contains uppercase

[Robert Mathews]

Using Mailman 2.1.33. I noticed that occasionally, DMARC mitigations for aol.com "From" addresses were not being applied.

I tracked us down to the fact that DNS records can in rare cases return "AOL" in uppercase in the answer of the TXT record lookup. Here's an example where I caught it happening:

 $ dig _dmarc.aol.com TXT

 [...]

 ;; QUESTION SECTION:
 ;_dmarc.aol.com. IN TXT

 ;; ANSWER SECTION:
 _dmarc.AOL.com. 492 IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:<email address hidden>; ruf=mailto:<email address hidden>;"

Note that we requested "_dmarc.aol.com" in the question section, but got back "_dmarc.AOL.com" in the answer section. That case mismatch makes this code in Mailman/Utils.py skip the record:

        for name in want_names:
            if name not in results_by_name:
                continue

I believe the solution is to lowercase the result after the lookup. Patch attached.

[Mark Sapiro (msapiro)]

Thank you for the report. I've never seen this (or maybe just never noticed it), but I accept that it happens. I suspect at some point Mailman may have received a message From: <email address hidden> and looked up _dmarc.AOL.com in DNS and a result is cached. This message may be properly mitigated because there was no case mismatch, but a subsequent message From: <email address hidden> gets the cached result and there is a case mismatch.

However, when I try `dig _dmarc.aol.com TXT` and `dig _dmarc.AOL.com TXT` multiple times in succession the case in the answer always matches the question, so that may not be the reason.

[Robert Mathews (rob-launchpad-net)]

I think it is probably the reason. A lookup with the uppercase version makes it get cached with the uppercase label if (and only if) it's not in your recursive nameserver's cache to start with.

So to test this, you either have to flush the resolver's cache first, or try a lookup of something that's not likely to be in the resolver's cache to start with, like this domain name I own:

dig _dmarc.newWAVErevisited.com TXT

When I try that one repeatedly, the first time I get this result, which is not from the resolver's cache (note the 60 second TTL):

;; ANSWER SECTION:
_dmarc.newwaverevisited.com. 60

But subsequent times I get the uppercase "WAVE" from the cache:

;; ANSWER SECTION:
_dmarc.newWAVErevisited.com. 57

(This is with BIND 9.10.3 as the recursive caching nameserver in my case.)

So it does seem like this problem would happen when someone "From: <email address hidden>" sends a message *and* the DMARC record isn't in the resolver's cache.

(I've seen aol.com DMARC mitigations fail on two separate occasions within the last month, but the first time I couldn't trace the root cause because the uppercase entry had already expired from the cache. I just happened to catch it quickly today by good luck.)