DNS-сервер Recursive Bind работает в облаке, но не в виртуальной машине

Я использую ansible для запуска идентичного сервера в облаке, а также в виртуальной машине (Virtualbox) на моей рабочей станции. Экземпляр использует закрытый рекурсивный DNS-сервер Bind для кэширования запросов, и он отлично работает, когда находится в облаке, но ничего не решит, когда находится в виртуальной машине, и я ломаю голову над тем, почему. Вот named.conf...

# Bind9

параметры {
    порт прослушивания 53 { 127.0.0.1; 10.1/16; 10,2/16; 10,3/16; };
    прослушивание на v6, порт 53 { :: 1; };
    директория "/var/named";
    дамп-файл "/var/named/data/cache_dump.db";
    файл статистики "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    файл-secroots "/var/named/data/named.secroots";
    рекурсивный-файл "/var/named/data/named.recursing";
    разрешить запрос {проверено; };
    auth-nxdomain нет;
    рекурсия да;

    максимальный размер кэша 16 м;
    интервал очистки 60;
    максимальный кеш-ttl 3600;
    макс-ncache-ttl 3600;

    версия "";
    № журнала запросов;
    dnssec-включить да;
    dnssec-валидация да;
    каталог управляемых ключей "/var/named/dynamic";
    pid-файл "/run/named/named.pid";
    ключевой файл сеанса "/run/named/session.key";
    включить "/etc/crypto-policies/back-ends/bind.config";
};

ACL подтвержден {
    10.1.0.0/24;
    10.2.0.0/24;
    локальный хост;
    локальные сети;
};

контролирует { };

Ведение журнала {
    канал default_syslog {
        демон системного журнала;
        предупреждение серьезности;
    };
    категория по умолчанию { default_syslog; };
    категория не имеет себе равных { ноль; };
};

зона "." В {
    тип подсказки;
    файл "named.ca";
};

включить "/etc/named.rfc1912.zones";
включить "/etc/named.root.key";

IP-адрес машины находится в диапазоне 192.168, а диапазоны 10... в файле conf связаны с VPN, работающей на машине. разрешение.conf файл указывает на 127.0.0.1. В остальном все довольно просто.

Бег копать google.com приводит к SERVFAIL как вы можете видеть здесь...

; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> google.com
;; глобальные параметры: +cmd
;; Получил ответ:
;; ->>HEADER<<- код операции: QUERY, статус: SERVFAIL, id: 59078
;; флаги: qr rd ra; ЗАПРОС: 1, ОТВЕТ: 0, АВТОРИЗАЦИЯ: 0, ДОПОЛНИТЕЛЬНО: 1

;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ:
; ЭДНС: версия: 0, флаги:; УДП: 1232
; COOKIE: 84042dfe2a471323626805ee61d1e76c742ad5196cf79d37 (хорошо)
;; РАЗДЕЛ ВОПРОСОВ:
;google.com. В

;; Время запроса: 832 мс
;; СЕРВЕР: 127.0.0.1#53(127.0.0.1)
;; КОГДА: воскресенье, 2 января, 12:57:00 по восточному поясному времени 2022 г.
;; РАЗМЕР MSG rcvd: 67

Я предполагаю, что это связано с Virtualbox, поскольку та же конфигурация работает в облаке. Vbox каким-то образом перехватывает DNS-запросы и не дает правильного ответа? Однако я использую сеть Bridge, поэтому, как я понимаю, ВЕСЬ трафик направляется в сеть, как если бы это был автономный экземпляр, не так ли?

Не уверен, указывает ли это на что-либо, но когда я бегу статус systemctl с именем на облачной машине все выглядит хорошо, но когда я запускаю ее на виртуальной машине, я вижу ошибки...

... зона управляемых ключей: нет допустимых якорей доверия для «.»!
... зона управляемых ключей: 0 ключей отозвано, 1 все еще находится на рассмотрении
... зона управляемых ключей: все запросы к '.' не удастся

Я не знаю, с чего начать диагностику, буду признателен за любую помощь, которую вы можете предложить!

Таким образом, после дополнительного расследования кажется, что BIND/named сначала попытается использовать IPv6, если он настроен для этого, а затем полностью потерпит неудачу, если он недоступен, вместо того, чтобы вообще пытаться использовать IPv4.

В моем случае виртуальная машина на рабочей станции не имеет подключения к IPv6 просто потому, что мой текущий интернет-провайдер еще не поддерживает IPv6... да, в 2022 году, тьфу. Таким образом, выполнив следующие действия, вы сможете восстановить разрешение DNS в сети.

В /etc/sysconfig/имя, Добавлять...

ВАРИАНТЫ="-4"

В /etc/named.conf, Добавлять...

фильтр-аааа-на-v4 да;

... и закомментируйте следующее, если оно существует

// прослушивание порта v6 53 { ::1; };

Наконец, перезапустите названный с имя перезапуска systemctl. Это сработало для меня, надеюсь, это поможет вам. Ваше здоровье!