When running a forward-only BIND9 server with DNSSEC validation enabled, you might encounter persistent "no valid RRSIG" errors in your logs. This occurs when your resolver attempts to validate DNSSEC-signed records but encounters inconsistencies in the validation chain.

The error messages indicate two distinct but related problems:

1. No valid RRSIG for the requested record
2. Insecure response from parent zone despite DNSSEC expectation

This typically happens when:

• Your forwarders don't properly support DNSSEC validation
• There's a mismatch between DNSSEC-aware and non-DNSSEC-aware resolvers
• The upstream servers provide inconsistent responses

The current configuration shows:

options {
    forwarders {
        2001:558:feed::1;  # Comcast IPv6
        2001:558:feed::2;
        75.75.75.75;       # Comcast IPv4
        75.75.76.76;
    };
    forward only;
    
    dnssec-enable yes;
    dnssec-validation auto;
    dnssec-lookaside auto;
};

Option 1: Disable DNSSEC validation for forwarding

dnssec-validation no;

Option 2: Use DNSSEC-aware forwarders

forwarders {
    9.9.9.9;           # Quad9 (supports DNSSEC)
    1.1.1.1;           # Cloudflare DNS
    2606:4700:4700::1111;
};

Option 3: Hybrid approach

dnssec-validation yes;
dnssec-lookaside no;

# Whitelist problematic domains
validate-except {
    "com";
    "net";
    "org";
};

To investigate specific domains:

dig +dnssec ubuntu.com @75.75.75.75
delv @75.75.75.75 ubuntu.com
dnssec-verify -v ubuntu.com

When dealing with validation errors, consider these performance impacts:

• Each failed validation attempt adds 1-2 seconds latency
• BIND will retry validation with different forwarders
• Cached failures still trigger validation attempts

To reduce log noise while maintaining visibility:

logging {
    channel security_log {
        file "/var/log/named/security.log" versions 5 size 10m;
        severity debug;
        print-time yes;
        print-severity yes;
        print-category yes;
    };
    category security {
        security_log;
    };
    category dnssec {
        security_log;
    };
};

---

When your BIND9 server logs messages like error (no valid RRSIG) resolving and got insecure response; parent indicates it should be secure, it's indicating DNSSEC validation failures. These occur when:

• The upstream resolver (in this case, Comcast's servers) isn't properly signing responses
• The DNSSEC chain of trust is broken somewhere in the resolution path
• Your local configuration expects validation but isn't receiving valid signatures

Looking at your configuration, there are several noteworthy points:

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

This combination tells BIND to:

1. Enable DNSSEC processing
2. Automatically validate DNSSEC records
3. Use the (now deprecated) DLV (DNSSEC Lookaside Validation) as fallback

For a forward-only resolver, you have two main approaches:

Option 1: Disable DNSSEC Validation

options {
    dnssec-validation no;
    dnssec-enable no;
    forwarders {
        2001:558:feed::1;
        2001:558:feed::2;
        75.75.75.75;
        75.75.76.76;
    };
    forward only;
};

Option 2: Use Secure Forwarders

Switch to public DNS providers that properly support DNSSEC:

forwarders {
    // Cloudflare
    1.1.1.1;
    1.0.0.1;
    2606:4700:4700::1111;
    2606:4700:4700::1001;
    
    // Google
    8.8.8.8;
    8.8.4.4;
    2001:4860:4860::8888;
    2001:4860:4860::8844;
};

For more control, you can configure validation exceptions:

options {
    dnssec-validation yes;
    validate-except {
        "com";
        "net";
    };
};

Use these commands to verify your DNSSEC configuration:

# Check DNSSEC validation status
dig +dnssec @127.0.0.1 example.com SOA

# Trace validation chain
delv @127.0.0.1 example.com

# Check specific record validation
dig +sigchase @127.0.0.1 example.com A

Remember to check your logs after changes with:

tail -f /var/log/named.log | grep -E 'RRSIG|validation'