Zone transfer over VPN

[Mark Andrews]

Use tsig-keygen

> On 7 Sep 2022, at 17:33, Michael De Roover <isc at nixmagic.com> wrote:
> 
> 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
> 
> 
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org