To put more detail on this the DS is *only* used to verify the DNSKEY
RRset. As long as that returns trusted *every* DNSKEY in that RRset is
valid for verifying the rest of the zone. There is NO requirement to
look at the DS RRset when verifying anything other than the DNSKEY
RRset.
TA -> DNSKEY
Well if you are attacking the resolver by sending invalid RRSIGs ...
> On 15 Feb 2024, at 11:15, Matt Nordhoff via bind-users
> wrote:
>
> Hello,
>
> I'm not sure if this is a bug or a feature, but the recent CVE fixes
> prevent resolving paste.debian.net with DNSSEC validation on.
>
> It is
Hello,
I'm not sure if this is a bug or a feature, but the recent CVE fixes
prevent resolving paste.debian.net with DNSSEC validation on.
It is a CNAME:
$ dig +short paste.debian.net
apu.snow-crash.org.
p.snow-crash.org.
148.251.236.38
debian.net is fine, but snow-crash.org is misconfigured: It
Hi Mounika
If you connect to a secondary nameserver to accept dynamic zone updates you
have to configure on the secondary inside the slave zone section a statement:
allow-update-forwarding { dhcp-updates; };
...where "dhcp-updates" is an ACL (that could be named as you l
On 14.02.24 17:06, trgapp16 via bind-users wrote:
I configured Bind 9.18.12 as slave DDNS with dynamic updates from DHCP (ISC
DHCP 4.4)
running on the same server (Ubuntu 22.04 server)
When I run "named-checkconf named.conf", I get the following error
"named.conf:2018: option 'allow-update' is
Hello,
I configured Bind 9.18.12 as slave DDNS with dynamic updates from DHCP (ISC
DHCP 4.4)
running on the same server (Ubuntu 22.04 server)
When I run "named-checkconf named.conf", I get the following error
"named.conf:2018: option 'allow-update' is not allowed in 'slave' zone
'zonename.com
Transfer from a single address.
The IXFR transfer is detecting that a record is being asked to be deleted but
it is not present in the zone. Named will fallback to an AXFR. The logs have
been extended recently to provide more details.
--
Mark Andrews
> On 14 Feb 2024, at 18:41, Andreas S.
Solved by adding 'server-id' to named.conf.options.
Thank you Petr Špaček for the suggestion.
Op 14/02/2024 om 10:23 schreef Marco Davids (SIDN):
I have upgraded two servers to 9.18.24 and the funny thing is that on
one server id.servers works well:
;; ANSWER SECTION:
id.server. 0
Hey,
could you run the other server manually with same configuration but on a
different port and enable -d 99 on a command line? That could give some hints.
--
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
I have upgraded two servers to 9.18.24 and the funny thing is that on
one server id.servers works well:
;; ANSWER SECTION:
id.server. 0 CH TXT "one"
And on the other it does not:
;; AUTHORITY SECTION:
id.server. 86400 CH SOA id.server. hostmaster.id.server. 0 28800
10 matches
Mail list logo
