Короткий ответ — причин несколько. Самое частое: либо зона вообще не подписана/подписана с ошибкой (ошибка делегации DS/DNSKEY/ RRSIG), либо ваш резолвер не может корректно получить/передать DNSSEC-ответы из‑за блокировок/фильтрации/обрыва TCP/EDNS/MTU/времени. Ниже — конкретно что проверить и как диагностировать.
Возможные причины
- Зона не подписана (или родительская зона содержит DS, а в самой зоне нет корректного DNSKEY → валидатор вернёт SERVFAIL).
- Неправильные/истёкшие RRSIG (неверная подпись у авторитативных серверов).
- Фильтрация EDNS0 / обрезка UDP — большие DNSSEC-ответы обрезаются и TCP‑fallback не срабатывает.
- Блокировка/ограничение TCP порт 53 (а для DNSSEC часто нужен TCP).
- Проблемы с MTU/фрагментацией (UDP+DNSSEC > 512 байт).
- Неправильное время в контейнере (подписи валидируются по времени).
- Отсутствие/неверный trust anchor (кто‑то удалил/испортил корневой ключ в настройках резолвера).
- Баг/ограничение самого Technitium (маловероятно, но возможно) или сетевые ограничения LXC/Proxmox.
Что выполнить прямо сейчас (в контейнере)
1) Посмотреть обычный и DNSSEC‑ответы от вашего резолвера:
dig +dnssec ya.ru @127.0.0.1
dig +nocmd +noall +answer +authority +additional +dnssec ya.ru @127.0.0.1
Обратите внимание на статус (NOERROR / SERVFAIL), наличие RRSIG в ANSWER/AD флаг.
2) Прогнать трассировку (чтобы увидеть где ломается делегация):
dig +trace ya.ru
3) Сравнить с публичным резолвером (чтобы понять, проблема у вас или у зоны):
dig +dnssec ya.ru @8.8.8.8
dig +dnssec ya.ru @1.1.1.1
4) Проверить DS в зоне верхнего уровня (TLD) и DNSKEY у авторитативных серверов:
dig +short DS ya.ru @a.gtld-servers.net
dig +dnssec DNSKEY ya.ru @<authoritative_ns_ip>
5) Попробовать через TCP (проблема с UDP/EDNS/фрагментацией):
dig +tcp +dnssec ya.ru @127.0.0.1
6) Проверить время в контейнере:
date
timedatectl status
Если время неверное — настроить NTP/chrony/systemd‑timesyncd.
7) Посмотреть логи Technitium / включить отладку DNSSEC в настройках Technitium и смотреть ошибки (validation failed, SERVFAIL cause и т.п.).
8) Наблюдать трафик, чтобы увидеть ответы/отрезанные пакеты:
tcpdump -n -s0 -w /tmp/dns.pcap port 53
или
tcpdump -n -A port 53 and host <authoritative_ip>
Что означают результаты
- Если публичные резолверы (Google/Cloudflare) возвращают NOERROR, а ваш резолвер — SERVFAIL: проблема в вашем резолвере/сети/конфиге (time, trust anchor, EDNS/TCP).
- Если все резолверы возвращают SERVFAIL: проблема на стороне домена (ошибка делегации/подписи).
- Если через TCP работает, а через UDP нет: скорее всего EDNS0/MTU/фрагментация/файрвол.
- Если в dig +dnssec видно DS в родителе, но нет DNSKEY в зоне — это явная причина валидатора возвращать ошибку.
Специфично для LXC/Proxmox
- Проверьте, не блокирует ли хост исходящий TCP/53/UDP(large) для контейнера.
- Некоторые Proxmox/Firewall правила/OVS могут рушить фрагментацию/EDNS. Попробуйте временно отключить firewall на хосте/контейнере и проверить.
Если хотите, пришлите выводы этих команд:
- dig +dnssec ya.ru @127.0.0.1
- dig +trace ya.ru
- dig +dnssec ya.ru @8.8.8.8
- date
Я посмотрю вывод и подскажу точную причину и решение.