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

In message 
<201203090422(_dot_)q294MRA2012090(_at_)fs4113(_dot_)wdf(_dot_)sap(_dot_)corp>, 
Martin Rex writes
:
> Mark Andrews wrote:
> > > "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.
> A zone file loaded by a DNS server is not necessarily an authoritative
> zone file! And for a non-authoritative zone, a partial zone might
> be considerably better than no data at all.
You were still authoritative for it, just not a official server.
The act of loading from a zone file makes you authoritative.  Your
content may have been slightly older if it had been updated on the
master but it was still complete for the version of the zone you
had.  You were also within the expected tolerences for changes to
be made visible to everyone.  Those are specified in the SOA record.

> In 1993 we had a worldwide private network with modate-size links
> to remote locations and the links would occasionally fail for a
> few hours.  So I setup *all* DNS servers (primary&secondaries,
> delegated primaries&secondaries and caching-only) to obtain all
> zones via XFER in a tree structure.
>
>
> -Martin
-- 
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