NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/protocol/tcpip/domains/621

Text File | 1992-09-11 | 5.6 KB | 157 lines

Newsgroups: comp.protocols.tcp-ip.domains
Path: sparky!uunet!indetech!cirrus!dhesi
From: [e-mail] (Rahul Dhesi)
Subject: SUMMARY: How do you reset SOA serial no.?
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Cirrus Logic Inc.
References: <[e-mail]>
Date: Fri, 11 Sep 1992 20:15:52 GMT
Lines: 145

My original inquiry was:

>Is there a good way of resetting a high SOA serial number
>to a low value?

Most people essentially agreed that the only way is to perform the
following steps.  "Reinitialize the server" means you either kill and
restart it, or send it kill -HUP.

1.  Edit the primary zone file to show the new serial number,
    then reinitialize the server.

2.  For each secondary server,
    - either delete the relevant zone file, or manually edit the
      serial number in it to be the new serial number.
    - then reinitialize the server.

Obviously, this is tedious, and even error-prone if there are
unofficial secondaries that you don't know about.  In fact this is a
good reason to not to run a secondary server that is unknown to the
person running the primary.

Christophe Wolfhugel <[e-mail]> pointed
out that you may lose precious cached data if you kill and restart a
server, so it's always best to kill -HUP it:

  "My 30 days-running named now has 1000+ pages more than its initial
   size, I'd really not want to kill it.  And anyway much more known
   servers (such as top-level) would certainly not want to loose
   their caches."

However, Paul Vixie <[e-mail]> had this alternate suggestion:

  "Cold-start all the secondaries and wait for the cache ttls to
   expire."

Vikas Aggarwal <[e-mail]> said:

  "Or else you can always set the expire value to something tiny and that
   will expire the secondary zone info automatically."

Since the serial number is a 32-bit unsigned value, it occurred to me
to ask: what happens when the serial number in the primary goes up from
2^32-1 to 2^32?  I gave the primary SOA a serial number of 4294967295
(which is 2^32 - 1).  I set up a secondary server and it showed the
same serial number.  Then I incremented the primary serial number to
4294967296 (which is 2^32) and restarted the primary server.  A dump
showed that the primary interpreted this as 0, which makes sense if we
are counting modulo 2^32.  After I had waited several times the largest
timeout value in the SOA record, the secondary had still not picked up
the changed serial number.

So, a suggestion:  Don't begin with a serial number of 4294967295 or
anything close to it.

Interesting fact:  On my Sharp calculator, 2^32 is 4294967296.  On my
Casio calculator, 2^32 is 4294967295.

Thanks to the following people for email replies:
   Christophe Wolfhugel <[e-mail]>
   Paul Vixie <[e-mail]>
   Jack Bryans <[e-mail]>
   Vikas Aggarwal <[e-mail]>
   Samuel Lam <[e-mail]>

Since I received only a few replies, they are all appended below.

 Date:    Mon, 07 Sep 92 23:28:08 +0100
 From:    Christophe Wolfhugel <[e-mail]>

 > Is there a good way of resetting a high SOA serial number
 > to a low value?

 The solution that appears obvious to me, but not necessarilly
 efficient is to reduce your serial number, and then by mail
 request to all your secondaries (official, and this will really
 be a problem if you have unofficial secondaries, ie hosts you don't
 know are secondary for your domain) to manually edit their zone
 file and (perhaps not needed, it might get the result faster)
 kill -HUP /etc/named. I strongly disadvice to terminate named,
 this will result is a lossage of the precious cache on all the
 concerned servers.

 My 30 days-running named now has 1000+ pages more than its initial
 size, I'd really not want to kill it.  And anyway much more known
 servers (such as top-level) would certainly not want to loose
 their caches.

 Question: why do you need to go back? I use yymmddx with xx being an
 order # in the day, and I did not experience problems.

 > I will summarize any email received.

 Please do so. Interested in any more efficient solution.

 Chris

 Date:    Mon, 07 Sep 92 15:33:09 PDT
 From:    Paul Vixie <[e-mail]>

 coldstart all the secondaries and wait for the cache ttls to expire

 Date:    Mon, 07 Sep 92 18:50:00 PDT
 From:    Jack Bryans <[e-mail]>

 Why bother.  A good serial number for today is 199209070.  You can still
 change your mind 9 more times today, all the way up to 199209079.

 Jack

 Date:    Mon, 07 Sep 92 21:52:26 EDT
 From:    indetech!uunet!nisc.jvnc.net!aggarwal (Vikas Aggarwal)
 To:      indetech!cirrus!dhesi (Rahul Dhesi)

 Tell your secondaries to delete their secondary files from disk and then
 reset the serial number on the primary. Secondaries will also need to
 restart their nameservers.

 Or else you can always set theh expire value to something tiny and that
 will expire the secondary zone info automatically.

     -vikas
     [e-mail]

 Date:    Mon, 07 Sep 92 21:25:00 PDT
 From:    Samuel Lam <[e-mail]>

 In article <[e-mail]>, you wrote:
 >Is there a good way of resetting a high SOA serial number
 >to a low value?

  1) modify SOA value in primary name server's zone file
  2) restart primary name server
  3) modify SOA value in secondary name server's zone file
     to a lower value than in 1), or simply remove that file
  4) restart secondary name server
  5) repeat 3) and 4) for all secondary name servers of that
     zone

 ...Sam
 --
 <[e-mail]>
--
Rahul Dhesi <[e-mail]>
also: [e-mail]