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

[Derek Diget]

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/
***********************************************************************