> On Dec 27, 2015, at 11:40 PM, John Levine <jo...@taugh.com> wrote: > >>> NEW >>> For instance, some authoritative name servers embedded in load >>> balancers reply properly to A queries but send REFUSED to NS queries. >>> This behaviour violates the DNS protocol (see Section ??? of [RFC??], >>> and improvements to the DNS are impeded if we accept such behaviour >>> as normal. >>> END >> >> Does anyone has an idea of the reference to use to replace the "???" > > Given that it doesn't seem to be a protocol violation, I'd suggest this: > > For instance, some authoritative name servers embedded in load > balancers reply properly to A queries but send REFUSED to NS queries. > This behavior causes a variety of problems, such as invalid negative > answers, that are so severe that it is unreasonable to expect clients > to interoperate with them reliably and so there is no point in trying to > work around them. > > R's, > John >
For the longest time in the DNS world there have been different standards of conduct for the different functional elements. Publishers can get a away with gross misconduct, while resolvers are expected to find the answer at all cost. I agree with your statement as the first step in calling out authorities that if they are “not nice” there is no need to try to return the answer. In 1999 or 2000 we started seeing LoadBalancers that returned NXDOMAIN for any query other than A for a name. At the time the bind-9 team argued about what to do, I still think that the behavior selected was the wrong one i.e. ignore NXDOMAN for AAAA query and ask for A. IMHO a resolver that does not like the answers it is getting from a authority has full right to stop trying to find the answer and return SERVFAIL. I understand that operators of said resolver will get complaints that important cat pictures are unavailable,…… I think for all practical purposes this situation is a great example of the “Prisoners Dilemma” as there is no way to educate the people writing the crap software as they are insulated by multiple layers of protection. Olafur _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
