DNSSEC signing common zone in views
Hello all,
I am consolidating our old split DNS consisting of internal and
external dedicated servers(VMs) into one primary server with views
(there will be secondaries, but they are not important to the
question). The old previous configuration is using inline-signing and
auto-dnssec. I will be switching to dnssec-policy with csk. This is
fine.
My question is what would be considered best practice when I want the
zone to be signed by the same CSK in every view. Should I point both
zones to the same "key-directory", or should I use a different
directory for every view? And how would the key rollover work in such
a case?
I have tried to use the same key-directory for both zones in each
view. It seems to technically work. But maybe someone could point out
some disadvantages I will be facing in the future? Is there common
consensus on how this is supposed to be approached? Maybe I am
handling it all wrong and there is a much better way :)
The config I tested:
dnssec-policy "ACME" {
keys { csk key-directory lifetime unlimited algorithm 13; };
nsec3param iterations 1 optout false salt-length 16;
};
view internal {
match-clients { internal; };
zone "ACME.cz" {
type primary;
file "primary/internal/ACME.cz/ACME.cz.zone";
inline-signing yes;
key-directory "dnssec-keys/ACME.cz";
dnssec-policy "ACME";
};
};
view external {
match-clients { external; };
zone "ACME.cz" {
type primary;
file "primary/external/ACME.cz/ACME.cz.zone";
inline-signing yes;
key-directory "dnssec-keys/ACME.cz";
dnssec-policy "ACME";
};
};
---
ns1-new /var/named/dnssec-keys/ACME.cz # cat KACME.cz.+013+14237.state
; This is the state of key 14237, for ACME.cz.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20190611121855 (Tue Jun 11 14:18:55 2019)
Published: 20190611121855 (Tue Jun 11 14:18:55 2019)
Active: 20190611121855 (Tue Jun 11 14:18:55 2019)
PublishCDS: 20190612132355 (Wed Jun 12 15:23:55 2019)
DNSKEYChange: 20220907123627 (Wed Sep 7 14:36:27 2022)
ZRRSIGChange: 20220907123627 (Wed Sep 7 14:36:27 2022)
KRRSIGChange: 20220907123627 (Wed Sep 7 14:36:27 2022)
DSChange: 20220907123627 (Wed Sep 7 14:36:27 2022)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent
# named -V
BIND 9.18.6 (Stable Release)
running on Linux x86_64 4.18.0-372.19.1.el8_6.x86_64 #1 SMP Tue Aug 2
16:19:42 UTC 2022
Thanks,
Josef
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone transfer over VPN
Use tsig-keygen
> On 7 Sep 2022, at 17:33, Michael De Roover 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 :
>RSASHA1 | NSEC3RSASHA1 |
>RSASHA256 | RSASHA512 |
>ECDSAP256SHA256 | ECDSAP384SHA384 |
>ED25519 | ED448 | DH
>-b :
>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@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: ma...@isc.org
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone transfer over VPN
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 :
RSASHA1 | NSEC3RSASHA1 |
RSASHA256 | RSASHA512 |
ECDSAP256SHA256 | ECDSAP384SHA384 |
ED25519 | ED448 | DH
-b :
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
