Re: transfering vs. loading a zone

[Mark Andrews <[e-mail]>]

> During the DNSEXT meeting at IETF 72 one topic came up regarding the 
> "AXFR clarify" draft.  The topic is "the difference between a zone 
> transfer and zone load operation."
> 
> The issue begins with the question "what is in a zone?"  That 
> question is what derailed the document a half decade ago.  The 
> question is not that easy to answer.
> 
> There is a statement in the original RFCs about what is in a zone, 
> and the statement is pretty clear.  However, the advent of dynamic 
> update (with the ability to add a cut point) created a class of 
> records now called "obscured records" and this class gained 
> additional importance with the advent of DNAME.
> 
> Obscured records are not the first records which can be classified as 
> "wrong" but are legitimately tied to a zone, earlier examples of this 
> are "bad" glue records, i.e., glue record with different address(es) 
> than the authoritative data they represent.
> 
> Complicating matters, once we recognize that bad glue and obscured 
> records are legitimate parts of a zone, through the fact that the 
> records were added by the administrator, what about "typos?"  Of 
> course, a typo of transposing bits in a AAAA record is something the 
> DNS itself won't know about, but a typo like:
> 
> 
>      $ORIGIN example.
>      @              SOA        ...
>      <...>
>      ns1.nic        AAAA       3ffe::1
>      ns1.nic.       A          127.0.0.1
> 
> The AAAA shown is for ns1.nic.example. and the A is ns1.nic.  Is the 
> address record for ns1.nic. in the zone even though this might make a 
> name server refuse to load and serve the zone?
> 
> This raises the issue - what is in a zone?  I see three possible 
> (extreme) answers:
> 
> 1.) Exactly what the administrator places into the zone.
> 2.) The subset of #1 excluding typos.
> 3.) The best data that should be there.

	What the administrator places into the zone.

	You can refuse to load it but you can't split it.

	You get everything or you get nothing.  BIND operated for
	too long with best effort loading.  This, in the end, caused
	lots of problems operational problems.

	Mark

> If #1 is done perfectly right, then all three are the same.
> 
> Why not #3?  If the nameservers start editing the zone, 
> troubleshooting becomes troublesome.  From personal experience, I 
> knew of an erstwhile zone that had many, many lame delegations.  Most 
> servers for the zone also served all of the children, meaning it was 
> hard to capture the lame delegations.  But one server exposed the 
> lame delegations and that was causing operational problems. 
> Fortunately, as an operator of a slave for the zone I got a copy of 
> the zone via AXFR and was able to debug and alert the admin.
> 
> It pays to let errors become exposed.  Makes debugging easier.  Of 
> course, covering over bumps is good - if all the covering is done the 
> same way.  In an interoperable world though, nothing is always "done 
> the same way."
> 
> A comment was made at the mic in the meeting that we should think of 
> a zone "for a particular serial number."  And the zone for a 
> particular serial number is "set in stone" when the zone is 
> successfully loaded at the master server.  Not by the administrator, 
> and zones that fail to load never get to be that version.  This is 
> because only after the master loads the zone will either there be 
> NOTIFYs sent or the slaves will poll and see the incremented serial 
> number.  If any name server, especially the master, "edits" the zone 
> (that is loads a subset of what is given), the name server has taken 
> an editing pen to the administrator's work.
> 
> Why not #2?  It isn't clear if typo errors are objectively defined. 
> I haven't thought all the way through but my hunch is that trying to 
> algorithmically decide if a mistake was made is nearly impossible.
> 
> So that leaves #1, "warts and all."  In my opinion, it's the right 
> approach, but then again this is an opinion to be expressed by the 
> working group.
> 
> But let's assume for now a zone is defined as #1, and press on to the 
> issue of loading a zone (from an AXFR - as AXFR is the topic at hand).
> 
> If an AXFR will deliver to a name server the contents of a zone 
> according to the criteria of #1 above, the name server ought to do 
> some sanity checking on it.  I.e., the zone is not #3, it is not 
> ready for immediate consumption.
> 
> A name server could parse the zone and decide not to serve it due to 
> errors.  A name server has to recognize the "obscured" (or "occluded" 
> I forget the term we want to use) records.
> 
> Here's an open question.  If a name server gets a zone via AXFR 
> (presumably the name server had a reason to ask for it) and decides 
> the zone is bad and returns SERVFAIL to all queries for data in the 
> zone, will the name server still store the zone, send NOTIFYs and 
> serve it as AXFR/IXFR?
> 
> Is it possible for a name server to hold a cache of zones that failed 
> to load?  I mean, one failed load per zone configured, not a running 
> history.
> 
> Is the decision to transfer a zone different from the decision to 
> load and serve a zone?
> 
> This is meant to start an open discussion...so maybe this isn't all 
> wrapped up, but I'm seeking comments.  Eventually this will be in a 
> section about the differences between AXFR and loading.
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                [phone]
> NeuStar
> 
> Never confuse activity with progress.  Activity pays more.
> 
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>