Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Serial numbers for inline signing

256 views
Skip to first unread message

Thomas Schulz

unread,
Dec 18, 2013, 10:17:15 AM12/18/13
to bind-...@lists.isc.org
I have a question about the serial number as modified by inline signing.
I have a static zone, adi.com, that I am setting up for dnssec. I added
inline-signing yes;
key-directory "dnssec";
auto-dnssec maintain;
to my named.conf file after generating the keys and then did a rndc restart.
After that I did a
rndc signing -nsec3param 1 0 10 aef7db3a adi.com
to switch to nsec3. Checking the resulting serial number, I find that it is
2013120423. The serial number in the static zone file is 2013120400.
Why did it bump it up to 23? I expected something like 02.

Tom Schulz
Applied Dynamics Intl.
sch...@adi.com

Alan Clegg

unread,
Dec 18, 2013, 10:27:17 AM12/18/13
to Thomas Schulz, bind-users
I can’t tell you why you got an exact number, but the best rule about this is “don’t worry about the signed serial number”, as BIND will take care of it for you. As long as you continue to increment the static zone serial number as you always have, the serial in the signed zone will be maintained correctly.

There are a number of things that are happening all the time with the signed zone that you are not aware of, for example, re-signing as signatures reach expiration, re-signing when you change from NSEC to NSEC3, etc.

All of these will keep the signed serial number ‘bumping up’ even when your zone isn’t changing.

AlanC
--
Alan Clegg | +1-919-355-8851 | al...@clegg.com

signature.asc

Tony Finch

unread,
Dec 18, 2013, 10:59:49 AM12/18/13
to Thomas Schulz, bind-...@lists.isc.org
Thomas Schulz <sch...@adi.com> wrote:

> Checking the resulting serial number, I find that it is 2013120423. The
> serial number in the static zone file is 2013120400. Why did it bump it
> up to 23? I expected something like 02.

Have a look at the sig-signing-signatures option which says (by default)
that named should create at most 10 RRSIGs per signing quantum, and each
quantum implies a SOA serial update. That should lead you to expect a
difference of more than 2 after what you did.

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

Chris Thompson

unread,
Dec 18, 2013, 11:02:06 AM12/18/13
to Thomas Schulz, Bind Users Mailing List
On Dec 18 2013, Alan Clegg wrote:

>
>On Dec 18, 2013, at 10:17 AM, Thomas Schulz <sch...@adi.com> wrote:
>
>> I have a question about the serial number as modified by inline signing.
>> I have a static zone, adi.com, that I am setting up for dnssec. I added
>> inline-signing yes;
>> key-directory "dnssec";
>> auto-dnssec maintain;
>> to my named.conf file after generating the keys and then did a rndc restart.
>> After that I did a
>> rndc signing -nsec3param 1 0 10 aef7db3a adi.com
>> to switch to nsec3. Checking the resulting serial number, I find that it is
>> 2013120423. The serial number in the static zone file is 2013120400.
>> Why did it bump it up to 23? I expected something like 02.
>
>I can't tell you why you got an exact number, but the best rule about this
>is "don't worry about the signed serial number", as BIND will take care of
>it for you. As long as you continue to increment the static zone serial
>number as you always have, the serial in the signed zone will be maintained
>correctly.
>
>There are a number of things that are happening all the time with the signed
>zone that you are not aware of, for example, re-signing as signatures reach
>expiration, re-signing when you change from NSEC to NSEC3, etc.
>
>All of these will keep the signed serial number 'bumping up' even when your
>zone isn't changing.

You can look at the sequence of changes to the signed zone by using

dig ixfr=2013120400 adi.com @[yourauthserver]

or by applying named-journalprint to the .signed.jnl file, unless the
journal has been pruned as a result of exceeding the max-journal-size
setting. But this won't tell you *when* each increment happened.

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

Alan Clegg

unread,
Dec 18, 2013, 1:59:46 PM12/18/13
to Antonio Querubin, bind-users

