Скажите привязке игнорировать проверку домена SOA в зонах пересылки

У меня странная проблема с bind.

Предпосылка: я использую привязку (версия 9.16_11), установленную на pfSense, но, несмотря на это, я могу изменить почти все в конфигурации привязки.

Я настроил простую зону переадресации, конфигурация примерно такая:

зона "dom001.my-domain.com" {
        введите вперед;
        только вперед;
        экспедиторы { 192.168.29.10; };
};

Теперь, если я попытаюсь выполнить nslookup для хоста в этом домене, я увижу ошибку. Пример:

Неавторитетный ответ:
Имя: mail2.dom001.my-domain.com
Адрес: 192.168.210.126
** сервер не может найти mail2.dom001.my-domain.com: SERVFAIL

Странно то, что ответ получен (адрес можно увидеть в ответе), но, несмотря на это, я вижу ошибку SERVFAIL.

Другая странная вещь, dig не сообщает об ошибке:

; <<>> DiG 9.16.6 <<>> mail2.dom001.my-domain.com
;; глобальные параметры: +cmd
;; Получил ответ:
;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 53129
;; флаги: qr rd ra; ЗАПРОС: 1, ОТВЕТ: 1, ПОЛНОМОЧИЯ: 0, ДОПОЛНИТЕЛЬНО: 1

;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ:
; ЭДНС: версия: 0, флаги:; UDP: 4096
; COOKIE: 3218b8a1b8f64565eb9bd6636124bf73640809a4347f3bcf (хорошо)
;; РАЗДЕЛ ВОПРОСОВ:
;mail2.dom001.мой-домен.com. В

;; РАЗДЕЛ ОТВЕТОВ:
mail2.dom001.мой-домен.com. 30 В А 192.168.210.126

;; Время запроса: 30 мс
;; СЕРВЕР: 172.16.0.2#53(172.16.0.2)
;; КОГДА: вторник, 24 августа, 11:44:19 по центральноевропейскому летнему времени 2021 г.
;; РАЗМЕР MSG rcvd: 110

Во время этих запросов я вижу некоторые «предупреждения» в журналах привязки:

24 августа, 10:42:58, названо 19540 хромых серверов: информация: FORMERR разрешает 'mail2.dom001.my-domain.com/AAAA/IN': 192.168.29.10#53
24 августа 10:42:58 названный преобразователь 19540: уведомление: ошибка формата DNS от 192.168.29.10#53 при разрешении mail2.dom001.my-domain.com/AAAA для клиента 10.16.16.41#38299: Имя cluster.local (SOA) не поддомен зоны dom001.my-domain.com -- неверный ответ

Я проверил дальше, и кажется, что проблема связана с записями SOA на сервере пересылки:

;; РАЗДЕЛ ВОПРОСОВ:
;mail2.dom001.мой-домен.com. В СОА

;; РАЗДЕЛ ОТВЕТОВ:
кластер.локальный. 30 В SOA ns.dns.cluster.local. хостмастер.кластер.локальный. 1629766398 7200 1800 86400 30

На самом деле ответ кластер.локальный вместо dom001.мой-домен.com.

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

И даже с сервером, который работает нормально, у меня есть журналы привязки, полные ошибок из-за этой проблемы.

К сожалению, я не могу управлять сервером пересылки и изменять запись SOA.

Мой вопрос: как я могу настроить привязку, чтобы игнорировать запись SOA этого сервера пересылки и принимать ответ, даже если SOA не является коэрентным?

Я знаю, что это не лучшее решение, но мне нужно обойти неправильно настроенный сервер пересылки.

Заранее спасибо за помощь!

Я не верю, что в BIND есть какие-либо параметры, которые заставят его принять этот ответ, поскольку он кажется не связанным с запросом.
Увидеть такой непоследовательный ответ определенно не ожидается, и я думаю, что если вы действительно хотите (временно?) принять и передать эти ответы (конечно, клиентам они тоже могут не понравиться), вам, возможно, придется взглянуть на другое программное обеспечение, которое не заботится о содержании ответа таким же образом.
(Я подозреваю, что dnsdist, будучи прокси, а не рекурсором, может сделать это за вас.)

Тем не менее, я думаю, что могу немного прояснить некоторую путаницу...

нслукап ситуация основана на том, как нслукап по умолчанию отправляет два отдельных запроса, один для А и один для АААА.
А запрос выполнен успешно и явно имел релевантное значение А запишите в качестве ответа, АААА запрос не удался, предположительно не было АААА запись, и поскольку отрицательные ответы всегда сопровождаются (предположительно) соответствующими СОА запись, которая, вероятно, вызывает именно ту проблему, которую вы описали.

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

Что касается поведения другого сервера имён, то это не совсем «редактирование СОА", это скорее какая-то логическая ошибка в программном обеспечении сервера имен. На самом деле не должно быть возможности найти кластер.локальный запись при поиске mail2.dom001.мой-домен.com, то есть в совершенно другой ветви дерева.