-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, 2016-04-28 at 20:01 +0000, 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 OK. Maybe we don't understand the > issue?
> DNS++ is apparently what we're using on our end. > Is this behavior not according to the RFC? ;; ANSWER SECTION: pitt-edu.mail.protection.outlook.com. 10 IN A 207.46.163.247 pitt-edu.mail.protection.outlook.com. 10 IN A 207.46.163.215 pitt-edu.mail.protection.outlook.com. 10 IN A 207.46.163.138 ;; ANSWER SECTION: ns1-proddns.glbdns.o365filtering.com. 30 IN A 65.55.169.42 ns1-proddns.glbdns.o365filtering.com. 30 IN A 207.46.100.42 ns1-proddns.glbdns.o365filtering.com. 30 IN A 207.46.163.143 Many dns servers cache the "edns aware" state of authoritative server, but that cache entry might expire with the 30 second ttl above. And the pitt-edu A record would also have expired then. So on the next lookup, the recursive resolver might try talking edns, and need to repeat the query without edns. Combined with the short TTL, that might be enough to cause operational problems. However, it looks like all your customers *.mail.protection.outlook.com are setup the same way, with the same short TTLs. So if this is really a DNS compatibility issue (possibly between DNS++ and Bind), I would expect a LOT more failures. Of the folks having problems delivering to (for example) pitt-edu, it would be interesting to know the exact version of the recursive dns resolver used by their outbound mail server. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlcidXoACgkQL6j7milTFsH+MgCfS1h1zcxga6PM4/mDbhStKvy0 MpwAmgMmWYr2vxf3kKDZQ9ZqHFWoGgIb =Ibgl -----END PGP SIGNATURE----- _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
