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-p
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
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 subsy
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 outs
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 ser
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 co
6 matches
Mail list logo
