1

I've recently stood up a new DNS server using Bind (v9.18.28-1) and I'm getting repeating blocks of errors in my "general" log file:

02-Oct-2024 09:49:09.723 resolver: DNS format error from 2001:7fe::53#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.755 resolver: DNS format error from 2001:dc3::35#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.787 resolver: DNS format error from 2001:500:2f::f#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.819 resolver: DNS format error from 2001:500:12::d0d#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.851 resolver: DNS format error from 2001:503:c27::2:30#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.883 resolver: DNS format error from 2001:500:2::c#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.919 resolver: DNS format error from 2001:500:2d::d#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.951 resolver: DNS format error from 2001:7fd::1#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:09.991 resolver: DNS format error from 2001:500:9f::42#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.027 resolver: DNS format error from 2801:1b8:10::b#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.059 resolver: DNS format error from 2001:500:a8::e#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.095 resolver: DNS format error from 2001:500:1::53#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.127 resolver: DNS format error from 2001:503:ba3e::2:30#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.163 resolver: DNS format error from 192.36.148.17#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.183 resolver: DNS format error from 202.12.27.33#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.207 resolver: DNS format error from 192.5.5.241#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.227 resolver: DNS format error from 192.112.36.4#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.251 resolver: DNS format error from 192.58.128.30#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.275 resolver: DNS format error from 192.33.4.12#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.299 resolver: DNS format error from 199.7.91.13#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.323 resolver: DNS format error from 193.0.14.129#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.347 resolver: DNS format error from 199.7.83.42#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.371 resolver: DNS format error from 170.247.170.2#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.395 resolver: DNS format error from 192.203.230.10#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.423 resolver: DNS format error from 198.97.190.53#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.447 resolver: DNS format error from 198.41.0.4#53 resolving ./NS for <unknown>: non-improving referral
02-Oct-2024 09:49:10.447 resolver: resolver priming query complete: failure

It appears that these are all of the root name servers I've got listed in the /usr/share/dns/root.hints file.

This file is referenced via this zone block in my named configuration file:

// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/usr/share/dns/root.hints";
};

Here's the options that I've got set:

options {
        directory "/var/cache/bind";

        allow-query {
                any;
        };

        forwarders {
          1.1.1.1;
        };

        allow-recursion {
              xx.xx.xx.xx/29;
              //10.0.0.0/8;
              10.1.0.0/16;
        };
        // hide version #
        version "unknown";


        dnssec-validation auto;


};

Any idea as to what is causing these format errors and is there anything I can do about it?

Thanks folks!

Improve this question

1 Answer 1

Reset to default
2

It sounds like something (your firewall, or your ISP's firewall, etc) is intercepting all your DNS queries and redirecting them to another resolver.

Run dig . ns @a.root-servers.net. You should see:

  1. aa flag in the header (the "root" servers are authoritative for .),
  2. no ra flag (the "root" servers never offer recursive service),
  3. no ad flag (authoritative servers don't DNSSEC validate their own data),
  4. "recursion requested but not available", and most importantly
  5. an 'ADDITIONAL SECTION' that contains A/AAAA records for the nameservers.

If the results look different than what's listed above, then your query was most likely redirected to a different server.

To investigate further, run:

  • dig +short hostname.bind CH TXT @a.root-servers.net
  • dig +short version.bind CH TXT @a.root-servers.net

Repeat for each of {a..m}.root-servers.net. You should get different results for every server (B-root runs "knot 3.x", D-root runs "NSD 4", etc). If the results are identical, it means all the queries were redirected, and the reported hostname might hint towards the owner of the bad server, if they forgot to hide it.

Sometimes DNS interception is only set up for UDP but not TCP (even though all servers support both), so dig +vc <query> @<server> might bypass it. Additionally the B-root supports DNS-over-TLS, so you can try dig +tls <query> @b.root-servers.net and compare the result against what you get "normally".

Since your BIND seems to be configured to always rely on forwarding queries to 1.1.1.1 (instead of being a standalone resolver), you can shut up the messages by removing the entire zone "." definition.

Improve this answer
7
  • The forwards option is present because it won't resolve anything without it - which I suspect is directly related to the inability to reach the root servers. I'll turn that off and try your suggestions above. Thank you! (I'll comment again later with the results.) Commented Oct 4, 2024 at 13:26
  • - With the forwarder turned off, a.root-servers.net doesn't resolve at all. I expected that. When I query via ip (or via hostname after re-enabling forwarding), I get this: flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27. Is it safe to assume that both the presence of "ra" and the lack of "aa" flags indicate that something is intercepting the request? Commented Oct 4, 2024 at 14:29
  • Yes, because you're querying a server authoritative for that zone (root servers are authoritative for .) so you're always supposed to get an aa authoritative answer back (and such an answer would not have the ad flag) – without that flag, you're definitely talking to something else. (And although there exist some DNS servers that do both authoritative + recursive roles, the "root" servers never offer recursive service so ra would never be set in their answers.) Commented Oct 4, 2024 at 14:40
  • 1
    I appreciate the info @u1686_grawity. It looks like I get to have a really ugly conversation with Comcast. I suspect they've been pulling this crap for years and I simply didn't notice because I wasn't watching my DNS server logs that closely. I rebuilt my name servers a couple of weeks ago and started seeing these issues. (I've got a "business" account with static ip addresses, and they've got no forking business screwing around with my traffic.) Commented Oct 4, 2024 at 15:12
  • 1
    This was the exact problem. As soon as they turned it off. the resolver priming operation succeeded. Thanks again for your help! Commented Oct 4, 2024 at 15:40

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.