Mark Andrews wrote: > > The incredibly huge base that returned NOERROR to type 28 queries > when AAAA was defined. Almost all of the offending boxes were > designed after AAAA was defined. When AAAA was defined is marginally relevant. Since IPv6 was designed as a completely seperate universe, it was flying below the radar for most software apps developers for >10 years. I was first bothered about IPv6 in 2004. Had there been versions of BIND exhibiting such behaviour? I know that during its development, BIND sometimes adopted annoying unnecessary backwards-incompatible changes that caused folks to not upgrade. IIRC, suddenly refusing to load zone with hostnames containing underscores was one BIND change I remember from my early days as DNS admin, that caused me to ignore BIND software updates for several years (waiting for the "offending" hosts to die of age). > > Lots of them get responses to RFC 1035 types wrong. If you don't > implement the type then you can't load the zone if it contains the > type, partial zone loads are not permitted as per RFC 1035. "not permitted" would require a "must not", but I only see a "should not" here: http://tools.ietf.org/html/rfc1035#section-5.2 > > If you have loaded the zone then the type doesn't exist, so it doesn't > matter that you don't implement it, you therefore can't match the > type as per RFC 1034 so the answer is NOERROR or NXDOMAIN depending > apon whether the name exists in the zone or not. >From these discussions, your explanations and my latest reading of 1034/1035 I believe I have a hunch what might have happened (to our internal DNS) when my w2k3 IPv6 stack freaked out... It might be related to the particular fashion in which I originally set up the private DNS universe as an intern in 1993. And while I joined development in 1995 and the tools I had written to to generate the DNS zone files got replaced ~1999 with a commercial solution, the structure of the private DNS universe seems to be still the way I originally set it up. Thank you for your patience and elaborate responses. > > > So if the behaviour (how to exactly respond to queries for unknown > > QTYPEs) is neither explicitly specified, nor likely have been part of > > the usual/common interop tests performed by the vendor, > > what you're left with might be "ureflected&untested guessing" > > on part of the implementors to fill those gaps. > > > > Bottom line, the receiver must be VERY conservative with assumptions > > about what exactly can be infered from error responses for situations > > that are fairly vague in the spec and potentially untested in the > > installed base. That is called "robustness principle". > > Which is why there are lots of SERVFAILs as you can't infer anything > from NOTIMP. Servfail is supposed to be a transient error. What should a _new_ recursive non-authoritative server send as response back to the stub resolver when it encounters a NOTIMP response from the authoritative server for an AAAA query? -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf