ns1-proddns.glbdns.o365filtering.com unreachable?
Anyone else with trouble to reach the *.o365filtering.com DNS Servers?
Yes, there seems to be a global outage: July 6, 2022 11:03 AM Title: Some users may experience delays when sending or receiving email messages in Exchange Online User Impact: Users may experience delays when sending or receiving email messages in Exchange Online. More info: Users may see the message status being stuck on 'Pending' or 'Getting Status'. Current status: We're analyzing service telemetry information to determine the next troubleshooting steps. Scope of impact: Impact is specific to some users who are served through the affected infrastructure in Europe, Middle East, and Africa. Next update by: Wednesday, July 6, 2022, 1:30 PM (11:30 AM UTC) -- Cas de Reuver http://reuver.co On Wed, Jul 6, 2022 at 11:03 AM Thomas Mieslinger <miesi@mail.com> wrote:
Anyone else with trouble to reach the *.o365filtering.com DNS Servers?
On Wed, Jul 06, 2022 at 11:37:40AM +0200, Bjoern Franke via NANOG <nanog@nanog.org> wrote a message of 10 lines which said:
<tenant>.mail.protection.outlook.com seems to throw servfails.
The authoritative name servers for this domain do not handle EDNS (which was specified only 23 years ago) so the resolvers that do not fallback on EDNS (probably the majority) return a SERVFAIL. Seen with RIPE Atlas probes: % blaeu-resolve -r 500 --type NS mail.protection.outlook.com [ns1-proddns.glbdns.o365filtering.com. ns2-proddns.glbdns.o365filtering.com.] : 319 occurrences [ERROR: SERVFAIL] : 138 occurrences [] : 1 occurrences Test #42222155 done at 2022-07-06T09:24:50Z
On Wed, 2022-07-06 at 11:49 +0200, Stephane Bortzmeyer wrote:
On Wed, Jul 06, 2022 at 11:37:40AM +0200, Bjoern Franke via NANOG <nanog@nanog.org> wrote a message of 10 lines which said:
<tenant>.mail.protection.outlook.com seems to throw servfails.
The authoritative name servers for this domain do not handle EDNS (which was specified only 23 years ago) so the resolvers that do not fallback on EDNS (probably the majority) return a SERVFAIL.
While it is true that their auths do not handle EDNS, they cover that by responding with FORMERR without an EDNS section. All resolvers should in fact fall back.
From what I can tell, the real problem is that these servers barely respond at all - so little that it's easy to conclude that EDNS is the reason, but without EDNS responses are just as sporadic.
So, in short, they have a DNS responding problem; their bad handling of EDNS makes that worse, because now a resolver needs to get two queries (one with EDNS, then one without) through to them before resolving something - and then it is rewarded with a 10 second TTL! Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/
On Wed, Jul 06, 2022 at 12:15:31PM +0200, Peter van Dijk <peter.van.dijk@powerdns.com> wrote a message of 28 lines which said:
So, in short, they have a DNS responding problem; their bad handling of EDNS makes that worse, because now a resolver needs to get two queries (one with EDNS, then one without) through to them before resolving something
Thanks, you're right and I was wrong. It seems it now works again. Note these authoritative name servers have other problems. For instance, when receiving NS queries, they put the answer in the Answer section but not for SOA requests.
participants (5)
-
Bjoern Franke -
Cas de Reuver -
Peter van Dijk -
Stephane Bortzmeyer -
Thomas Mieslinger