Recursive Bind DNS server working in the cloud, but not in VM

I'm using ansible to bring up an identical server in the cloud, as well as in a VM (Virtualbox) on my workstation. The instance uses a non-public-facing recursive Bind DNS server to cache queries and it works great when it's out in the cloud, but it won't resolve anything when in the VM and I'm scratching my head as to why. Here's the named.conf...

# Bind9

options {
    listen-on port 53       { 127.0.0.1; 10.1/16; 10.2/16; 10.3/16; };
    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             { validated; };
    auth-nxdomain           no;
    recursion               yes;

    max-cache-size          16m;
    cleaning-interval       60;
    max-cache-ttl           3600;
    max-ncache-ttl          3600;

    version                 "";
    querylog                no;
    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";
};

acl validated {
    10.1.0.0/24;
    10.2.0.0/24;
    localhost;
    localnets;
};

controls { };

logging {
    channel default_syslog {
        syslog daemon;
        severity warning;
    };
    category default { default_syslog; };
    category unmatched { null; };
};

zone "." IN {
    type hint;
    file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

The machine IP is in the 192.168 range, and the 10... ranges in the conf file are related to a VPN running on the machine. The resolve.conf file is pointing to 127.0.0.1. Otherwise everything is pretty straightforward.

Running dig google.com results in a SERVFAIL as you can see here...

; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59078
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 84042dfe2a471323626805ee61d1e76c742ad5196cf79d37 (good)
;; QUESTION SECTION:
;google.com.                    IN      A

;; Query time: 832 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Jan 02 12:57:00 EST 2022
;; MSG SIZE  rcvd: 67

My inkling is that this is related to Virtualbox as the same config works in the cloud. Is Vbox somehow intercepting DNS requests and not providing the right response? I'm using Bridge networking though, so my understanding was that ALL traffic is routed to the network as if this is a standalone instance, is that not the case?

Not sure if it points to anything but when I run systemctl status named on the cloud machine everything looks good, but when I run it on the VM I'm seeing errors...

... managed-keys-zone: No valid trust anchors for '.'!
... managed-keys-zone: 0 key(s) revoked, 1 still pending
... managed-keys-zone: All queries to '.' will fail

I'm not sure where to begin to diagnose, appreciate any help you can offer!

So after more investigation, it seems that BIND/named will try IPv6 first if it's configured to do so and then fail completely if it's not accessible, rather than trying IPv4 at all.

In my case, the VM on workstation does not have IPv6 connectivity simply because my current ISP doesn't support IPv6 yet... yes, in 2022, ugh. So by doing the following, you should be able to get your DNS resolution back online.

In /etc/sysconfig/named, add...

OPTIONS="-4"

In /etc/named.conf, add...

filter-aaaa-on-v4          yes;

... and comment out the following if it exists

// listen-on-v6 port 53    { ::1; };

Finally, restart named with systemctl restart named. This worked for me, hopefully it helps you. Cheers!