Subject: transfering vs. loading a zone

From: Edward Lewis <[email-masked]>
Date: Tue, 12 Aug 2008 08:25:46 -0700

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Aug 2008 09:05:23 +1000

> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 13 Aug 2008 19:46:21 +0900

Edward Lewis wrote:

> 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.

The issue is vaguely recognized but not addressed in RFC1034 and a
solution was given 15 years ago or so in initial versions of IXFR
draft.

That is, glue As in zone information must be tagged by refferal point,
though neither zone file format nor AXFR allows to do so, which is why
I tried to fix it with IXFR.

The result was that no one else even tried to understand the issue,
which now resulted in Kaminsky's variation of ID attack with glue A.

> (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, 

Hugh? If a name server tries to receive a new version of a zone and fails,
it should continue to use an older version of the zone until it expires.

						Masataka Ohta

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 13 Aug 2008 13:22:17 +0200

Hi,

Agree with Mark, that the server that loads the zone from text file (or
whatever the first source) can refuse to send the zone through the
ecosystem.  It can admit the zone, but then keep it as written by the owner.

How to distinguish load from transfer?  After a reboot, a transferred
zone is loaded from disk.  And master or slave configuration may not be
a clue either in complicated mesh setups.

Masataka Ohta wrote:
| Edward Lewis wrote:
|> 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,
|
| Hugh? If a name server tries to receive a new version of a zone and fails,
| it should continue to use an older version of the zone until it expires.

Yes.

Best regards,
~   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Wed, 13 Aug 2008 09:20:17 -0700

Well, this is kind of what I was wondering about.

Can a name server receive a zone via AXFR, examine it and decide it's 
rotten but then turn around and send it as an AXFR server?  Would the 
server then send out NOTIFY messages as if it loaded the zone?  (Mind 
you, this is the AXFR document, but I want to know anyway.)  I 
suppose that having a rotten zone in the server would also complicate 
IXFR, huh?

Perhaps a name server should toss any rotten zones.  But, but, but...

But what if a subset of authoritative servers decide to load the zone 
with serial number 9.  The admin though sees that serial number 8 is 
the last everywhere, looks at a log of one of the rejecting machines, 
edits the zone and tries to load it as 9 again.  Now the rejecters 
will pick this up and serve it as 9, but the ones that loaded the 
previous 9 will not pick it up (as the serial number didn't 
increment).

Should a server remember the last SOA serial it saw, regardless of 
the successful loading of the one.  I.e., separation of the zone 
transfer process and loading process.

At 13:22 +0200 8/13/08, W.C.A. Wijngaards wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi,
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.9 (GNU/Linux)
>Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
>iEYEARECAAYFAkiiw+kACgkQkDLqNwOhpPiIBACfbyT2pUN4QajkDA/2bWyyH1BO
>Ny0Anj30RayKGWLkL6UAEeP0l/4HHQij
>=1GgV
>-----END PGP SIGNATURE-----
>
>--

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Aug 2008 09:14:52 +1000

> suppose that having a rotten zone in the server would also complicate 

	Ed, if the zone is deemed rotten then the SOA queries will
	not be answered and the downstream slave will not attempt
	to AXFR from the upstream slave.

	IXFR should conceptually be the same.  The rotten SOA should
	not be visible to the IXFR process.

	All or nothing.  Anything else is a problem waiting to
	happen.
 
> previous 9 will not pick it up (as the serial number didn't 

	The administrator failed to manage the serial number properly,
	the results are outside the protocol because the administator
	failed to follow the protocol.

> transfer process and loading process.

	There is no need for the slave to remember.  If the
	administrator follows the protocol it is not required.
 
	Mark

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 14 Aug 2008 14:08:05 +0900

> ecosystem.  It can admit the zone, but then keep it as written by the 

With AXFR/IXFR, that is an issue only with the primary nameservers.
Though RFC1034 does not disallow zone transfer with text files transferred
by ftp or e-mail, nameservers receiving text zone should be considered
the primary with regrad to AXFR/IXFR discussion.

The problem here, however, is that zone contents recognized valid
by the primary nameserver may be recognized invalid by secondary
nameservers.

Such inconsistencies are often caused by violent application of the
concept of "bailiwick" to glue As.

> | it should continue to use an older version of the zone until it expires.

And, we hope zone administrators take care of inconsistencies between
nameservers before or, in practice hopefully, immediately after the
zone expiration.

							Masataka Ohta