On Dec 18, 2013, at 11:05 AM, Antonio Querubin <to...@lavanauts.org> wrote:

> Is there a way to keep the serial numbers synced between the primary and slaves for auto-maintained zones? Every once in a while the primary and slaves somehow get out of sync and the logs start generating error messages about the mis-match. The mis-match also gets noticed by various DNS sanity checkers.

This is an automatic feature of DNS. I’d concern myself more with “what is happening to make my serial numbers differ between my servers”.

Did it work before DNSSEC inline signing? If you “dig +nssearch zonename” what are your results?
signature.asc

Thomas Schulz

unread,
Dec 18, 2013, 3:36:51 PM12/18/13
to bind-...@lists.isc.org
> You can look at the sequence of changes to the signed zone by using
>
> dig ixfr=2013120400 adi.com @[yourauthserver]
>
> or by applying named-journalprint to the .signed.jnl file, unless the
> journal has been pruned as a result of exceeding the max-journal-size
> setting. But this won't tell you *when* each increment happened.
>
> --
> Chris Thompson

Thanks for the information. The when was all within about 1 second.
I was fast enough with the switch to nsec3 that the slaves only had
to do one transfer. I can see from the dig output that named was really
busy!

Antonio Querubin

unread,
Dec 19, 2013, 1:06:22 AM12/19/13
to Alan Clegg, bind-users
On Wed, 18 Dec 2013, Alan Clegg wrote:

> On Dec 18, 2013, at 11:05 AM, Antonio Querubin <to...@lavanauts.org> wrote:
>
>> Is there a way to keep the serial numbers synced between the primary
>> and slaves for auto-maintained zones? Every once in a while the
>> primary and slaves somehow get out of sync and the logs start
>> generating error messages about the mis-match. The mis-match also gets
>> noticed by various DNS sanity checkers.
>
> This is an automatic feature of DNS. I�d concern myself more with �what
> is happening to make my serial numbers differ between my servers�.
>
> Did it work before DNSSEC inline signing?

Yep. The slaves sync up with the master after a zone refresh and stay
that way.

> If you �dig +nssearch zonename� what are your results?

Currently the serial numbers are all in sync. What I don't understand is
what condition cause them to get out of sync (ie. the slave's serial
number exceeds the master's serial number).


Antonio Querubin
e-mail: to...@lavanauts.org
xmpp: antonio...@gmail.com

Evan Hunt

unread,
Dec 19, 2013, 1:22:06 AM12/19/13
to Antonio Querubin, bind-users
On Wed, Dec 18, 2013 at 08:06:22PM -1000, Antonio Querubin wrote:
> Currently the serial numbers are all in sync. What I don't understand is
> what condition cause them to get out of sync (ie. the slave's serial
> number exceeds the master's serial number).

You're using inline-signing? Which server do you have doing the signing?

Name servers can get out of sync because the slaves haven't refreshed
recently, but in that case I would expect the master would be ahead of
the slave, not the other way around.

If you're using inline-signing and you have the slave signing, then
the slave's serial number would get ahead of the master's... but in
that case, the master should be "hidden" -- it shouldn't be listed
in the NS RRset for the zone, and a consistency check should ignore
it.

--
Evan Hunt -- ea...@isc.org
Internet Systems Consortium, Inc.

Antonio Querubin

unread,
Dec 19, 2013, 2:34:39 AM12/19/13
to Evan Hunt, bind-users
On Thu, 19 Dec 2013, Evan Hunt wrote:

> You're using inline-signing? Which server do you have doing the signing?

Only the master has 'auto-dnssec maintain' in the zone config.

> Name servers can get out of sync because the slaves haven't refreshed
> recently, but in that case I would expect the master would be ahead of
> the slave, not the other way around.

Yes I know.

> If you're using inline-signing and you have the slave signing, then
> the slave's serial number would get ahead of the master's... but in
> that case, the master should be "hidden" -- it shouldn't be listed
> in the NS RRset for the zone, and a consistency check should ignore
> it.

No, the slaves don't do any signing, just the master.
0 new messages