BIND server has tons of "no valid RRSIG" errors

Question

I have a forward-only BIND9 server running on the LAN and it logs hundreds of errors per day like:

Aug 29 18:38:29 nuc named[850]: error (no valid RRSIG) resolving 'ubuntu.com/DS/IN': 75.75.75.75#53
Aug 29 18:38:31 nuc named[850]:   validating @0x7fc6d826ed50: com SOA: got insecure response; parent indicates it should be secure
Aug 29 18:38:31 nuc named[850]: error (no valid RRSIG) resolving 'medium.com/DS/IN': 75.75.75.75#53
Aug 29 18:38:31 nuc named[850]:   validating @0x7fc6d4014b80: com SOA: got insecure response; parent indicates it should be secure

It appears clients are still getting results, but these messages are filling up the logs. Relevant lines in named.conf:

    forwarders {
            # Comcast
            2001:558:feed::1;
            2001:558:feed::2;
            75.75.75.75;
            75.75.76.76;
    };
    forward only;

    dnssec-enable yes;
    dnssec-validation auto;
    dnssec-lookaside auto;

What do these errors really mean is happening? Is this a misconfiguration on my end or Comcast's?

Solution 1

It looks like Comcast's servers are deliberately stripping out DNSSEC signatures from the responses they're giving you, so your server cannot validate com. (in this case) even though it knows that one should be signed. This is unlikely to cause any directly noticeable problems, it just leaves you and your users wide open for all the attacks that DNSSEC was created to protect against.

Exactly why Comcast want to reduce your level of security you will have to ask them.

Solution 2

I got the similar errors in /var/log/syslog

no valid RRSIG resolving and broken trust chain resolving

After adding the following params in /etc/bind/named.conf/options, the problem is gone

dnssec-enable yes;
dnssec-validation yes;

Solution 3

Using Bind 9.9 on my old Ubuntu server in the file /etc/bind/named.conf.options the parameter

dnssec-validation auto;

has been set by default.

The last three or four years I received tons of error messages like:

named[2308]: validating @0x7fd77c00ffc0: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf.
named[2308]: error (no valid KEY) resolving './DNSKEY/IN': 199.7.83.42#53
named[2308]: validating @0x7fd780022e80: . DNSKEY: unable to find a DNSKEY which verifies the DNSKEY RRset and also matches a trusted key for '.'

After three or four years of friggling around with the bind configurations and keys, looking at every reachable resource dealing with isc bind at least adding / changing the parameters to

dnssec-enable yes;
dnssec-validation yes;

solved my problem with these tons of errors.

Comments

[Tilman Schmidt]

One way of fixing this is to drop the forwarders configuration entirely, allowing your BIND9 server to resolve directly from the authoritative servers instead of going through the Comcast name servers.

[Rick Buford]

I would suspect that they'd stripping because of the additional overhead and because there aren't a great many servers doing proper validation yet. So, while there's a fair number of servers offering DNSSEC responses, unless you're dealing with something that requires it, it's a lot more load on the LDNS.

[Admin]

according to the documentation here bind9.readthedocs.io/en/v9_16_6/reference.html this disables dnssec-validation if trust-anchors is not set. Does anyone know how secure this is without a trust-anchor?