On Sunday, December 27, 2015 10:31:52 PM Paul Wouters wrote: > The section in question of the draft under discussion talks about the > specific case where a load balancer is returning REFUSED because it > did not implement NS queries, and that such behaviour is a violation > of the RFC.
strictly speaking, rfc's are guidelines, not to be violated or not, but only sometimes to be followed. an rfc guides sender behaviour and receiver interpretation. sometimes the receivers don't follow the interpretation guidelines, and so it is with REFUSED. REFUSED is considered by initiators to pertain to the specific <qname,qtype,qclass,clientIP,serverIP> and are not therefore dispositive toward the originating application. "not dispositive" means the iteration will continue, trying other serverIP's if any are known, and eventually returning SERVFAIL to the originating application if all servers known for this closest encloser refuse or fail or time out. in that sense REFUSED is underspecified since these semantics are the same as if the server returned SERVFAIL, except the time domain. that is, SERVFAIL pertains to the <qname,qtype,qclass,clientIP,serverIP,$now> and as such, a SERVFAIL response should only be cached for a limited period. REFUSED is "forever". > Not implementing NS queries on an authoritative nameserver > results in a DNS implementation that indeed violates the RFC. The question > was, which part of which RFC is the best reference to point to. "violates" is the wrong rubric. the signal is ambiguous as specified and even more ambiguous as widely implemented. so, first mover advantage was abused, and you fight now as and where and when you are, not as and where and when you might wish to have been. in today's world, the safest interpretation is not "what the framers intended" but "how the world actually works." and that means treating REFUSED as a synonym for SERVFAIL but with longer cache retention. do not, therefore, treat the REFUSED coming out of these load balancers as dispositive, and regard it as being specific to <qname, qtype, qclass, clientIP, serverIP> such that varying any member of that tuple could be expected to produce a non-REFUSED answer. "DNS: You will never find a more wretched hive of slop and ambiguity. We must be cautious." (Obi-Wan Mockapetris) see also: http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/ -- P Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
