Zone transfer over VPN

[Michael De Roover]

On Wednesday, September 7, 2022 1:14:00 AM WEST John Thurston wrote:
> If you are dealing with two totally private networks, do you even need
> the ACL?
> 
> But if you do need to limit access, then I suggest using TSIG to
> identify and authorize. This avoids the whole question of
> source/destination IP addresses. If the transfer request is made using
> the correct key, it will work.
> 
> I do this by defining a specific key for each secondary server. Then, in
> the appropriate view on the hidden primary, I use:
> 
>    match-clients { none; };
>    allow-transfer { key nameofkeyhere; };
> 
> and on each secondary, I define a 'primaries' and use that in the zone
> definitions:
> 
>    primaries hiddenprimary { 10.20.30.40 key nameofkeyhere; };
>    zone "foo.bar.com" { type secondary;  primaries { hiddenprimary; }; };
> 
> The address of the secondary does not matter. As long as it makes the
> connection to the primary using the key 'nameofkeyhere', it can do the
> zone transfers.

Hi John,

Thank you so much for getting back to me, I really appreciate it. I have used 
your advice and looked further into how to configure TSIG, and came across this 
article on nixCraft [1]. However, while the setup seems like it is fairly 
straightforward, the usage of HMAC-MD5 they mention seems to be deprecated. I 
have checked which ciphers dnssec-keygen supports in 9.18.5 (I have taken the 
time to upgrade the Alpine boxes while I was at it) and it seems like ED25519 
is supported, which I like and use extensively in SSH already. But when using 
the command below, it doesn't seem to work properly, exiting with the error 
message below that.

ns1:~# cd /etc/bind
ns1:/etc/bind# dnssec-keygen -a ED25519 -n HOST rndc-key
dnssec-keygen: fatal: invalid DNSKEY nametype HOST

Using this command without the -n parameter works fine, but (as per defaults) 
generates a zone key instead. Is ED25519 supported for host keys? If not, what 
would be the best current practice algorithm to generate a key of this type? 
Apparently the options in my installation of BIND are among these:

    -a <algorithm>:
        RSASHA1 | NSEC3RSASHA1 |
        RSASHA256 | RSASHA512 |
        ECDSAP256SHA256 | ECDSAP384SHA384 |
        ED25519 | ED448 | DH
    -b <key size in bits>:
        RSASHA1:        [1024..4096]
        NSEC3RSASHA1:   [1024..4096]
        RSASHA256:      [1024..4096]
        RSASHA512:      [1024..4096]
        DH:             [128..4096]
        ECDSAP256SHA256:        ignored
        ECDSAP384SHA384:        ignored
        ED25519:        ignored
        ED448:  ignored
        (key size defaults are set according to
        algorithm and usage (ZSK or KSK)

[1] https://www.cyberciti.biz/faq/unix-linux-bind-named-configuring-tsig/

Thanks again for your time to read this email, and for your insights.

-- 
Met vriendelijke groet / Best regards,
Michael De Roover