redundant bump-in-the-wire signers using BIND

[Michael Sinatra]

To close the loop a bit on this...

On 05/22/18 03:22, Tony Finch wrote:
> Michael Sinatra <michael at brokendns.net> wrote:
>>
>> My only concern is that serial numbers might get out of sync between the
>> two signers at some point.
> 
> You can avoid this problem with `serial-update-method unixtime`.
> 
> HOWEVER! I think you are going to have problems with inconsistent IXFRs
> depending on which signer the public authoritative servers talk to. You
> can work around this by only using AXFR, by turning off `provide-ixfr` and
> `request-ixfr`.

Thanks, Tony, that's a great point, and it ultimately led me to the work
done on by the yeti-dns project.  One of their experiments was a
multi-signer, multi-ZSK setup.[1]  That's a bit different from what I am
doing, as I am actually synching the private keys.  However, since I am
also signing with ECDSA, and the major crypto libraries don't yet
support deterministic ECDSA, I am going to have differing sigs no matter
how synchronized they are.

In testing this setup over the past several weeks, it appears that BIND
operates in the same way as NSD, in that, if it tries an ixfr and can't
cleanly diff the updated zone into the old one, it falls back to axfr.
Here's an example log:

18-Jun-2018 14:25:42.698 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: connected using
cleverly:obfuscated:ipv6:client-address#41964
18-Jun-2018 14:25:42.724 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: failed while receiving
responses: not exact
18-Jun-2018 14:25:42.724 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: Transfer status: IXFR failed
18-Jun-2018 14:25:42.724 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: Transfer completed: 0
messages, 11 records, 0 bytes, 0.025 secs (0 bytes/sec)
18-Jun-2018 14:25:43.203 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: connected using
cleverly:obfuscated:ipv6:client-address#41965
18-Jun-2018 14:25:43.229 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: Transfer status: success
18-Jun-2018 14:25:43.229 transfer of '6tap.net/IN' from
cleverly:obfuscated:ipv6:server-address#53: Transfer completed: 1
messages, 61 records, 5366 bytes, 0.025 secs (214640 bytes/sec)


The fallback to AXFR is not an issue for the zones I am currently
signing because they are not that big and don't change very often (there
are no dynamic DHCP names in these zones, for example).  So it does seem
like this will work, but I am doing some more testing (and have run into
another issue, which will be in a different thread).  Thanks, though for
the heads up.

michael

[1] See
https://raw.githubusercontent.com/BII-Lab/Yeti-Project/master/doc/Report-MZSK.md
and https://tools.ietf.org/html/draft-song-yeti-testbed-experience-06
(section 4.2.1) for more info.  To be on the safe side, it may make
sense to just configure AXFR all of the time, but BIND seems to be doing
a good job of falling back to AXFR when it detects an inconsistency.