On Oct 14, 2013, at 9:12 PM, David Newman <dnew...@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 | a...@clegg.com
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users