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

Reply via email to