|
|
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
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. 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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf