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