Re: provisioning software, was DNS RRTYPEs, the difficulty with

In message 
<201203090223(_dot_)q292NAZS005402(_at_)fs4113(_dot_)wdf(_dot_)sap(_dot_)corp>, 
Martin Rex writes
:
> 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?
No.  Unknown types were always NOERROR/NXDOMAIN.
 
> 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).
Which was controllable behaviour.
 
> > 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
RFC 1035 pre-dates the formalisation of MUST NOT/SHOULD NOT etc.

5.2. Use of master files to define zones

When a master file is used to load a zone, the operation should be
suppressed if any errors are encountered in the master file.  The
rationale for this is that a single error can have widespread
consequences.  For example, suppose that the RRs defining a delegation
have syntax errors; then the server will return authoritative name
errors for all names in the subzone (except in the case where the
subzone is also present on the server).

How anyone could rationalize serving a zone with missing data after
reading that I don't know.  I do know that doing so does cause
operational problems and fixing named to stop serving the zone on
load errors was was one of the ealier things I did.

> > 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?
Well the server should try the next server for the zone.  If all of them
return NOTIMP, SERVFAIL/NOTIMP.


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf