Thanks Mark. It's right there in the log.
Bob
--
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 mail
Named will tell you which DNSSEC algorithms it supports. Depending upon the OS
and its configuration this may differ.
DNSSEC algorithms: RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519
ED448
vs
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256
ECDSAP384S
Would this be true for FreeBSD as well? I also have a bind 9.18.24
instance running on freeBSD
and it seems to be ok.
Bob
> The crypto policy stuff ultimately creates and maintains files in
/etc/crypto-policy/backends, which has a list of acceptable or
not-acceptable crypto settings.
> Whilst a
art
From: bind-users on behalf of John Thurston
Date: Thursday, 18 April 2024 at 06:39
To: "bind-users@lists.isc.org"
Subject: Re: Answers for www.dnssec-failed.org with dnssec-validation auto;
Arrgh. You are correct. I was so far down in the weeds, I didn't notice a rock
had fall
Arrgh. You are correct. I was so far down in the weeds, I didn't notice
a rock had fallen on my head.
I know I can re-enable SHA1 for everything on the host with:
update-crypto-policies --set DEFAULT:SHA1
But that's a fairly broad stroke, when only 'named' needs to accept such
signatures. Is
My bind 9.18.24 server runs under Debian.
When I query with dig it appears to take long enough to resolve that it
goes to the next DNS server in the client's IP stack. The secondary server
in my list is quad9. It seems to resolve correctly. If I point to the
address of my Debian server, it works bu
"ns88-testPrimary-key";
};
};
options {
directory "/var/opt/testPrimary/named/data";
dump-file "cache_dump.db";
listen-on port 1053 {
127.0.0.1/32;
};
dump-file "cache_dump.db";
listen-on port 1053 {
127.0.0.1/32;
};
querylog yes;
dnssec-validation auto;
empty-zones-enable no;
recursion yes;
};
key "ns88-testPrimary-key" {
algorithm "hmac-sha256";
On 17/04/2024 11:41, John Thurston wrote:
I'm seeing strange behavior with a BIND 9.18.24 resolver and
dnssec-failed.org.
With no dnssec-validation line (or with "dnssec-validation auto") in
the .conf, querying for www.dnssec-failed.org returns SERVFAIL, as
expected . . u
I'm seeing strange behavior with a BIND 9.18.24 resolver and
dnssec-failed.org.
With no dnssec-validation line (or with "dnssec-validation auto") in the
.conf, querying for www.dnssec-failed.org returns SERVFAIL, as expected
. . until it doesn't. After several seconds of a
On 27. 01. 22 16:05, Gehrkens.IT GmbH | Heiko Wundram wrote:
Hello Tony,
The other things that can cause the behaviour you observed are synth-from-
dnssec and qname-minimization.
thanks for the heads up concerning synth-from-dnssec; I thought the default
was "no", but that seems to have chang
Hello Tony,
> The other things that can cause the behaviour you observed are synth-from-
> dnssec and qname-minimization.
thanks for the heads up concerning synth-from-dnssec; I thought the default
was "no", but that seems to have changed somewhere between 9.14 and 9.16...
I've just changed that
Gehrkens.IT GmbH | Heiko Wundram wrote:
>
> From what I gather, this behaviour sounds almost like what RFC 8020 proposes
> (NXDOMAIN cut), but at least according to the corresponding ticket, that
> isn't implemented in BIND.
The other things that can cause the behaviour you observed are
synth-fro
ews have dnssec-validation auto (set as a
global option), and the forwarding zones are configured as "type forward;
forward only;" in each specific view using an import from a single
configuration file which contains all forward zone specifications and also a
"validate-except" clause whi
resolv.conf has only itself as dns server
When using dnssec-validation AUTO, and turning on debug, the following is shown
when I nslookup from my PC towards the server.
13-Nov-2020 11:09:18.998 client @0x7f7fb41d6b20 xxx.xxx.xxx.252#30201: request
is not signed
13-Nov-2020 11:09:18.998
NSSEC signed
domain. Try debuging salesforce.com. domain verification instead.
On 11/13/20 1:59 PM, Ismael Suarez wrote:
> With "dnssec-validation AUTO;" I get:
>
> # delv +cd www.popularsba.com
> ;; resolution failed: timed out
>
>
> With "dnssec-validation N
With "dnssec-validation AUTO;" I get:
# delv +cd www.popularsba.com
;; resolution failed: timed out
With "dnssec-validation NO;" I get:
# delv +cd www.popularsba.com
;; resolution failed: timed out
; unsigned answer
www.popularsba.com. 279 IN CNAME
Hi Ismael,
easiest way to check validation is using delv tool from BIND 9.11+. It
uses the same algorithm as BIND server does. If you get SERVFAIL from
your recursive server, try adding +cd parameter to delv or dig. When it
works with +cd, validation is responsible somewhere in recursive servers
c
Hi all
The following domain (www.popularsba.com) does not resolve with dnssec
validation set to auto, but when I change the validation off it works.
Why is this? How can I check this validation?
Using bind 9.12
Thanks to all
___
Please visit https://
orth double-checking.
W
> Based on what you copy-pasted, that appears to be the case.
>
> "dnssec-validation auto" causes named to use its built-in key for the root
> zone, so you don't have to put your own "managed-keys" statement into
> named.conf,
Shawn Zhou via bind-users wrote:
> Thanks Even. Sounds like "dnssec-validation auto" is a more
> future-proof option for what want it. I will use that instead.
My recommendation is to avoid configuring or installing root trust
anchors, and let named handle all that itself.
Thanks Even. Sounds like "dnssec-validation auto" is a more future-proof
option for what want it. I will use that instead.
On Wednesday, June 12, 2019, 5:25:51 PM PDT, Evan Hunt
wrote:
On Wed, Jun 12, 2019 at 11:40:27PM +, Shawn Zhou via bind-users wrote:
> The
ed-keys" statement is in named.conf (or included in
it via an "include" statement) then the keys will be updated automatically.
Based on what you copy-pasted, that appears to be the case.
"dnssec-validation auto" causes named to use its built-in key for the root
zone, so you do
Hi,
The default BIND9 installation for CentOS7 has dnssec-validation set to "yes"
and it also includes managed-keys as well. Do those managed-keys get updated
automatically? It is not clear from reading
https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html#dnssec-validation-explained
tha
24 matches
Mail list logo
