The whole process of DNS updates is fully automated.
Certainly, under _normal_ circumstances the problem
should not accure at all and I know all the implications
that would cause. But I know _definitly_ that I want to
use the primary's information ;-)
Deleting the db file would of course be the usual way,
but as said, the whole process is automated, and I
really wouldn't like the hassle of writing an
interface to delete a db file on the dns machine
triggerd from elsewhere. We are talking several
thousand zone files here. Imagine a bug ...
We are running BIND 9.x. Maybe with 9 there's a way?
Cheers, Marcel
On 14 Aug 2001, at 10:36, Nate Duehr wrote:
> Assuming you're talking about BIND 8.2.x - no.
>
> ndc reload zonename
>
> will refuse to load a zone if the serial matches what
> BIND already knows about.
>
> Deleteing the zonefile from the drive (in the case of a
> slave, since that appears to be what you're describing) and
> restarting BIND is going to be the only way to clear up
> having the wrong zone.
>
> Why not just have the zone head roll the serial number
> properly when changes are made? You're going to cause other
> (hopefully minor) problems by forcing the reload of a zone
> with a serial number that matches a different previous zone.
> [Imagine if your SOA timeouts had changed drastically, for
> example... machines caching your old SOA record and serial
> number aren't going to have a need to query for the new one
> because you are still reporting the same serial number...
> etc.]
>
> On Tue, Aug 14, 2001 at 12:05:04PM +0200, Marcel Hicking
> wrote: > Is it possible to force a secondary/slave NS > to
> do a zone transfer for a particualr zone > _regardless_ of
> the local stored serial? > > I certainly know that this is
> not recommended > for daily use, but I occasionly have a
> situation > where this is required. > > Any ideas beyond
> manually deleting the db-file? > > tia, Marcel > > -- >
> __ > .´ `. > : :' ! Enjoy > `. `´ Debian/GNU Linux >
> `- > > > -- > To UNSUBSCRIBE, email to
> [EMAIL PROTECTED] > with a subject of
> "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> >
>
> --
> Nate Duehr <[EMAIL PROTECTED]>
>
> GPG Key fingerprint = DCAF 2B9D CC9B 96FA 7A6D AAF4 2D61
> 77C5 7ECE C1D2 Public Key available upon request, or at
> wwwkeys.pgp.net and others.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
