Re: Answers for www.dnssec-failed.org with dnssec-validation auto;
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 mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Answers for www.dnssec-failed.org with dnssec-validation auto;
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 ECDSAP384SHA384 ED25519 ED448 % named -V BIND 9.19.23-dev (Development Release) running on Darwin arm64 22.6.0 Darwin Kernel Version 22.6.0: Mon Feb 19 19:43:41 PST 2024; root:xnu-8796.141.3.704.6~1/RELEASE_ARM64_T8103 built by make with '--enable-developer' '--prefix=/usr/local' '--sysconfdir=/etc' '--localstatedir=/var' '--with-gssapi=krb5-config' 'CFLAGS=-g -mmacosx-version-min=13.1' 'PKG_CONFIG_PATH=/Users/marka/userspace-rcu/lib/pkgconfig:' '--with-cachedb=rbt' compiled by CLANG Apple LLVM 15.0.0 (clang-1500.1.0.2.5) compiled with OpenSSL version: OpenSSL 3.2.1 30 Jan 2024 linked to OpenSSL version: OpenSSL 3.2.1 30 Jan 2024 compiled with libuv version: 1.44.2 linked to libuv version: 1.44.2 compiled with liburcu version: 0.15.0-pre compiled with jemalloc version: 5.3.0 compiled with libnghttp2 version: 1.59.0 linked to libnghttp2 version: 1.61.0 compiled with libxml2 version: 2.11.6 linked to libxml2 version: 21206 compiled with json-c version: 0.11 linked to json-c version: 0.11 compiled with zlib version: 1.3.1 linked to zlib version: 1.3.1 linked to maxminddb version: 1.8.0 threads support is enabled DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448 DS algorithms: SHA-1 SHA-256 SHA-384 HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512 TKEY mode 2 support (Diffie-Hellman): no TKEY mode 3 support (GSS-API): yes default paths: named configuration: /etc/named.conf rndc configuration: /etc/rndc.conf nsupdate session key: /var/run/named/session.key named PID file: /var/run/named/named.pid geoip-directory: /opt/local/share/GeoIP % > On 18 Apr 2024, at 11:44, Bob McDonald wrote: > > 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 "bind.config" is created, you aren't including it in your config > > (this is fine), which suggests that the issue is with some of openssl > > configurations (which will be system wide anyway). > > > You can use the update-crypto-policies to update only the openssl > > configuration to allow sha1, or you could manually recreate those files > > (instead of the usual symlinks) and edit them individually as you please. > > > Stuart > -- > 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
Re: Answers for www.dnssec-failed.org with dnssec-validation auto;
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 "bind.config" is created, you aren't including it in your config (this is fine), which suggests that the issue is with some of openssl configurations (which will be system wide anyway). > You can use the update-crypto-policies to update only the openssl configuration to allow sha1, or you could manually recreate those files (instead of the usual symlinks) and edit them individually as you please. > Stuart -- 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: Answers for www.dnssec-failed.org with dnssec-validation auto;
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 "bind.config" is created, you aren't including it in your config (this is fine), which suggests that the issue is with some of openssl configurations (which will be system wide anyway). You can use the update-crypto-policies to update only the openssl configuration to allow sha1, or you could manually recreate those files (instead of the usual symlinks) and edit them individually as you please. Stuart 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 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 there a way to narrow it down? -- Do things because you should, not just because you can. John Thurston907-465-8591 mailto:john.thurs...@alaska.gov Department of Administration State of Alaska On 4/17/2024 9:21 AM, Ondřej Surý wrote: Let me guess - you are running on RHEL (without SHA-1 support) and dnssec-failed.org is signed with RSA/SHA-1… -- 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: 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 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 there a way to narrow it down? -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 4/17/2024 9:21 AM, Ondřej Surý wrote: Let me guess - you are running on RHEL (without SHA-1 support) and dnssec-failed.org is signed with RSA/SHA-1…-- 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: Answers for www.dnssec-failed.org with dnssec-validation auto; (John Thurston)
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 but it's REALLY slow. Dig shows both the address of the server providing the answer and the amount of time it took for the resolution. That MAY provide some clues as to what's going on. I suspect this is an issue with bind 9.18.24. I can't say for sure. HTH, Bob Sent from my Google Pixel phone. -- 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: Answers for www.dnssec-failed.org with dnssec-validation auto;
Let me guess - you are running on RHEL (without SHA-1 support) and dnssec-failed.org is signed with RSA/SHA-1…--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 17. 4. 2024, at 19:02, John Thurston wrote:
A fresh day, and a fresh idea - I just spun up a completely new
instance of named, listening on its own port, with a stripped down
config. Now the behavior is even stranger.
I can see the "no valid signature found" line in the server log,
but my 'dig' still gets an answer. What I can see in the logs
tells me that named has determined the answer is invalid, but then
it proceeds to deliver that answer to my client. I can't figure
out why.
I feel like I am too far down into the weeds, and there is
something basic I'm overlooking. Can anyone help re-orient me?
The .conf is pretty small, and looks like:
controls {
inet 127.0.0.1 port 1953 allow {
127.0.0.1/32;
} keys {
"ns88-testPrimary-key";
};
};
options {
directory "/var/opt/testPrimary/named/data";
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";
secret "";
};
When I launch it in the foreground, the output looks like:
17-Apr-2024
08:17:46.934 starting BIND 9.18.24 (Extended Support Version)
17-Apr-2024 08:17:46.934 running on Linux x86_64
5.14.0-362.18.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jan 29
07:05:48 EST 2024
17-Apr-2024 08:17:46.934 built with
'--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--program-prefix='
'--disable-dependency-tracking'
'--prefix=/opt/isc/isc-bind/root/usr'
'--exec-prefix=/opt/isc/isc-bind/root/usr'
'--bindir=/opt/isc/isc-bind/root/usr/bin'
'--sbindir=/opt/isc/isc-bind/root/usr/sbin'
'--sysconfdir=/etc/opt/isc/scls/isc-bind'
'--datadir=/opt/isc/isc-bind/root/usr/share'
'--includedir=/opt/isc/isc-bind/root/usr/include'
'--libdir=/opt/isc/isc-bind/root/usr/lib64'
'--libexecdir=/opt/isc/isc-bind/root/usr/libexec'
'--localstatedir=/var/opt/isc/scls/isc-bind'
'--sharedstatedir=/var/opt/isc/scls/isc-bind/lib'
'--mandir=/opt/isc/isc-bind/root/usr/share/man'
'--infodir=/opt/isc/isc-bind/root/usr/share/info'
'--enable-warn-error' '--disable-static' '--enable-dnstap'
'--with-pic' '--with-gssapi' '--with-json-c' '--with-libxml2'
'--without-lmdb' 'build_alias=x86_64-redhat-linux-gnu'
'host_alias=x86_64-redhat-linux-gnu' 'CC=gcc' 'CFLAGS=-O2
-flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
-march=x86-64-v2 -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed
-Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-L/opt/isc/isc-bind/root/usr/lib64' 'CPPFLAGS=
-I/opt/isc/isc-bind/root/usr/include'
'LT_SYS_LIBRARY_PATH=/usr/lib64'
'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig'
'SPHINX_BUILD=/builddir/build/BUILD/bind-9.18.24/sphinx/bin/sphinx-build'
17-Apr-2024 08:17:46.934 running as: named -g -4 -D testPrimary
-n 1 -u named -c /etc/opt/testPrimary/named.conf
17-Apr-2024 08:17:46.934 compiled by GCC 11.4.1 20230605 (Red
Hat 11.4.1-2)
17-Apr-2024 08:17:46.934 compiled with OpenSSL version: OpenSSL
3.0.7 1 Nov 2022
17-Apr-2024 08:17:46.934 linked to OpenSSL version: OpenSSL
3.0.7 1 Nov 2022
17-Apr-2024 08:17:46.934 compiled with libuv version: 1.44.2
17-Apr-2024 08:17:46.934 linked to libuv version: 1.44.2
17-Apr-2024 08:17:46.934 compiled with libxml2 version: 2.9.13
17-Apr-2024 08:17:46.934 linked to libxml2 version: 20913
17-Apr-2024 08:17:46.934 compiled with json-c version: 0.14
17-Apr-2024 08:17:46.934 linked to json-c version: 0.14
17-Apr-2024
Re: Answers for www.dnssec-failed.org with dnssec-validation auto;
A fresh day, and a fresh idea - I just spun up a completely new instance
of named, listening on its own port, with a stripped down config. Now
the behavior is even stranger.
I can see the "no valid signature found" line in the server log, but my
'dig' still gets an answer. What I can see in the logs tells me that
named has determined the answer is invalid, but then it proceeds to
deliver that answer to my client. I can't figure out why.
I feel like I am too far down into the weeds, and there is something
basic I'm overlooking. Can anyone help re-orient me?
The .conf is pretty small, and looks like:
controls {
inet 127.0.0.1 port 1953 allow {
127.0.0.1/32;
} keys {
"ns88-testPrimary-key";
};
};
options {
directory "/var/opt/testPrimary/named/data";
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";
secret "";
};
When I launch it in the foreground, the output looks like:
17-Apr-2024 08:17:46.934 starting BIND 9.18.24 (Extended Support
Version)
17-Apr-2024 08:17:46.934 running on Linux x86_64
5.14.0-362.18.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Jan 29
07:05:48 EST 2024
17-Apr-2024 08:17:46.934 built with '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--program-prefix='
'--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr'
'--exec-prefix=/opt/isc/isc-bind/root/usr'
'--bindir=/opt/isc/isc-bind/root/usr/bin'
'--sbindir=/opt/isc/isc-bind/root/usr/sbin'
'--sysconfdir=/etc/opt/isc/scls/isc-bind'
'--datadir=/opt/isc/isc-bind/root/usr/share'
'--includedir=/opt/isc/isc-bind/root/usr/include'
'--libdir=/opt/isc/isc-bind/root/usr/lib64'
'--libexecdir=/opt/isc/isc-bind/root/usr/libexec'
'--localstatedir=/var/opt/isc/scls/isc-bind'
'--sharedstatedir=/var/opt/isc/scls/isc-bind/lib'
'--mandir=/opt/isc/isc-bind/root/usr/share/man'
'--infodir=/opt/isc/isc-bind/root/usr/share/info'
'--enable-warn-error' '--disable-static' '--enable-dnstap'
'--with-pic' '--with-gssapi' '--with-json-c' '--with-libxml2'
'--without-lmdb' 'build_alias=x86_64-redhat-linux-gnu'
'host_alias=x86_64-redhat-linux-gnu' 'CC=gcc' 'CFLAGS=-O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64-v2
-mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
-fcf-protection -fno-omit-frame-pointer' 'LDFLAGS=-Wl,-z,relro
-Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
-L/opt/isc/isc-bind/root/usr/lib64' 'CPPFLAGS=
-I/opt/isc/isc-bind/root/usr/include' 'LT_SYS_LIBRARY_PATH=/usr/lib64'
'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig'
'SPHINX_BUILD=/builddir/build/BUILD/bind-9.18.24/sphinx/bin/sphinx-build'
17-Apr-2024 08:17:46.934 running as: named -g -4 -D testPrimary -n 1
-u named -c /etc/opt/testPrimary/named.conf
17-Apr-2024 08:17:46.934 compiled by GCC 11.4.1 20230605 (Red Hat
11.4.1-2)
17-Apr-2024 08:17:46.934 compiled with OpenSSL version: OpenSSL 3.0.7
1 Nov 2022
17-Apr-2024 08:17:46.934 linked to OpenSSL version: OpenSSL 3.0.7 1
Nov 2022
17-Apr-2024 08:17:46.934 compiled with libuv version: 1.44.2
17-Apr-2024 08:17:46.934 linked to libuv version: 1.44.2
17-Apr-2024 08:17:46.934 compiled with libxml2 version: 2.9.13
17-Apr-2024 08:17:46.934 linked to libxml2 version: 20913
17-Apr-2024 08:17:46.934 compiled with json-c version: 0.14
17-Apr-2024 08:17:46.934 linked to json-c version: 0.14
17-Apr-2024 08:17:46.934 compiled with zlib version: 1.2.11
17-Apr-2024 08:17:46.935 linked to zlib version: 1.2.11
17-Apr-2024 08:17:46.935
17-Apr-2024 08:17:46.935 BIND 9 is maintained by Internet Systems
Consortium,
17-Apr-2024 08:17:46.935 Inc. (ISC), a non-profit 501(c)(3) public-benefit
17-Apr-2024 08:17:46.935 corporation. Support and training for BIND 9 are
17-Apr-2024 08:17:46.935 available at https://www.isc.org/support
17-Apr-2024 08:17:46.935
17-Apr-2024 08:17:46.935 adjusted limit on open files from 524288 to
1048576
17-Apr-2024 08:17:46.935 found 1 CPU, using 1 worker thread
17-Apr-2024 08:17:46.935 using 1 UDP listener per interface
17-Apr-2024 08:17:46.936 DNSSEC algorithms: RSASHA256 RSASHA512
ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
17-Apr-2024 08:17:46.936 DS algorithms: SHA-1 SHA-256 SHA-384
17-Apr-2024 08:17:46.936 HMAC algorithms:
Re: Answers for www.dnssec-failed.org with dnssec-validation auto;
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 . . until it doesn't. After several seconds of answering
SERVFAIL, I start getting NOERROR responses, and IP addresses in the
ANSWER. It isn't a predictable number of seconds; sometimes 9,
sometimes 20.
Is this supposed to be happening?
When I examine the process with delv and my eyeballs, I can't see why
it is succeeding with dig and my validating resolver.
Maybe I'm not looking for the right things with my eyeballs? I'm
stumped, and looking for advice for nest-steps in understanding what's
going on.
The following one-liner:
# rndc flush && while true; do dig -4 www.dnssec-failed.org. A
@localhost; sleep 1; done
Hi John.
FYI I tried running your command myself and didn't see the same problem.
The first thing you'd want to rule out is the possibility that you have
more than one resolver running? E.g.
sudo netstat -anp | awk '{ if ($4 ~ /:53$/) print; }' | sort -u
The last column in the output from the command above should show a
number followed by a slash then a process name, which should be the same
on every line (e.g. "1804/named"). If it isn't, then see if you can stop
the other service(s) and then rerun your test?
If you have just a single process listening on port 53, then I'd suggest
using "tail -f" to watch your BIND logs (or syslog?) while you are
running your test, to see what is going on from the recursive resolver's
point of view? Hopefully you'll see something interesting when the
problem happens?
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
Answers for www.dnssec-failed.org with dnssec-validation auto;
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 answering SERVFAIL, I start getting NOERROR responses, and IP addresses in the ANSWER. It isn't a predictable number of seconds; sometimes 9, sometimes 20. Is this supposed to be happening? When I examine the process with delv and my eyeballs, I can't see why it is succeeding with dig and my validating resolver. Maybe I'm not looking for the right things with my eyeballs? I'm stumped, and looking for advice for nest-steps in understanding what's going on. The following one-liner: # rndc flush && while true; do dig -4 www.dnssec-failed.org. A @localhost; sleep 1; done Results in answers like: ; <<>> DiG 9.18.24 <<>> -4 www.dnssec-failed.org. A @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62774 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 9fd5ae2d4566c51d0100661f07f2bfc240421b91f851 (good) ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; Query time: 237 msec ;; SERVER: 127.0.0.1#53(localhost) (UDP) ;; WHEN: Tue Apr 16 15:21:22 AKDT 2024 ;; MSG SIZE rcvd: 78 ; <<>> DiG 9.18.24 <<>> -4 www.dnssec-failed.org. A @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7693 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 90175bca7b323c830100661f07f3467dc5a561eb4f77 (good) ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(localhost) (UDP) ;; WHEN: Tue Apr 16 15:21:23 AKDT 2024 ;; MSG SIZE rcvd: 78 --- after ~20 more like those --- ; <<>> DiG 9.18.24 <<>> -4 www.dnssec-failed.org. A @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34572 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 60f5a11077dc97240100661f0809905b6096fd5e287a (good) ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; ANSWER SECTION: www.dnssec-failed.org. 7199 IN A 68.87.109.242 www.dnssec-failed.org. 7199 IN A 69.252.193.191 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(localhost) (UDP) ;; WHEN: Tue Apr 16 15:21:45 AKDT 2024 ;; MSG SIZE rcvd: 110 ; <<>> DiG 9.18.24 <<>> -4 www.dnssec-failed.org. A @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2987 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 89a4502552606c370100661f080a5dd5f9299ddb95fe (good) ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; ANSWER SECTION: www.dnssec-failed.org. 7198 IN A 68.87.109.242 www.dnssec-failed.org. 7198 IN A 69.252.193.191 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(localhost) (UDP) ;; WHEN: Tue Apr 16 15:21:46 AKDT 2024 ;; MSG SIZE rcvd: 110 -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- 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
