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


___
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

Re: redundant bump-in-the-wire signers using BIND

[Tony Finch]

Michael Sinatra  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`.

If this is going to be painful for you because of zone sizes, you might
consider getting dirty with dnssec-signzone which gives you more control
over when signing happens and RRSIG validity periods. I think (depending
on the signature algorithm) this will allow you to ensure that the two
signers produce the same zones at the same times. But it'll require a fair
amount of fiddling to get right.

(My recovery plan for a failed signer is to reprovision a replacement from
scratch.)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
individual and social justice
___
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

redundant bump-in-the-wire signers using BIND

[Michael Sinatra]

Hi all:

First, let me explain the trade-off I am trying to manage (as succinctly
as possible):

My current setup has an DNS/IPAM system that backs up to a redundant one
in a different location, a bump-in-the-wire hardware signing appliance
(different from the IPAM), and a bunch of authoritative slaves running
BIND in an anycast cloud.

+-+ +---+
|  IPAM   | --> | HW Signer | --> (Slaves)
+-+ +---+

The HW signer also backs up to a redundant one elsewhere.  Failover for
both can either be manual or a complex combination of heartbeats and
synchronization that yields an active-standby arrangement.  I choose
manual here because our needs don't require immediate, seamless
failover, and I don't want the complexity.

Now, I'd like to replace the HW signers with VMs running BIND.  HSM is
not a requirement for me.  I can run dnssec-keymgr to generate keys on
one of the BIND VMs and then rsync the keys to the other (again,
geographically redundant).  The configurations are similarly synched
between the two.

I am trying to go for reasonable, practical security for the secret
keys, but I also want them backed up to one other location.  So having 2
geographically redundant VMs that can be locked down so that they only
talke to the IPAM and the slaves seems reasonable.  Putting secret keys
on all of the slaves, and having them do inline signing seems a bit more
reckless.  (There are other reasons I'd like to maintain the
bump-in-the-wire method, but I won't go into them now.)

My initial thought is that, as long as I can keep the keys and config in
sync between the two signing VMs, I can keep both VMs running bind *and*
can treat them both as stealth masters and have all of the slaves
configured to use both VMs as masters.  This obviates the need for
manual failover of the *signers*.

This seems to work in practice with a legacy zone that I am using for
testing.  The two signers sometimes sign at slightly different times, so
the signatures are different, but they both produce valid signatures.

My only concern is that serial numbers might get out of sync between the
two signers at some point.  If signer 1 is down for an extended period
of time, signer 2 may go through a few re-sign cycles and have a
consistently higher serial number in the case of a zone that isn't
modified much.

I can see two possible solutions: 1. manually "jiggle the handle" on the
IPAM by bumping the serial number to be greater than that of the larger
signer's SOA serial.  (The IPAM uses date/time serial format, so this
should be easy.) 2. use 'rndc signing -serial' to set the serial number,
possibly in concert with a monitoring script that checks to see if the
serial is out of sync.

Has anyone implemented anything like this?  Any other gotchas I should
be thinking about?  BIND does a good job of doing the right thing with
serial numbers, but I have yet to see (via google-foo or even bing-foo)
any evidence of anyone trying to do an active-active redundant
configuration with BIND inline-signing.

thanks!
michael
___
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