How to reset the serial number?

[Carlos Ribas]

Hello all,

I accidentally changed the serial number to one bigger than 32 bits and now I'm trying to reset the serial number. Following the manual of Bind9 I tried to add 2147483647 (2ˆ31-1) to the number and reload the server, but my slave is not updating to the new zone serial number.

Here is what I'm doing:

# dig @10.0.1.24 saturno.br SOA

...

;; ANSWER SECTION:

example.br.         86400   IN      SOA     ns1.example.br. hostmaster.example.br. 2694341036 7200 3600 604800 86400

...

2694341036 + 2147483647 = 4841824683

I put this number as serial, but did not work. I also saw that when the number is over than 4,294,967,295 I have to substract 4,294,967,296. So 4841824683 - 4294967296 = 546857387.  It did not work too. Does anybody knows what I'm doing wrong? I'm using Bind 9.7.3.

Best regards, 

---------------------------------

Carlos Eduardo Ribas

[Chuck Swiger]

On Mar 26, 2012, at 11:30 AM, Carlos Ribas wrote:
> I accidentally changed the serial number to one bigger than 32 bits and now I'm trying to reset the serial number. Following the manual of Bind9 I tried to add 2147483647 (2ˆ31-1) to the number and reload the server, but my slave is not updating to the new zone serial number.

Shut down the slave server(s).
Use scp or rsync to copy over the zone file, one with a corrected serial #.
Restart the slave server(s).

[ Is BIND putting SOA serial #'s into a signed int? ]

Regards,
--
-Chuck

[Carlos Ribas]

Hello,

     I was doing some tests with DNSSEC in that zone. I used one day of signature lifetime, now it is expired. All this happen when I was trying to regenerate the signature.

     In fact, the problem is that my master did not see the serial change. If I run dig using the master I still got the old serial number,even after restart bind. Should I have to disable DNSSEC?

   

Regards,

---------------------------------

Carlos Eduardo Ribas

2012/3/26 Chuck Swiger <csw...@mac.com>

[Mark Pettit]

Did it reject the zone when you used a too-large serial number? If so then that explains why digging against the master doesn't show an updated serial.

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

[Chris Buxton]

On Mar 26, 2012, at 11:30 AM, Carlos Ribas wrote:

Hello all,

I accidentally changed the serial number to one bigger than 32 bits and now I'm trying to reset the serial number. Following the manual of Bind9 I tried to add 2147483647 (2ˆ31-1) to the number and reload the server, but my slave is not updating to the new zone serial number.

Here is what I'm doing:

# dig @10.0.1.24 saturno.br SOA

...

;; ANSWER SECTION:

example.br.         86400   IN      SOA     ns1.example.br. hostmaster.example.br. 2694341036 7200 3600 604800 86400

...

2694341036 + 2147483647 = 4841824683

I put this number as serial, but did not work. I also saw that when the number is over than 4,294,967,295 I have to substract 4,294,967,296. So 4841824683 - 4294967296 = 546857387.  It did not work too. Does anybody knows what I'm doing wrong? I'm using Bind 9.7.3.

You cannot reload a dynamic zone. Could that be the problem?

A serial number higher than 2^32 will not load. Instead of adding 2^31 - 1, subtract 2^31 + 1. Or try adding 2^30 (or subtracting 3 * 2^30).

Make sure to reload the zone after each change, or if your zone is dynamic, use a dynamic update that adds the SOA record again and sets the new serial number.

Regards,

Chris Buxton

BlueCat Networks

[WBr...@e1b.org]

--

William Brown
Messaging and Core Hosted Application Technical Teams
Technology Services, WNYRIC, Erie 1 BOCES
(716) 821-7285

Chuck Swiger wrote on 03/26/2012 02:35:24 PM:

> Shut down the slave server(s).
> Use scp or rsync to copy over the zone file, one with a corrected serial
#.
> Restart the slave server(s).

If I have access to the slave, I just deleted slave zone and issue "rndc
reload". It will transfer the missing zone.

Several advantages:

No need to shut down slave.
Less typing/less chance to mis-type something.






Confidentiality Notice:
This electronic message and any attachments may contain confidential or
privileged information, and is intended only for the individual or entity
identified above as the addressee. If you are not the addressee (or the
employee or agent responsible to deliver it to the addressee), or if this
message has been addressed to you in error, you are hereby notified that
you may not copy, forward, disclose or use any part of this message or any
attachments. Please notify the sender immediately by return e-mail or
telephone and delete this message from your system.

[Chris Thompson]

On Mar 27 2012, WBr...@e1b.org wrote:

>Chuck Swiger wrote on 03/26/2012 02:35:24 PM:
>
>> Shut down the slave server(s).
>> Use scp or rsync to copy over the zone file, one with a corrected serial
>#.
>> Restart the slave server(s).
>
>If I have access to the slave, I just deleted slave zone and issue "rndc
>reload". It will transfer the missing zone.
>
>Several advantages:
>
>No need to shut down slave.
>Less typing/less chance to mis-type something.

If you have control over all the slaves, then using "rnds retransfer [zone]"
on them for each zone with serial number trouble is easier still.

If you don't have such control, you are more or less stuck with using
serial number wrapround in the style of RFC 1982. Even if you do that
right, you may find DNS server implementations on the slaves that don't.
As we discovered in September 2009, when we did the last stage of wrapping
our serials round from YYYYMMDDNN style to seconds-since-1970, the
stealth-slaving Windows DNS servers of that time (even the 2008
ilk) just could not cope, and went into a tizzy continuously trying
to fetch the zones and then rejecting them for their "smaller" serials.

--
Chris Thompson
Email: ce...@cam.ac.uk

[Carlos Ribas]

Hello all,

    I just want to say thank you for all the responses. Now it works!  I removed the slave zone, but I also had to change the master configuration to use db.example.br rather than db.example.br.signed, then re-sign the zone and then back to use db.example.br.signed.

Best regards,

---------------------------------

Carlos Eduardo Ribas

Analista de Suporte

Rede ANSP / Projeto NARA

2012/3/27 Chris Thompson <ce...@cam.ac.uk>

[Chris Thompson]

On Mar 27 2012, WBr...@e1b.org wrote:

>Chuck Swiger wrote on 03/26/2012 02:35:24 PM:
>
>> Shut down the slave server(s).
>> Use scp or rsync to copy over the zone file, one with a corrected serial
>#.
>> Restart the slave server(s).
>
>If I have access to the slave, I just deleted slave zone and issue "rndc
>reload". It will transfer the missing zone.

Assuming you mean "delete the slave zone *file*", this doesn't actually
work (unless you restart BIND as well). Tested with 9.8.2rc2, but it
seemed innately unlikely. Why would BIND on the slave ever look at the
file contents except on startup?

Or did you mean something like (1) remove the zone from the slave's
configuration and "rndc reconfig" (reload is overkill) (2) delete the
slave zone file (3) add the zone to the slave's configuration again
and "rndc reconfig" ?

That would work, but "rndc retransfer [zone]" is a lot simpler!