[dns-operations] SERVFAIL/FORMERR for TXT mta.email.(office|microsoftonline).com
Mark Andrews
marka at isc.org
Fri Nov 7 21:55:06 UTC 2014
On further investigation the office.com servers are insane. They
are synthesizing delegating NS record which match the query name.
This results in broken delegation.
Named looks at the answer. See that something is wrong based on
which zone it is querying into, logs FORMERR and moves onto the
next server trying to find a good answer. When all the servers
return bad answers it returns SERVFAIL to the client.
Microsoft needs to fix this.
Mark
; <<>> DiG 9.11.0pre-alpha <<>> email.office.com @ns1.msedge.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23390
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;email.office.com. IN A
;; AUTHORITY SECTION:
email.office.com. 3600 IN NS NS1.ExactTarget.com.
email.office.com. 3600 IN NS NS2.ExactTarget.com.
;; Query time: 13 msec
;; SERVER: 204.79.197.1#53(204.79.197.1)
;; WHEN: Sat Nov 08 08:38:17 EST 2014
;; MSG SIZE rcvd: 93
; <<>> DiG 9.11.0pre-alpha <<>> mta.email.office.com @ns1.msedge.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41135
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;mta.email.office.com. IN A
;; AUTHORITY SECTION:
mta.email.office.com. 3600 IN NS NS1.ExactTarget.com.
mta.email.office.com. 3600 IN NS NS2.ExactTarget.com.
;; Query time: 12 msec
;; SERVER: 204.79.197.1#53(204.79.197.1)
;; WHEN: Sat Nov 08 08:38:04 EST 2014
;; MSG SIZE rcvd: 97
; <<>> DiG 9.11.0pre-alpha <<>> 41241234231kk.mta.email.office.com @ns1.msedge.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37480
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;41241234231kk.mta.email.office.com. IN A
;; AUTHORITY SECTION:
41241234231kk.mta.email.office.com. 3600 IN NS NS1.ExactTarget.com.
41241234231kk.mta.email.office.com. 3600 IN NS NS2.ExactTarget.com.
;; Query time: 14 msec
;; SERVER: 204.79.197.1#53(204.79.197.1)
;; WHEN: Sat Nov 08 08:39:53 EST 2014
;; MSG SIZE rcvd: 111
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
More information about the dns-operations
mailing list