So is the FORMERR ... just the resolver noting that EDNS is not supported?
If so, I'm uncertain of the issue.
We don't use EDNS here, so that's what the “our” servers should be doing, yes?
Also, when I replied (“ALL”) to this thread a bit earlier, my response was
bounced by one particular r
For EDNS to work correctly you MUST accept UDP fragmented packets, or
configure your DNS server to advertise a max EDNS packet size of about 1200
bytes.
Otherwise, bind, for instance, goes in a series of fallback and by the time
the result is available the mail server has moved on...
On Thu, Apr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2016-04-28 at 20:57 +, Michael Wise wrote:
> If the "Aware" flag expired, would best practice not be to check that
> first rather than presuppose that the facility does exist?
The check for "edns aware" involves sending the query with ed
On Thu, Apr 28, 2016 at 2:18 PM, Rob Heilman wrote:
> pitt-edu.mail.protection.outlook.com
I haven't been following this discussion, but for the purpose of
providing some historical perspective... pitt.edu seemed to have
signed their DNS two weekends ago, and upmc.edu signed their DNS last
weeke
"might ... might ..."
If the "Aware" flag expired, would best practice not be to check that first
rather than presuppose that the facility does exist?
I have no exposure to eDNS so far, so don't know much about it at all, but this
sounds like an issue with the resolver doing the wrong thing wh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2016-04-28 at 20:01 +, Michael Wise wrote:
> " All this is stating is that DNS++ does not support RFC 2671 EDNS
> protocol extensions.
> " DNS++ is responding per the RFC by sending the FORMERR back to the
> requestor. I believe this is
" All this is stating is that DNS++ does not support RFC 2671 EDNS protocol
extensions.
" DNS++ is responding per the RFC by sending the FORMERR back to the requestor.
I believe this is OK. Maybe we don’t understand the issue?
DNS++ is apparently what we're using on our end.
Is this behavior n
Rose, Scott wrote:
outlook.com isn’t signed, so I doubt it is a DNSSEC error (though they
look the same). BIND should see that it isn’t signed and just roll
with it. Could be that a server in the chain isn’t responding
(whatever serves the mail.protection.outlook.com zone).
We use Office365
BTW, just so y'all know, I'm poking people internally to get this looked at.
Thanks!
Aloha,
Michael.
--
Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been
Processed." | Got the Junk Mail Reporting Tool ?
-Original Message-
From: mailop [mailto:mailop-boun...@mailo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2016-04-28 at 11:41 -0700, Steve Atkins wrote:
> Looks like (some of) the Microsoft authoritative servers are confused
> by dnssec.
> ~ ? dig +dnssec @ns1-proddns.glbdns.o365filtering.com pitt-
> edu.mail.protection.outlook.com
confused by
> On Apr 28, 2016, at 11:18 AM, Rob Heilman wrote:
>
> We are seeing intermittent but frequent SERVFAIL errors for Microsoft owned
> hostnames in MX records. Specifically with *.mail.protection.outlook.com
> hostnames. In the BIND logs we see something like this:
>
> 28-Apr-2016 13:35:01.13
outlook.com isn’t signed, so I doubt it is a DNSSEC error (though they
look the same). BIND should see that it isn’t signed and just roll
with it. Could be that a server in the chain isn’t responding
(whatever serves the mail.protection.outlook.com zone).
We use Office365 too, and have heard
We are seeing intermittent but frequent SERVFAIL errors for Microsoft owned
hostnames in MX records. Specifically with *.mail.protection.outlook.com
hostnames. In the BIND logs we see something like this:
28-Apr-2016 13:35:01.139 query-errors: debug 1: client 10.10.10.96#48950
(pitt-edu.mail.
13 matches
Mail list logo
