Zone transfer over VPN
Mark Andrews
marka at isc.org
Wed Sep 7 07:49:21 UTC 2022
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
More information about the bind-users
mailing list