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