Я имею вперед только сервер BIND9, работающий на LAN, и это регистрирует сотни ошибок в день как:
Aug 29 18:38:29 nuc named[850]: error (no valid RRSIG) resolving 'ubuntu.com/DS/IN': 75.75.75.75#53
Aug 29 18:38:31 nuc named[850]: validating @0x7fc6d826ed50: com SOA: got insecure response; parent indicates it should be secure
Aug 29 18:38:31 nuc named[850]: error (no valid RRSIG) resolving 'medium.com/DS/IN': 75.75.75.75#53
Aug 29 18:38:31 nuc named[850]: validating @0x7fc6d4014b80: com SOA: got insecure response; parent indicates it should be secure
Кажется, что клиенты все еще получают результаты, но эти сообщения заполняют журналы. Соответствующие строки в named.conf
:
forwarders {
# Comcast
2001:558:feed::1;
2001:558:feed::2;
75.75.75.75;
75.75.76.76;
};
forward only;
dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside auto;
То, что делает эти ошибки действительно означают, происходит? Действительно ли это - неверная конфигурация на моем конце или Comcast?
Похоже, серверы Comcast намеренно удаляют подписи DNSSEC из ответов, которые они вам дают, поэтому ваш сервер не может проверить com.
(в данном случае), даже если он знает, что нужно подписать. Это вряд ли вызовет какие-либо непосредственно заметные проблемы, это просто оставляет вас и ваших пользователей широко открытыми для всех атак, от которых был создан DNSSEC.
Вы должны спросить их, почему именно Comcast хочет снизить уровень вашей безопасности. .
Я получил аналогичные ошибки в /var/log/syslog
нет действительного разрешения RRSIG
и разрешение нарушенной цепочки доверия
После добавления следующих параметров в /etc /bind/named.conf/options
, проблема ушла
dnssec-enable yes;
dnssec-validation yes;
При использовании Bind 9.9 на моем старом сервере Ubuntu в файле /etc/bind/named.conf.options параметр
dnssec-validation auto;
был установлен по умолчанию.
За последние три или четыре года я получил множество сообщений об ошибках, таких как:
named[2308]: validating @0x7fd77c00ffc0: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf.
named[2308]: error (no valid KEY) resolving './DNSKEY/IN': 199.7.83.42#53
named[2308]: validating @0x7fd780022e80: . DNSKEY: unable to find a DNSKEY which verifies the DNSKEY RRset and also matches a trusted key for '.'
После трех или четырех лет возни с конфигурациями и ключами привязки, просматривая каждый доступный ресурс, связанный с привязкой isc, по крайней мере добавляя/изменяя параметры
dnssec-enable yes;
dnssec-validation yes;
решили мою проблему с этими тоннами ошибок.