The load balancers are not RFC compliant. While NOTIMP is a valid rcode it was not intended to be returned for normal queries.
If you look at RFC 1034 you should be getting a Name Error (NXDOMAIN) response. The server can't load records it doesn't implement so it it sees them it is supposed to reject the entire zone. If it has successfully loaded the zone then it returns NXDOMAIN because the name does not exist. If the name existed then it should be returning NOERROR zero answers because the type does not exist. This is even more so after the publishing of RFC 2929/5395, Domain Name System (DNS) IANA Considerations, RFC 3597, Handling of Unknown DNS Resource Record (RR) Types and RFC 6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA. RFC 2929 (obsoleted by RFC 5395) both define which qtypes are reserved for meta queries. RFC 3597 further reinforces NOERROR zero answers for non meta qtypes. RFC 6698 further show TLSA to be a normal (not meta) qtype. Now NOTIMP for meta queries makes sense as they require the server to do something other than return records of the requested type. This is further documented in draft-ietf-dnsop-no-response-issue which I hope will go for last call soon. The application can work around NOTIMP by requesting A records and if that returns a NOERROR response then asking for TLSA records. It requires a extra query if you get a NOERROR response by not for a NXDOMAIN response. One should also be asking why anyone is still using a non EDNS aware servers in 2016. There is really no excuse for requiring all your clients to send you two queries when the vast majority of recursive servers talk EDNS. Mark In message <1467393884.20170.25.ca...@ns.five-ten-sg.com>, Carl Byington writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Those dns servers answer queries for A records, but return notimpl for > TLSA queries. And they don't understand edns. > > time dig _25._tcp.spe-sony-com.mail.protection.outlook.com tlsa > @ns1-proddns.glbdns.o365filtering.com. +noedns > > That runs in .1 or .2 seconds here, talking directly to their server. > > > time dig _25._tcp.spe-sony-com.mail.protection.outlook.com tlsa > > That takes between .9 and 1.5 seconds, talking to the local bind > 9.10.4-P1 resolver. Looking at tcpdump output, the local resolver asks > all four servers for the answer twice, both times getting notimpl > results. > > mail.protection.outlook.com has two NS records, but (at least as seen > from here) both names have the same four IPv4 addresses. > > Is there something preventing an ip address merge to only send four > outgoing queries? > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iEYEAREKAAYFAld2p1MACgkQL6j7milTFsHVJACdEa614rKep2fumntitXyHNqGj > sawAn3I5b6ke9o7eJhgRcaSaQg1h3VLL > =WiA/ > -----END PGP SIGNATURE----- > > > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users