Hi!
In
https://bind9.readthedocs.io/en/v9.18.19/dnssec-guide.html
there's a link to
https://stats.research.icann.org/dns/tld_report/
which is no longer valid. New data seems to be here:
https://ithi.research.icann.org/
ITHI == idenitifier technologies health indicators
how many
Hi!
In the light of the recent exim security issues[1,2]
I'm trying to find out if bind 9.18.19, if used as resolver,
does enough validation to shield exim instances from CVE-2023-42119 ?
As details and reproducers for the CVE are not available, this is a
more general question. Pointers on where
Hi!
Mark wrote:
> > We do have somewhat extensive logging on our auth DNS servers,
> > and currently, we see a load of messages like those:
>
> > client @0x80357ad60 #5701 ( > 18 (null)
> They are debugging messages. Stop running in debug mode.
Done, logging is quieter now. Thanks!
--
Hi!
We do have somewhat extensive logging on our auth DNS servers,
and currently, we see a load of messages like those:
client @0x80357ad60 #5701 (#65358: set ede: info-code 18 extra-text (null)
What do those messages report and how can I silence those messages ?
--
p...@opsec.eu
Hi!
> I have a zone definition like this:
>
> zone "myzone" in {
> type master;file "signed/myzone";
Aha, this file path was wrong. Fixed, at least it crashes no longer.
--
p...@opsec.eu+49 171 3101372Now what ?
--
Visit
Hello,
I have a zone definition like this:
zone "myzone" in {
type master;file "signed/myzone";
allow-transfer { "myacl"; };
inline-signing yes;
dnssec-policy default;
};
and starting bind9.18.7 on FreeBSD 13.1 (self-compiled ports version)
leads to this crash, according to syslog, see
Hello,
we observed a strange behaviour for the domain foryoudecor.com,
when trying to resolve it using bind 9.18.2, using
dig -t mx foryoudecor.com
The bind log for 9.18.2 says:
May 11 12:00:14 ns named[96774]: fetch: foryoudecor.com/MX
May 11 12:00:14 ns named[96774]: DNS format error from
7 matches
Mail list logo
