DNSSEC auto signing and file handling

The forwarders that you have configured will only cause problems when running a validating resolver as the Opendns servers do not cooperate when doing DNSSEC validation.

I suppose it might mostly work anyway for you as you didn't specify forward only, so named will fall back to resolving things on its own more or less all the time as the forwarders keep failing to produce useful results. But even if it sort of works it will still make a complete mess of your logs.

To demonstrate, if I set forward only and use those same forwarders this is what happens:

named[20057]: error (no valid RRSIG) resolving 'net/DS/IN': 208.67.220.220#53
named[20057]: error (no valid RRSIG) resolving 'net/DS/IN': 208.67.222.222#53
named[20057]: error (no valid DS) resolving 'sigfail.verteiltesysteme.net/A/IN': 208.67.222.222#53
named[20057]: validating @0x7f36805ecb10: sigfail.verteiltesysteme.net A: bad cache hit (net/DS)
named[20057]: error (broken trust chain) resolving 'sigfail.verteiltesysteme.net/A/IN': 208.67.220.2

As you can see, it fails but for entirely the wrong reason. (It failed at the DS for net, not when validating the actually broken signatures at sigfail.verteiltesysteme.net.)

I expect your logs are currently a mix of stuff like the above combined with actually relevant entries from when named falls back to querying properly working servers. Fixing this ought to help troubleshooting.

As for the inconsistent results, I'm not sure that anything in your configuration can really explain that. Are you positive that it's actually that same named instance that answered the query? No strange NAT rules or something like that which would cause clients to transparently talk to some different server or whatnot?

Queries like dig @192.168.10.36 version.bind CH TXT and dig @192.168.10.36 hostname.bind CH TXT could expose such a thing going on.

I think I finally found the root cause of my problem. I have two views, that were configured to include the same master zone file twice.

You cannot use the same file for two zones. So this is invalid and caused my problem:

view "internal" {
    match-clients ...;
    zone "example.com" {
        type master;
        file "/etc/bind/zones/example.net";
    };
};
view "external" {
    match-clients ...;
    zone "example.com" {
        type master;
        file "/etc/bind/zones/example.net";
    };
};

The proper way to share a zone is described in chapter 4 of the " Understanding views in BIND 9, by example" guide. Basically, only one of the zone must be the master zone, and the other one must be a slave. After adding a few acls, keys and also-notify for localhost in the right places, I got rid of those errors.

In the end this is my final configuration:

key "internal" {
    // TSIG Key generated with dnssec-keygen -a HMAC-MD5 -b 512 -n USER internal
    algorithm hmac-md5;
    secret "XXXX";
};

view "internal" {
    match-clients { key internal; ...IPs...; }; // our network
    zone "robin.info" {
        type slave;
        file "/etc/bind/slave-zones/robin.info"; // Not the same file as external view!
        masters { 127.0.0.1; };
    };
};

view "external" {
    match-clients { !key internal; "any"; }; // everyone else
    server 127.0.0.1 {
        /* Deliver notify messages to internal view with internal key. */
        keys { internal; };
    };
    zone "robin.info" {
        type master;
        file "/etc/bind/zones/robin.info";
        // ACL file with allow-transfer and also-notify
        // including secondary DNS servers and 127.0.0.1
        include "/etc/bind/acls"; 
        key-directory "/etc/bind/dnssec/robin.info/2017";
        inline-signing yes;
        auto-dnssec maintain;
    };
};