Maybe https://dnsviz.net/ ?
Mit freundlichen Grüßen
Julian Panke
-------- Ursprüngliche Nachricht --------
Am 04.11.24 12:58 um Robert Wagner schrieb :
Any chance someone from the bind group knows of an open-source DNS compliance
validation tool that can analyze and check configuration settings?
I hate to say it, but there are a lot of people managing DNS servers as part of
other responsibilities. If it responds with an IP, then they consider it
working/functional and nothing needs to be done. Having a tool that reviews
your configuration and points out issues would help us advocate for proper
configuration. Kind of a SSL checker for DNS...
Thanks in advance for any thoughts you can provide.
Robert Wagner
From: bind-users <bind-users-boun...@lists.isc.org> on behalf of Robert Edmonds
<edmo...@mycre.ws>
Sent: Friday, November 1, 2024 4:16 PM
To: Robert Mankowski <robert.mankow...@hotmail.com>
Cc: bind-users@lists.isc.org <bind-users@lists.isc.org>
Subject: Re: DNSSEC, OpenDNS and www.cdc.gov
This email originated from outside of TESLA
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
This is a problem with the operational configuration of the cdc.gov
nameservers.
The gov nameservers publish the following NS records for cdc.gov:
cdc.gov. 10800 IN NS auth00.ns.uu.net.
cdc.gov. 10800 IN NS auth100.ns.uu.net.
cdc.gov. 10800 IN NS ns1.cdc.gov.
cdc.gov. 10800 IN NS ns2.cdc.gov.
cdc.gov. 10800 IN NS ns3.cdc.gov.
The cdc.gov nameservers publish the following NS records for cdc.gov:
cdc.gov. 3600 IN NS ns1.cdc.gov.
cdc.gov. 3600 IN NS ns2.cdc.gov.
cdc.gov. 3600 IN NS ns3.cdc.gov.
This NS RRset from the cdc.gov nameservers (the NS RRset directly above
which has three .cdc.gov NS records) is the authoritative NS RRset for
cdc.gov and is used by standards conforming resolver implementation in
preference to the non-authoritative NS RRset in the referral response
from the .gov nameservers (the NS RRset at the top of this email with
five NS records). See RFC 2181, section 5.4.1.
The domain name www.cdc.gov is a CNAME to www.akam.cdc.gov:
www.cdc.gov. 300 IN CNAME www.akam.cdc.gov.
The ".cdc.gov" nameservers all generate RCODE "REFUSED" answers for
queries for www.akam.cdc.gov (as well as akam.cdc.gov):
; <<>> DiG 9.20.2-1-Debian <<>> +norec @ns1.cdc.gov www.akam.cdc.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 27267
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.akam.cdc.gov. IN A
;; Query time: 4 msec
;; SERVER: 198.246.96.61#53(ns1.cdc.gov) (UDP)
;; WHEN: Fri Nov 01 15:40:44 EDT 2024
;; MSG SIZE rcvd: 45
This is a standards conformance problem with the .cdc.gov nameservers.
The .cdc.gov nameservers should either return a response containing
records that answer the query, or a referral response to the nameservers
that do. See RFC 1034, section 4.3.2(3)(b).
The reason that some DNS resolver services are able to resolve this
name is because they are probably also querying the .uu.net nameservers
included in the delegation NS RRset for cdc.gov, and those nameservers
are able to return a delegation for the akam.cdc.gov zone:
; <<>> DiG 9.20.2-1-Debian <<>> +norec @auth00.ns.uu.net www.akam.cdc.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51056
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; NSID: 56 65 72 69 7a 6f 6e ("Verizon")
;; QUESTION SECTION:
;www.akam.cdc.gov. IN A
;; AUTHORITY SECTION:
akam.cdc.gov. 86400 IN NS a1-43.akam.net.
akam.cdc.gov. 86400 IN NS a5-66.akam.net.
akam.cdc.gov. 86400 IN NS a2-64.akam.net.
akam.cdc.gov. 86400 IN NS a8-67.akam.net.
akam.cdc.gov. 86400 IN NS a9-64.akam.net.
akam.cdc.gov. 86400 IN NS a28-65.akam.net.
;; Query time: 16 msec
;; SERVER: 198.6.1.65#53(auth00.ns.uu.net) (UDP)
;; WHEN: Fri Nov 01 15:44:13 EDT 2024
;; MSG SIZE rcvd: 185
To be clear, though, this is unambiguously a problem with the cdc.gov
nameservers and not a fault in resolver implementations that utilize the
authoritative NS RRset for cdc.gov which does not include the .uu.net
nameservers.
Various issues with the operation of the cdc.gov zone have been reported
to DNS-OARC's dns-operations mailing list over the years (as well as
other forums). The most recent thread is archived here:
https://lists.dns-oarc.net/pipermail/dns-operations/2024-July/022642.html
Robert Mankowski wrote:
> I recently implemented a forward only BIND server for home. I was forwarding
> to
> OpenDNS FamilyShield using TLS and DNSSEC at first, but I was getting a
> noticeable amount of SERVFAIL responses. I believe it is related to DNSSEC
> (see
> delv tests below), but I don’t believe it is my configuration because when I
> forward to Cloudflare’s Family service, or to Google DNS, I don’t have any
> problems with the same domains (e.g. www.cdc.gov).
>
>
>
> I contacted Cisco Umbrella support because I was thinking it’s an issue with
> their servers, but they didn’t really help, so I thought I would try this list
> for advice.
>
>
>
> Would appreciate it if someone could review my configuration and/or reproduce
> my results to see if I’m doing something wrong.
>
>
>
> Thanks,
>
>
>
> Bob
>
>
>
> Here are some tests I ran:
>
>
>
> admin@router1:~$ apt-cache policy bind9
>
> bind9:
>
> Installed: 1:9.21.1-1+0~20240920.124+debian12~1.gbp62e0e7
>
> Candidate: 1:9.21.1-1+0~20240920.124+debian12~1.gbp62e0e7
>
> Version table:
>
> *** 1:9.21.1-1+0~20240920.124+debian12~1.gbp62e0e7 500
>
> 500 https://packages.sury.org/bind-dev bookworm/main amd64 Packages
>
> 100 /var/lib/dpkg/status
>
> 1:9.18.28-1~deb12u2 500
>
> 500 http://deb.debian.org/debian bookworm/main amd64 Packages
>
> 500 http://security.debian.org/debian-security bookworm-security/main
> amd64 Packages
>
>
>
>
>
> admin@router1:~$ delv -v
>
> delv 9.21.1-1+0~20240920.124+debian12~1.gbp62e0e7-Debian
>
>
>
> admin@router1:~$ delv -4 @208.67.220.123 www.cdc.gov. A
>
> ;; insecurity proof failed resolving 'cdc.gov/DNSKEY/IN': 208.67.220.123#53
>
> ;; broken trust chain resolving 'www.cdc.gov/A/IN': 208.67.220.123#53
>
> ;; resolution failed: broken trust chain
>
>
>
> admin@router1:~$ delv -4 @208.67.222.123 www.cdc.gov. A
>
> ;; insecurity proof failed resolving 'cdc.gov/DNSKEY/IN': 208.67.222.123#53
>
> ;; broken trust chain resolving 'www.cdc.gov/A/IN': 208.67.222.123#53
>
> ;; resolution failed: broken trust chain
>
>
>
> admin@router1:~$ delv -4 @1.1.1.3 www.cdc.gov. A
>
> ; fully validated
>
> www.cdc.gov. 248 IN CNAME www.akam.cdc.gov.
>
> www.cdc.gov. 248 IN RRSIG CNAME 8 3 300 20241019153420
> 20241009150230 1503 cdc.gov.
> b99UIGmCOTJj+C7JFXORmtUXQEIIGdF0q3Z5u6HfAbKcJhjfFjJrkRE6
> yntzr0pSksCp1Uwi146xvKz7ImCqkYK67/WlOujyquOGSfgOwO1DvUyj
> TfvXJWvjSRLTx30lwU6RV80RrC596A16anTpLc7Zi4VEAVncRHeUl1y1 /MG/CSCtE/
> Ef6tPD1FtGZjhXszVAgrk3fhISCsImRHuGAoIBnIKCKx2M
> YMhxirfV0z9Qq46PnW9zTzh+EbVKZkN0C+Xl3j2+4sqyHlubhrtgklG/ g0u+99/g/
> jdfex+Vh7dtcAXFcTZ1XGuPQXgsn6GrznecB8PaXmCxXfft GaDOdQ==
>
> www.akam.cdc.gov. 20 IN A 23.51.224.222
>
> www.akam.cdc.gov. 20 IN RRSIG A 10 4 20 20241018102927
> 20241015092927 16701 akam.cdc.gov.
> Lcd7WthqqU+A7UwQkBHZsT0nqxztJkn9cx57wXr4eHHCvJR0cCxZFkwl
> eIbSffPIu364terXJlcEvuWbWTLrCX7bo0c6B9bA5EPi2DsbegTfkG5u
> cqrZP9RTzXbfbs5l5w6CQ9DfSPcYx9BIYkusErQu5qQnGhoQ5bXI1VxT Otc=
>
>
>
> The relevant portion of my named configuration is:
>
>
>
> tls opendns-tls {
>
> remote-hostname "dns.opendns.com";
>
> };
>
>
>
> tls cloudflare_family-tls {
>
> remote-hostname "one.one.one.one";
>
> };
>
>
>
> tls google-tls {
>
> };
>
>
>
> tls router1-tls {
>
> key-file "/var/cache/bind/privkey.pem";
>
> cert-file "/var/cache/bind/fullchain.pem";
>
> dhparam-file "/var/cache/bind/dhparam.pem";
>
> ciphers "HIGH:!kRSA:!aNULL:!eNULL:!RC4:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!
> SHA1:!SHA256:!SHA384";
>
> prefer-server-ciphers yes;
>
> session-tickets no;
>
> };
>
>
>
> options {
>
> directory "/var/cache/bind";
>
> recursion yes;
>
> allow-query { trusted_nets; };
>
> version "none";
>
>
>
> forwarders {
>
> # 1.1.1.3 port 853 tls cloudflare_family-tls;
>
> # 1.0.0.3 port 853 tls cloudflare_family-tls;
>
> 208.67.222.123 port 853 tls opendns-tls;
>
> 208.67.220.123 port 853 tls opendns-tls;
>
> # 8.8.8.8 port 853 tls google-tls;
>
> # 8.8.4.4 port 853 tls google-tls;
>
> };
>
>
>
> forward only;
>
>
>
> allow-transfer { none; };
>
>
>
> dnssec-validation auto;
>
>
>
> listen-on port 443 tls router1-tls http default { trusted_interfaces; };
>
> listen-on port 853 tls router1-tls { trusted_interfaces; };
>
> listen-on { trusted_interfaces; };
>
> listen-on-v6 { none; };
>
>
>
> zone-statistics yes ;
>
> };
>
>
>
>
>
> --
> 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
--
Robert Edmonds
--
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--
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
