[dns-operations] SERVFAIL/FORMERR for TXT mta.email.(office|microsoftonline).com

[Mark Andrews]

The nameservers for mta.email.office.com are misconfigured.  They
are returning negative answers as if they are configured for
email.office.com rather than mta.email.office.com (the SOA record
has the wrong owner name).  The end of "dig +trace mta.email.office.com
txt" gives:

mta.email.office.com.	3600	IN	NS	NS1.ExactTarget.com.
mta.email.office.com.	3600	IN	NS	NS2.ExactTarget.com.
;; Received 97 bytes from 204.79.197.2#53(ns2.msedge.net) in 12 ms

email.office.com.	3600	IN	SOA	ns1.exacttarget.com. hostmaster.exacttarget.com. 2014030300 7200 3600 1209600 3600
;; Received 112 bytes from 66.231.91.222#53(NS1.ExactTarget.com) in 306 ms

Mark


In message <Pine.GSO.4.62.1411071337440.24166 at spaz.oit.wmich.edu>, Derek Diget 
writes:
> 
> 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
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org