8

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?

chicks
  • 3,915
  • 10
  • 29
  • 37
jmw
  • 83
  • 1
  • 1
  • 3

3 Answers3

10

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.

Andrew Schulman
  • 9,142
Wiki59_1
  • 101
8

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;
j3ffyang
  • 181
  • 1
  • 4
8

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.

Calle Dybedahl
  • 2,193