Long story short… The Data MCP team has pretty much determined that 184.108.40.206/24 is used by DMARC to authenticate AOL mail set with a strict policy. If you are behind a firewall, which we know many third-party IP providers use, you may inadvertently be blocking this range from accessing your DNS records. You will see more Service Unavailable 421 errors as a result.
The back story… Our network has been experiencing higher than normal traffic load and packet loss. After extensive investigation we found DNS lookups coming from 220.127.116.11/24 in very high volume, to domains which were no longer active. rDNS had not been updated and these queries were coming in for the incorrect domain. Traffic was snowballing across 1000 subdomains/queries.
Queries to properly set rDNS domains are minimal, however, and we suspect this is because DMARC could authenticate and cache the authenticated results, while the fails check over and over.
At first, we mistook the fails for a DNS Amplification DDoS attempt on the clients mailing IPs. But when we blocked 18.104.22.168/24 at the router, packet issues disappeared and AOL deferrals rose immediately. Open the range again and the network would slow but 250 Success returned.
So, the ISP has corrected rDNS and we are waiting to see the failed lookups correct to the new domains/rDNS.
Then we thought, “What about IPs from other sources, who operate behind a firewall?” They use a strict firewall and we don’t see any traffic AT ALL coming from 22.214.171.124/24, AND delivery is shit. We contacted that ISP and requested they open their firewall to this traffic under the assumption it was not malicious, but in fact necessary for DMARC and IP longevity. As soon as they opened the pipe, we saw the lookups pointing right back to DMARC, and the number of successfully delivered messages immediately rose from poor to decent.
Moral of the story… If you mail with DMARC authentication, make sure, if you are hosting your own DNS, that your firewalls permit 126.96.36.199/24, and that your IP providers also permit this traffic. If you are using third-party DNS, you might want to mail with NO DMARC because this could inflate your bill a bit. Also be sure not only to have rDNS set, but that it’s set accurately to match your forward DNS, otherwise the failed lookups will start to clog your network for no good reason.
If you’re asking yourself, “How do we work with these guys? Sounds like they know a thing or two.” Just visit us at www.DataMCP.com and we’ll put our expertise to work for you.