[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: dnsop@cafax.se
From: Gunnar Lindberg <lindberg@cdg.chalmers.se>
Date: Mon, 28 Jun 1999 15:11:57 +0200 (MET DST)
Sender: owner-dnsop@cafax.se
Subject: Primary also being secondary

I'm not sure if this belongs here, but I am sure you'll redirect :-).

This is real life, although I've modified some names to make it a
little less confusing.  SW is bind-8.1.2.

: chalmers.se.              IN NS ns1.chalmers.se.                 pri
:                           IN NS ns2.chalmers.se.                 sec
:
: hemmet.s-hem.chalmers.se. IN NS glutus.hemmet.s-hem.chalmers.se. pri
:                           IN NS ns1.chalmers.se.                 sec

So, this is a delegated subdomain, where the upper domain's primary is
also secondary for the delegated domain. Straight forward. Between
them they share NS(hemmet.s-hem.chalmers.se) info, and this is where
my report/question comes in.

Now, the people at hemmet.s-hem.chalmers.se screwed up their NS info:

: hemmet.s-hem.chalmers.se.
:     IN NS glutus.hemmet.s-hem.chalmers.se.hemmet.s-hem.chalmers.se.
:     IN NS ns1.chalmers.se.hemmet.s-hem.chalmers.se.

We've all done this at least once...

ns1.chalmers.se noticed the higher version number and fetched the zone,
including the erronous NS(hemmet.s-hem.chalmers.se). This did *not*
change the SOA version for zone chalmers.se.

Later on, there were other changes made to zone chalmers.se and the
SOA version was changed. ns2.chalmers.se noticed and fetched the data;
and now got the erronous NS(hemmet.s-hem.chalmers.se) - the erronous
one that ns1.chalmers.se fetched some time ago and obviously installed
in zone chalmers.se.

The people at hemmet.s-hem.chalmers.se soon found the error, fixed it
and incremented their SOA version. ns1.chalmers.se fetched again, with
correct info this time. However, SOA(chalmers.se) was not updated, so
ns2.chalmers.se did NOT fetch any new data; instead it was stuck with
the erronous NS(hemmet.s-hem.chalmers.se) info.

My conclusion is that, at least in bind-8.1.2, the delegated zone's
version of the shared NS-info gets precedence over the delegating
zone's version (the config file). Although I can see cases where this
may be good and useful I'm not sure this is generally so - the case
above is one counter example. I've not found anything in the RFCs
that tell which one is considered "correct" or even "better".

My 1c is that this is wrong and that the data sent to a secondary,
i.e. AXFR, should be the original data from the config file(s), and
not be a "copy of a copy".

	Gunnar Lindberg

Home | Date list | Subject list