Re: NOTIFY and TSIG
You use TSIG when transferring a zone to ensure you are talking to a valid
primary.
Spoofed NOTIFY messages where accounted for when NOTIFY was developed. The
server
will protect itself from spurious NOTIFY messages by rate limiting. Now if you
are
using views you can use TSIG to select the correct view and hence zone
instance, to
deliver the NOTIFY to.
> On 9 Jan 2024, at 14:40, Nick Tait via bind-users
> wrote:
>
> Hi list.
> I've been trying to understand whether it is necessary for the NOTIFY request
> (i.e. sent from primary to secondary server) to use TSIG, in the case where
> the secondary server specifies a key in its zone's "primaries" option?
> For example, assume the following set-up:
> The primary server (192.0.2.1) specifies the following configuration:
> key "secret-key.example.com" { ... };
> zone "example.com" {
> type primary;
> file "/etc/bind/db.example.com";
> notify yes;
> allow-transfer { key "secret-key.example.com"; };
> };
>
> And the secondary server (192.0.2.2) specifies:
> key "secret-key.example.com" { ... };
> zone "example.com" {
> type secondary;
> file "db.example.com";
> primaries { 192.0.2.1 key "secret-key.example.com"; };
> notify no;
> };
>
> And if the zone file db.example.com (on the primary server) contained:
> $TTL 3600
> @ IN SOA server1 root.server1 1 86400 7200 2419200 1800
> @ IN NS server1
> @ IN NS server2
> server1 IN A 192.0.2.1
> server2 IN A 192.0.2.2
>
> In this case when the zone is changed on the primary server, it will send an
> unsigned NOTIFY to the secondary server. The question I was trying to answer
> was: With the configuration above, will the secondary server accept the
> unsigned notification?
> I was hoping to find an RFC that answered this question, but didn't have any
> luck Googling. However the BIND documentation for "allow-notify"
> (https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-allow-notify)
> contains the following text:
> allow-notify
> ...
> Defines an address_match_list that is allowed to send NOTIFY messages for the
> zone, in addition to addresses defined in the primaries option for the zone.
> ...
> If not specified, the default is to process NOTIFY messages only from the
> configured primaries for the zone. allow-notify can be used to expand the
> list of permitted hosts, not to reduce it.
> My interpretation of the above was that if a key is specified in the
> "primaries" option, then the secondary would require the NOTIFY to be signed
> by the same key? However when I tested this theory, I found the secondary did
> accept (and process) the unsigned NOTIFY.
> While I understand (and agree) that this behaviour makes the most sense,
> given my confusion based on the documentation, I wonder if the documentation
> could be made clearer? E.g. Add the sentence: "In the case where the
> primaries option specifies a TSIG key, it is not necessary for the received
> NOTIFY to be signed by the same key."
> Thanks,
> Nick.
> --
> 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
NOTIFY and TSIG
Hi list.
I've been trying to understand whether it is necessary for the NOTIFY
request (i.e. sent from primary to secondary server) to use TSIG, in the
case where the secondary server specifies a key in its zone's
"primaries" option?
For example, assume the following set-up:
The primary server (192.0.2.1) specifies the following configuration:
key "secret-key.example.com" { ... };
zone "example.com" {
type primary;
file "/etc/bind/db.example.com";
notify yes;
allow-transfer { key "secret-key.example.com"; };
};
And the secondary server (192.0.2.2) specifies:
key "secret-key.example.com" { ... };
zone "example.com" {
type secondary;
file "db.example.com";
*primaries { 192.0.2.1 key "secret-key.example.com"; };*
notify no;
};
And if the zone file db.example.com (on the primary server) contained:
$TTL 3600
@ IN SOA server1 root.server1 1 86400 7200 2419200 1800
@ IN NS server1
@ IN NS server2
server1 IN A 192.0.2.1
server2 IN A 192.0.2.2
In this case when the zone is changed on the primary server, it will
send an /unsigned/ NOTIFY to the secondary server. The question I was
trying to answer was: /With the configuration above, will the secondary
server accept the unsigned notification?/
I was hoping to find an RFC that answered this question, but didn't have
any luck Googling. However the BIND documentation for "allow-notify"
(https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-allow-notify)
contains the following text:
*allow-notify*
...
Defines an address_match_list that is allowed to send NOTIFY
messages for the zone, in addition to addresses defined in the
primaries option for the zone.
...
If not specified, the default is to process NOTIFY messages only
from the configured primaries for the zone. allow-notify can be used
to expand the list of permitted hosts, not to reduce it.
My interpretation of the above was that if a key is specified in the
"primaries" option, then the secondary would require the NOTIFY to be
signed by the same key? However when I tested this theory, I found the
secondary did accept (and process) the unsigned NOTIFY.
While I understand (and agree) that this behaviour makes the most sense,
given my confusion based on the documentation, I wonder if the
documentation could be made clearer? E.g. Add the sentence: "In the case
where the primaries option specifies a TSIG key, it is not necessary for
the received NOTIFY to be signed by the same key."
Thanks,
Nick.
--
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: [Windows] [9.16.45] Missing IPv4 DNS prevents tools from working
No, 9.16 is already in the “security or critical bugfixes only” for two years (or so). This is a very minor issue on platform that’s being obsoleted. Sorry. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 8. 1. 2024, at 18:42, Gentry Deng via bind-users > wrote: > > I noticed that version 9.16 is about to be EOL. I wonder if this BUG can be > fixed before EOL? After all, this is the only version of BIND 9 that still > supports the Windows platform. -- 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: [Windows] [9.16.45] Missing IPv4 DNS prevents tools from working
Am 09.01.2024 um 01:41:46 Uhr schrieb Gentry Deng via bind-users: > Due to an accident my local network is missing IPv4 DNS but has IPv6 > DNS so it has little impact on accessing the internet. > > But I found that neither `dig `nor `nslookup` worked, and reported an > error: Windows Linux subsystem? Does it have an IPv6 address? Run ip a or ifconfig inside it. -- 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
[Windows] [9.16.45] Missing IPv4 DNS prevents tools from working
Hello there, Due to an accident my local network is missing IPv4 DNS but has IPv6 DNS so it has little impact on accessing the internet. But I found that neither `dig `nor `nslookup` worked, and reported an error: ``` C:\Program Files\ISC BIND 9\bin\dig.exe: parse of C:\Program Files\ISC BIND 9\etc\resolv.conf failed ``` There is actually no "resolv.conf" there, they get the DNS from the system and if IPv4 DNS is missing it will throw an error. Creating "resolv.conf" manually also does not prevent the problem. I noticed that version 9.16 is about to be EOL. I wonder if this BUG can be fixed before EOL? After all, this is the only version of BIND 9 that still supports the Windows platform. Best regards, Gentry -- 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
AW: migration from auto-dnssec to dnssec-policy deletes keys immediately
Hi all!
I also know a colleague which was hit by the same issue, causing problems to
their zone.
Migrating from auto-dnssec to dnssec-policy can lead to operational issues. For
example that problem with different algos should be mentioned in
https://kb.isc.org/docs/dnssec-key-and-signing-policy
Further, I suggest to add something like the following sentence to that
article: Changing DNSSEC configuration can lead to unexpected zone changes and
should be tested on dedicated test systems before. If you do this on a hidden
master, you could also temporarily disable outgoing XFR by configuring
'allow-transfer {"none";};' on that zone to prevent leakage of broken DNSSEC
zones. This way you can check the zone after migration and only after
successful testing (i.e. using https://dnsviz.net/d/ops.nic.at/analyze/ with
advanced options, pointing directly to the hidden master) re-enable outgoing
XFR.
Regards
Klaus
Von: bind-users Im Auftrag von Nick Tait via
bind-users
Gesendet: Donnerstag, 28. Dezember 2023 04:01
An: bind-users@lists.isc.org
Betreff: Re: migration from auto-dnssec to dnssec-policy deletes keys
immediately
On 28 Dec 2023, at 1:05 PM, Adrian Zaugg
mailto:lists.isc@mailgurgler.com>> wrote:
2023-12-27 23:51:24: zone myzone.ch/IN (signed): reconfiguring zone keys
2023-12-27 23:51:24: keymgr: retire DNSKEY myzone.ch/ECDSAP256SHA256/14076
(KSK)
2023-12-27 23:51:24: keymgr: retire DNSKEY myzone.ch/ECDSAP256SHA256/3654
(ZSK)
2023-12-27 23:51:24: keymgr: DNSKEY myzone.ch/ED25519/2336 (KSK) created for
policy mypolicy
2023-12-27 23:51:24: keymgr: DNSKEY myzone.ch/ED25519/35413 (ZSK) created for
policy mypolicy
Your DNSSEC policy “mypolicy” specifies a different algorithm (ED25519) to what
was previously in effect (ECDSAP256SHA256), which is why Bind generated new
keys. If you want Bind to keep the old keys when transitioning to dnssec-policy
you should initially specify the same algorithm in your policy.
My understanding is that after you’ve transitioned to using dnssec-policy you
should be able to change the algorithm and Bind should do a graceful roll-over?
Just make sure everything is “omnipresent” in your state files (in the keys
directory) first.
Nick.
--
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
