transfering vs. loading a zone

Edward Lewis <Ed.Lewis@neustar.biz> Tue, 12 August 2008 15:32 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BA1E3A6B18; Tue, 12 Aug 2008 08:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.105
X-Spam-Level: *
X-Spam-Status: No, score=1.105 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fvMBCKBh4ia; Tue, 12 Aug 2008 08:31:59 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 748C53A6A46; Tue, 12 Aug 2008 08:31:59 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KSvlN-000CTG-L2 for namedroppers-data@psg.com; Tue, 12 Aug 2008 15:26:21 +0000
Received: from [66.92.146.20] (helo=stora.ogud.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <Ed.Lewis@neustar.biz>) id 1KSvlJ-000CSb-I4 for namedroppers@ops.ietf.org; Tue, 12 Aug 2008 15:26:19 +0000
Received: from [0.0.0.0] (ns.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.2/8.14.2) with ESMTP id m7CFQCBS085832; Tue, 12 Aug 2008 11:26:13 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: <a06240800c4c752b74d81@[192.168.50.50]>
Date: Tue, 12 Aug 2008 08:25:46 -0700
To: namedroppers@ops.ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
Subject: transfering vs. loading a zone
Cc: ed.lewis@neustar.biz
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.64 on 10.20.30.4
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

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.

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                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

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