Problems with caching server that forwards to an internal split-brain authoritative server

[Mark Andrews]

> On 11 Mar 2022, at 12:16, Joseph L. Casale <jcasale at gmail.com> wrote:
> 
> I am trying to replicate a working configuration on an older host
> that has a caching server that forwards to an Active Directory DNS
> server at 172.18.0.2 that is part of a split-brain setup with a public
> copy of its zone hosted with Goggle.
> 
> When I attempt to resolve a record on the new caching server, it works
> fine only if the record is not part of the zone hosted by the Active Directory
> server. For example, `dig lists.isc.org` works fine.
> 
> When I attempt to resolve a record in the zone hosted on the forwarder, it
> fails with SERVFAIL and I get the following errors in the logs:
> 
> named[1158]: chase DS servers resolving 'example.com/DS/IN': 172.18.0.2#53
> named[1158]: no valid DS resolving 'name.example.com/A/IN': 172.18.0.2#53
> 
> The configuration I am using is shown below, any ideas as to what I am overlooking?

To answer your question about what you are overlooking the answer is “DNSSEC”.

With DNSSEC *every* time you create a new zone you *must* delegate it in the
parent zone if it is signed.  Delegation is actually a requirement from RFC
1034 but you can’t always see a missing delegation if you are not doing DNSSEC.
You can’t get away with the bad practice of having the parent and child zones
on the same server without delegating NS record or with using a forward zone
instead of a delegation.

DNSSEC requires signed answers for DS queries from the parent zone that say
one of the following:
1) there is a DS RRset here and also here are the RRSIGs that prove that the
   answer hasn’t been tampered with (secure delegation, child zone is signed)
2) there isn’t a DS RRSet but there is a delegation NSEC / NSEC3 + RRSIGs
   (insecure delegation, child zone is not signed or signed but not yet securely
   delegated)
3) there isn’t a DS RRset and there isn’t a delegation NSEC / NSEC3 + RRSIGs

Only type 1 and 2 answers are valid for introducing a new zone.  If you don’t
add the delegating NS records you get type 3 answers instead of type 2 answers
and validation of names from the “child” zone will fail as that parent zone
says that it doesn’t exist.

> options {
>   listen-on port 53 { 127.0.0.1; };
>   listen-on-v6 port 53 { ::1; };
>   directory "/var/named";
>   dump-file "/var/named/data/cache_dump.db";
>   statistics-file "/var/named/data/named_stats.txt";
>   memstatistics-file "/var/named/data/named_mem_stats.txt";
>   secroots-file "/var/named/data/named.secroots";
>   recursing-file "/var/named/data/named.recursing";
>   allow-query     { localhost; };
>   recursion yes;
>   forward only;
>   forwarders {
>     172.18.0.2;
>   };
>   dnssec-enable yes;
>   dnssec-validation yes;
>   managed-keys-directory "/var/named/dynamic";
>   pid-file "/run/named/named.pid";
>   session-keyfile "/run/named/session.key";
>   include "/etc/crypto-policies/back-ends/bind.config";
> };
> logging {
>     channel default_debug {
>     file "data/named.run";
>     severity dynamic;
>   };
> };
> zone "." IN {
>   type hint;
>   file "named.ca";
> };
> include "/etc/named.rfc1912.zones";
> include "/etc/named.root.key";
> 
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org