moving DNSSEC to a hidden master [SOLVED]

David Newman dnewman at networktest.com
Mon Oct 14 19:12:16 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Alan,

Thanks very much for your responses. Per my comments inline below,
this actually wasn't broken to begin with, but I just wasn't seeing it.

On 10/14/13 10:43 AM, Alan Clegg wrote:
> 
> On Oct 13, 2013, at 9:03 PM, David Newman <dnewman at networktest.com>
> wrote:
> 
>>>>> This is where things fall apart. I run 'rndc freeze' and 
>>>>> increment the zone file's serial number (or make any other 
>>>>> change), and then run 'rndc thaw' and 'rndc reload'.
> 
> So, I'm going to jump back a bit here.... If the configuration that
> you posted is what is actually running, you should get the
> following when you try to "rndc freeze":

When I said I used 'rndc freeze' and 'rndc reload', those really were
the commands I used. I did not use 'rndc <command> <zone>'
specifically because this is a static zone, and as you note that
doesn't work.

In case you couldn't tell by now, I don't use dynamic zones. If the
freeze/thaw commands are superfluous here, please let me know.

My (admittedly limited) understanding is that DNSSEC inline signing
copies the contents of the static zone into a dynamic zone and then
serves that, leaving the static zone unchanged.

It sounds as though you're saying I don't need the freeze/thaw
commands with static zones. Yes?

> 
> root at server00:/etc/namedb# rndc freeze example.com rndc: 'freeze'
> failed: not dynamic root at server00:/etc/namedb#
> 
> With the associated logging:
> 
> 14-Oct-2013 17:36:00.310 received control channel command 'freeze
> example.com'
> 
> You have views... is the definition of the internal one different
> from the external one (which you posted)?

Nope, this zone appears only in the external view.

> 
> So, I re-created your zone with the following zone entry:
> 
> zone "example.com" in { type master; file "master/example.com"; 
> allow-query { any; }; allow-transfer { any; }; notify yes; 
> key-directory "keys/"; inline-signing yes; auto-dnssec maintain; 
> };
> 
> This zone isn't dynamic based on what you have posted.

Yes, that's right.

> 
> It also works fine when I make changes (no "freeze"/"thaw"
> needed):
> 
> == Commands typed == root at server00:/etc/namedb# ls bind.keys  keys
> master  named.conf  rndc.key root at server00:/etc/namedb# cd master 
> root at server00:/etc/namedb/master# ls example.com  example.com.jbk
> example.com.signed  example.com.signed.jnl 
> root at server00:/etc/namedb/master# vi example.com 
> root at server00:/etc/namedb/master# rndc reload example.com zone
> reload queued root at server00:/etc/namedb/master#


Same here, except that file locations and permissions differ a bit on
FreeBSD (e.g., DNSSEC-signed zones MUST reside in a directory owned by
bind, so not 'master' because root owns that).

> == Logging produced == 14-Oct-2013 17:39:26.565 received control
> channel command 'reload example.com' 14-Oct-2013 17:39:26.571 zone
> example.com/IN (unsigned): loaded serial 2 14-Oct-2013 17:39:26.571
> zone example.com/IN (signed): serial 4 (unsigned 2)
> 
> And for those of you that have taken the DNS and BIND class, yes,
> I'm really using the very same lab environment that you used in
> class to test things... it works!

This is the crux of the problem: I was watching serial changes from
dig, not from the Bind logs.

In this case, I started with a serial of 2013092700, incremented it to
2013092701, and reloaded. 'dig soa' would still return 2013092700.

Problem is, bind logged the current serial number as 2013092705.
Guessing here, but it looks as though my change wouldn't be seen by
dig or any other external tool because internally, Bind was already on
a larger serial number.

As soon as I advanced the serial to something ahead of the one in the
logs, everything worked again.

This is probably another thing for dynamic zone fans to snicker at us
static zone users about. But as long as the static zone file's serial
number is greater than or equal to the internal serial number (modulo
a counter wrap), this appears to work OK.

Thanks again for the pointers. Much appreciated.

dn


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJcQhAACgkQyPxGVjntI4LWBgCg4z9M6munwjcag6TtPJuk1ey7
5B8An1z+TkRuSLAUpKyUrWmKU/T7/dvl
=3lB+
-----END PGP SIGNATURE-----


More information about the bind-users mailing list