I initially asked this question on the mailop list
<http://chilli.nosignal.org/mailman/listinfo/mailop> and a reply
mentioned this list. So....
We check and enforce SPF HELO (not SPF MailFrom) checks. Since most
senders don't set up SPF (TXT RR) records for their sending systems
there isn't many issues. (We figure if you have taken the time to set
up a SPF record for your HELO names, you know what you are doing.)
So today, I saw a SPF HELO temp rejection for a connection from
mta.email.office.com [68.232.192.175]. When I tried to do a
dig -t TXT mta.email.office.com.
I get a SERVFAIL which per the SPF spec should result in a 451 SMTP
response. When doing a
dig -t A mta.email.office.com.
I get a NOERROR with an answer section containing the A record. Now in
the BIND server logs, the TXT record looked up is logged as a
FORMERR resolving 'mta.email.office.com/TXT/IN': 66.231.91.222#53
or
FORMERR resolving 'mta.email.office.com/TXT/IN': 66.231.94.222#53
depending on which name server replied. Note that email.office.com. is
delegated to an email service provider (ESP).
Googling for FORMERR, leads me to the DNS server considered the query from
my recursive server to be formated incorrectly.
I tried the same queries from my home network (different network
connectivity, different OSes, different dig versions) and got the same
results. Two other users on the mailop mailing also tried and got the same
results.
What makes this weird is that if I use Google's recursive servers with
dig -t A mta.email.office.com. @8.8.8.8
I get the A record back as expected, but when doing
dig -t TXT mta.email.office.com. @8.8.8.8
I get a NOERROR with a blank answer which is what I would expect for an
entry without a TXT record. So Google's DNS recursive servers seem OK.
It gets even more interesting in that a
dig -t TXT exacttarget.com. @66.231.91.222
returns the TXT records just fine. As a query of
dig -t TXT ns1.exacttarget.com. @66.231.91.222
returns with a empty response and a NOERROR status.
So querying ns1.exacttarget.com [66.231.91.222] for
-t A mta.email.office.com => returns expected result
-t TXT mta.email.office.com. => returns client format error
-t A exacttarget.com. => returns expected result
-t TXT exacttarget.com. => returns expected result
-t A ns1.exacttarget.com. => returns expected result
-t TXT ns1.exacttarget.com. => returns expected result
Kind of odd that one query returns an error.
In the time that I noticed this yesterday, I think I have found a second
ESP that has a sub-domain delegated to it from their customer and getting
similar results.
So, my questions to the list is
1) Can others reproduce the error using their DNS environment?
2) Anyone can explain what is going on?
--
***********************************************************************
Derek Diget Office of Information Technology
Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/
***********************************************************************
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
