возвраты dnsmasq (ложный) “поддельный” результат для проверки DNSSEC
Я выполняю локальную установку Debian 8.1 с названным Сопоставителем DNS DNSSEC-проверки dnsmasq (версия 2.72-3+deb8u1).
Я настроил его для возврата a SERVFAIL если это не может проверить DNSSEC-поддерживающий домен, т.е. если домен имеет запись DNSSEC, это должно проверить правильно, чтобы быть переданным на клиенте.
В то время как я просматривал сегодня, я хотел посетить довольно известный сайт IETF, но я не мог, потому что домен не мог быть разрешен. Я сверился с командной строкой для проверки этого, и я добрался действительно a SERVFAIL. Я сверился с сервером Google DNS (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 log в разделе 2.73:
Fix broken DNSSEC validation of ECDSA signatures.
Из набора записей Cloudflare DS:
cloudflare.net. 86400 В ДС 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 IN CNAME www.ietf.org.cdn.cloudflare-dnssec.net.
Это происходит со мной с использованием последней версии dnscrypt 2.0.8 и последней версии dnssec 2.79; Это было временно и длилось всего 12 минут.
Так что это не ограничивается более ранними версиями. Согласно разделу "Питфоллы DNS" в A Case for Comprehensive DNSSEC Monitoring and Analysis Tools (выделено автором):
B. Фальшивая проверка, вызванная неправильной конфигурацией
B. В этом разделе мы описываем некоторые из причин сбоев проверки с точки зрения неправильной конфигурации. В любом случае, RRset, считающийся фальшивым, также делает недействительным любые зависимые RRset. Например, фальшивый DNSKEY RRset означает, что все RRsets, чьи RRSIG могут быть проверены этими DNSKEY, также являются фальшивыми.
...
Bogus: Валидатор не может сформировать цепочку доверия между RRset и якорем доверия и не может надежно показать, что такая цепочка не должна существовать. Пример: RRSIG с истекшим сроком действия, охватывающий RRset в secure.com, приводит к ложному ответу; также наличие DS для зоны broken.com, в которой нет DNSKEY, приводит к ложному статусу для любого RRset в зоне
Несмотря на то, что безопасная проверка является идеальным вариантом, небезопасный результат также может быть использован и эквивалентен нормальному, неаутентифицированному разрешению имен. Однако фальшивый результат является показателем того, что проверка не прошла - либо потому, что данные DNS были подделаны, либо из-за неправильной настройки. Ответ возвращается на рекурсивный (т.е. от имени другого клиента) запрос, который валидатор делает фальшивым, имеет статус ошибки SERVFAIL и не содержит данных DNS, что указывает на сбой общего разрешения имени. Конечный пользователь не может отличить ответ SERVFAIL, вызванный фальсификацией данных, от ответа, вызванного неправильной конфигурацией. В любом случае, однако, конечный результат один и тот же: имя, о котором идет речь, не может быть разрешено. Это исследование фокусируется на фальшивой валидации, вызванной неправильной конфигурацией.