Я запускаю локальную установку Debian 8.1 с DNS-Resolver, проверяющим DNSSEC, который называется dnsmasq (версия 2.72-3+deb8u1).
Я настроил его, чтобы вернуть SERVFAIL если он не может проверить домен с поддержкой DNSSEC, т. е. если в домене есть запись DNSSEC, он должен пройти правильную проверку, чтобы быть перенаправленным клиенту.
Пока я просматривал сегодня, я хотел посетить довольно известный сайт IETF но я не мог, потому что домен не мог быть разрешен. Я проверил это с помощью командной строки и действительно получил SERVFAIL. Я проверил DNS-сервер Google (8.8.8.8) и не получил SERVFAIL а вот IP-адрес.
После этого я включил ведение журнала для каждого запроса DNS и проверил результаты. Похоже, мое мнение было правильным, и проверка DNSSEC не удалась, даже несмотря на то, что он получил такой же ответ от серверов пересылки DNS, как я получил от Google.
Вот соответствующие строчки моего syslog:
Sep 5 13:27:13 dnsmasq: query[A] www.ietf.org from 192.168.1.10
Sep 5 13:27:13 dnsmasq: forwarded www.ietf.org to 81.3.21.188
Sep 5 13:27:13 dnsmasq: forwarded www.ietf.org to 178.63.73.246
Sep 5 13:27:13 dnsmasq: dnssec-query[DNSKEY] ietf.org to 81.3.21.188
Sep 5 13:27:13 dnsmasq: dnssec-query[DS] ietf.org to 81.3.21.188
Sep 5 13:27:13 dnsmasq: dnssec-query[DNSKEY] org to 81.3.21.188
Sep 5 13:27:13 dnsmasq: dnssec-query[DS] org to 81.3.21.188
Sep 5 13:27:13 dnsmasq: dnssec-query[DNSKEY] . to 81.3.21.188
Sep 5 13:27:13 dnsmasq: reply . is DNSKEY keytag 1518
Sep 5 13:27:13 dnsmasq: reply . is DNSKEY keytag 19036
Sep 5 13:27:13 dnsmasq: reply org is DS keytag 21366
Sep 5 13:27:13 dnsmasq: reply org is DS keytag 21366
Sep 5 13:27:13 dnsmasq: reply org is DNSKEY keytag 19629
Sep 5 13:27:13 dnsmasq: reply org is DNSKEY keytag 21366
Sep 5 13:27:13 dnsmasq: reply org is DNSKEY keytag 9795
Sep 5 13:27:13 dnsmasq: reply org is DNSKEY keytag 12023
Sep 5 13:27:13 dnsmasq: reply ietf.org is DS keytag 45586
Sep 5 13:27:13 dnsmasq: reply ietf.org is DS keytag 45586
Sep 5 13:27:13 dnsmasq: reply ietf.org is DNSKEY keytag 45586
Sep 5 13:27:13 dnsmasq: reply ietf.org is DNSKEY keytag 40452
Sep 5 13:27:13 dnsmasq: dnssec-query[DNSKEY] cloudflare-dnssec.net to 81.3.21.188
Sep 5 13:27:13 dnsmasq: dnssec-query[DS] cloudflare-dnssec.net to 81.3.21.188
Sep 5 13:27:13 dnsmasq: dnssec-query[DNSKEY] net to 81.3.21.188
Sep 5 13:27:13 dnsmasq: dnssec-query[DS] net to 81.3.21.188
Sep 5 13:27:13 dnsmasq: reply net is DS keytag 35886
Sep 5 13:27:13 dnsmasq: reply net is DNSKEY keytag 45464
Sep 5 13:27:13 dnsmasq: reply net is DNSKEY keytag 35886
Sep 5 13:27:13 dnsmasq: reply cloudflare-dnssec.net is DS keytag 537
Sep 5 13:27:13 dnsmasq: reply cloudflare-dnssec.net is BOGUS DNSKEY
Sep 5 13:27:13 dnsmasq: validation result is BOGUS
Sep 5 13:27:13 dnsmasq: reply www.ietf.org is <CNAME>
Sep 5 13:27:13 dnsmasq: reply www.ietf.org.cdn.cloudflare-dnssec.net is 104.20.0.85
Sep 5 13:27:13 dnsmasq: reply www.ietf.org.cdn.cloudflare-dnssec.net is 104.20.1.85
Теперь я не уверен, что домен временно настроен неправильно, или мое соединение было изменено, или мой DNS-сервер неправильно настроен, хотя все остальные домены до сих пор работали нормально, включая «ietf.org» (без www).
Если бы кто-нибудь мог помочь мне отследить проблему, я был бы благодарен.
Это связано с тем, что CloudFlare (поставщик CDN IETF) выбрал ECDSAP256SHA256 в качестве алгоритма подписи. Dnsmasq реализовал ECDSA с версии 2.69, однако он был сломан и не исправлен до версии 2.73, выпущенной в марте 2015 года. Таким образом, вам понадобится более новая версия dnsmasq или исправленная версия, чтобы исправить это правильно.
Из dnsmasq журнал изменений в разделе 2.73:
Fix broken DNSSEC validation of ECDSA signatures.
Из набора записей Cloudflare DS:
cloudflare.net. 86400 IN DS 2371 13 2 90F710A107DA51ED78125D30A68704CF3C0308AFD01BFCD7057D4BD0 3B62C68B
13 - это тип алгоритма. Каждый разрешенный алгоритм в DNSSEC имеет определенный номер. Алгоритм 13 - это ECDSA с кривой P-256 с использованием SHA-256.
в заключение dig +trace ds www.ietf.org включает запись CNAME, проходящую через Cloudflare.
www.ietf.org. 1800 В CNAME www.ietf.org.cdn.cloudflare-dnssec.net.
Это происходит со мной, используя последнюю версию dnscrypt 2.0.8 и последнюю версию dnssec 2.79; Это было временно и длилось всего 12 минут.
Таким образом, это не ограничивается более ранними версиями. Согласно разделу «Подводные камни DNS» в Пример использования комплексных инструментов мониторинга и анализа DNSSEC (курсив мой):
Б. Поддельная проверка, вызванная неправильной конфигурацией
В этом разделе мы описываем некоторые причины сбоев проверки с точки зрения неправильной конфигурации. В любом случае, RRset, который считается фиктивным, также делает недействительными любые зависимые RRset. Например, поддельный набор DNSKEY RRset означает, что все наборы RRset, чьи RRSIG могут быть потенциально подтверждены этими DNSKEY, также являются поддельными.
...
Поддельный: валидатор не может сформировать цепочку доверия между RRset и якорем доверия и не может надежно показать, что такой цепочки не должно существовать. Пример: истекший срок действия RRSIG, покрывающий набор RRset на secure.com, дает поддельный ответ; аналогично, наличие DS для зоны broken.com, в которой нет ключей DNSKEY, приводит к фиктивному статусу для любого RRset в зоне
Хотя безопасная проверка идеальна, небезопасный результат также может использоваться и эквивалентен нормальному разрешению имен без проверки подлинности. Однако ложный результат - это индикатор того, что проверка не удалась - либо из-за подделки данных DNS, либо из-за неправильной конфигурации. Ответ, возвращенный на рекурсивный (то есть от имени другого клиента) запрос, который валидатор представляет ложный, имеет статус ошибки SERVFAIL и не содержит данных DNS, что свидетельствует об общей ошибке разрешения имен. Конечный пользователь не может отличить ответ SERVFAIL, вызванный подделкой данных, от ответа, вызванного неправильной конфигурацией. В любом случае, однако, конечный результат один: имя, о котором идет речь, не может быть разрешено. В этом исследовании основное внимание уделяется фиктивной проверке, вызванной неправильной конфигурацией.