moving DNSSEC to a hidden master [SOLVED]

[Alan Clegg]

On Oct 14, 2013, at 9:12 PM, David Newman <dnewman at networktest.com> wrote:

> 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.

8-)  No problems.

> > 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.

Yes.  The use of the freeze and thaw is not needed unless you are hand-modifying dynamic zones.  

> 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.

Yes, it does that, but it does it "hidden from the user" -- you don't need to deal with it as if it is dynamic, just do what you were doing before and ignore the ".signed" and ".jnl" files that are created.

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

Correct.  You treat inline-signed zones exactly like you do static zones.  Pretend it's not even happening.

[...]

> 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.

So, you were able to see the <zone> and <zone (signed)> entries in the log file?

> 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.

You shouldn't need to keep track of the "signed" vs. "unsigned" serial numbers.  Inline signing is supposed to be completely (and I mean 100%) transparent to the process that you had in place prior to signing.

Now that you have (what I'll call) "synchronized-but-out-of-sync-due-to-inline-signing" serial numbers (the signed one should be a bit higher than the unsigned one but you'll only see that from the log messages; dig should ALWAYS produce the higher number), can you try incrementing the serial on your static/unsigned zone by one, reloading the zone and seeing what the logging produces?  It _should_ increment the signed version (otherwise your slaves will never update), when you reload the zone (as the SOA is resigned).   [wow, that's a horrible paragraph, but I think it makes sense]

Also note that the inline-signed zone (in memory and dumped out to zone.signed file) will continue to increment serial numbers even without you making changes to the static/unsigned zone because of internal re-signing caused by signature expiration.

> Thanks again for the pointers. Much appreciated.

No problem,
AlanC
-- 
Alan Clegg | +1-919-355-8851 | alan at clegg.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20131014/54173129/attachment-0001.bin>