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


To: Gunnar Lindberg <lindberg@cdg.chalmers.se>
Cc: dnsop@cafax.se
From: Peter Koch <pk@TechFak.Uni-Bielefeld.DE>
Date: Mon, 28 Jun 1999 17:15:56 +0200
In-reply-to: Your message of "Mon, 28 Jun 1999 15:11:57 +0200." <199906281311.PAA14579@wilfer1.cdg.chalmers.se>
Sender: owner-dnsop@cafax.se
Subject: Re: Primary also being secondary


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

We've seen this a couple of times even with 2nd level domains. One
recommendation I'd derive from this is that the primary (ar any master)
for a zone should not run as a secondary for a delegated zone. However,
this is in conflict with advice from years ago, when it was usually a good
idea to also serve child zones. Also it is in conflict with RFC2317 practice,
where for efficiency reasons you'd run secondary service for the child
zones on the/all parent zone's auth servers.

So, in your case, if ns2.chalmers.se becomes a (stealth) slave for
hemmet.s-hem.chalmers.se - probably a good idea anyway - the problem you
noticed should be avoided.

Anyway, it's a feature, not a bug, due to zone boundary enforcement.

-Peter

Home | Date list | Subject list