Hi, On 12/15/20 8:35 AM, libor.peltan wrote: > Hi Einar, > > a "warm standby" is a good idea. I assume that the immediate secondary of the > signer will NOT have the standby configured as a "master", until the > "promotion script" is called. > > However, even in this setup, there is no point in synchronizing the SOA > serials. Instead, the promotion script shall ensure, that after the promotion > the secondary does NOT download IXFR from the new > signer, and forces AXFR to prevent any surprises ;)
I think disabling journal on the backup signer might be a reasonable solution. This backup approach also eliminates possible issues relating bugs in incremental signing. Or you could backup/restore journal contents (DNSSEC stuff). This should ensure correct outgoing IXFR. Einar, I wouldn't recommend `zonefile-load: difference-no-serial` for such a serious deployment like TLD! But if you need it, don't forget to set `journal-content: all` (will be required in future Knot DNS versions). Daniel > > /Libor > > Dne 15. 12. 20 v 0:10 Einar B. Halldórsson napsal(a): >> Hi Libor, >> >>> AFAIK using multiple parallel signers is an unexplored territory in DNS. >>> >>> It's not difficult to ensure matching SOA serials, but having different >>> zone versions with same SOA serial is only asking for more trouble: what >>> if any secondary takes (for whatever reason) an IXFR from the other >>> signer than previously... >>> >>> There is a way to sign zone deterministicly (either RSA or Deterministic >>> ECDSA), but whole DNSSEC relies on unix timestamp, and it seems not >>> viable to establish a second-precision sync among signers. There have >>> been thoughts about this previously, but none went far enough to be >>> adopted by Knot. >>> >>> I agree it would be useful to have parallel signers, for the sake of >>> reliability, even better if they were of very different implementations. >>> But I haven't heard of any functioning setup. I assume most operators >>> simply rely on a single signer, while they are able to fix any issues >>> before the zone expires on public secondaries. >>> >> Our plan is to have basically a warm standby. It will have a backup of >> the keys and the same zone data, but it will not send notifies and will >> not accept XFR. A promotion script will turn on notifies and permit XFR. >> >> The benefit of keeping it warm is that we'll be able to monitor it and >> fix any problems with signing if and when they arise. We'd rather not >> discover it and have to deal with it when the active signer has failed. >> >>> BR, >>> >>> Libor >>> >>> PS: it's both odd and inspiring how different TLD operators face >>> different issues and focus on different goals: .de strikes frequency of >>> updates, .be triple-checks that the zone was not signed incorrectly, .is >>> seeks assurance that the signer keeps running ... :) >>> >> .be triple checks after they were hit with >> https://www.dnsbelgium.be/en/news/nsec3-issue-15112018 :) >> >> OpenDNSSEC has served us well these last years, but knot is a much better >> fit for us. The new online backup/restore makes syncing keys super easy >> and the config is very ansible friendly, something that opendnssec does not >> have. >> >> .einar -- https://lists.nic.cz/mailman/listinfo/knot-dns-users
