Каковы последствия публикации DURZ корневым сервером L?

Question

Мне интересно, каковы реальные эффекты L-корневого сервераиздательство DURZ сегоднябудет. В списке рассылки nanog,кто-то сказалважно оценить системные эффекты публикации подписанных зон корневыми серверами имен, даже если они не используют DNSSEC. Между тем, собственная опубликованная информация RIPE об их изменениях в корневом сервере K говорит, что естьнет проблем, если ваши резолверы не используют DNSSEC. Может кто-нибудь прояснить ситуацию? DNSSEC, похоже, представляет собой запутанную и запутанную паутину.

Если я не включу DNSSEC на своих резолверах, есть ли у меня повод беспокоиться о предстоящих изменениях на корневых серверах?

Answer 1

Тыможетчто-то увидеть, но в некоторой степени это зависит от того, какое программное обеспечение DNS вы используете.

В частности, BIND устанавливает бит «DNSSEC OK» (он же DO) для восходящих запросов, даже если он специально не запрашивает записи DNSSEC или не выполняет проверку DNSSEC.

В таких случаях корневые серверы могут отправлять обратно дополнительные записи DNSSEC, которыеможетвызвать проблемы в маловероятном случае, если на пути передачи данных окажется сломанное сетевое оборудование и/или неправильно настроенные брандмауэры.

Эти проблемы в основном связаны с размером пакета. Некоторые комплекты не любят пакеты DNS UDP, длина которых превышает 512 байт, либо из-за глючной прошивки, либо из-за ошибочных рекомендуемых конфигураций от поставщика. Смотрите мойRFC5625для получения более подробной информации. Обратите внимание, что большинство проблем, связанных с DNSSEC, о которых я сообщаю в этом RFC, относятся к оборудованию потребительского класса и только в необычных конфигурациях.

Обратите внимание, что если у вашего комплекта есть проблемы с большими пакетами UDP, то резервным вариантом будет использование TCP. Однако некоторые (заблуждающиеся) специалисты по безопасности настраивают свои брандмауэры на отключение исходящего DNS через TCP, что нарушает резервный вариант. СмотритеэтотПроект IETF для получения дополнительной информации о DNS через TCP.

Кстати, чтобы проверить конфигурацию вашей сети на предмет возможных проблем с DNS, я настоятельно рекомендуюотличный Netalyzrвеб-сайт ICSI в Калифорнийском университете в Беркли.

Однако, если быть точным, большинство экспертов DNSнетожидаются значительные проблемы из-за внедрения DNSSEC. Несколько TLD (включая .org и .se) уже были подписаны, и интернет из-за этого не рухнул.

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

Answer 2

Объяснение того, что может пойти не так, в псевдокоде, для тех, кто предпочитает императивные языки программирования :-)

-- Псевдокод (синтаксис более или менее похож на Ada), показывающий, что происходит
-- DNS-резолвер, когда корень подписан и ответы становятся
-- больше.

-- Исходная информация:
-- https://www.dns-oarc.net/oarc/services/replysizetest
-- RFC 5625
-- Отчет SSAC №35 http://www.icann.org/committees/security/sac035.pdf

-- Стефан Борцмейер

-- Используемые переменные:
-- EDNS0: логическое значение, указывает, отправляет ли распознаватель запросы EDNS0
-- EDNS0_Size: положительное целое число, размер буфера, объявленный EDNS0
-- DO_DNSSEC: логический, флаг DO, указывающий на поддержку DNSSEC резолвером
-- Min_Response_Size: целое число, минимум (после отбрасывания
-- ненужный RR) размер ответа DNS, отправленного авторитетным
-- сервер
-- Clean_path_for_fragments: логическое значение, указывает на то, что фрагменты UDP
-- может передаваться от авторитетного сервера имен к распознавателю
-- Clean_Path_For_EDNS0: логическое значение, указывает на то, что EDNS0 отвечает
-- (который может быть больше 512 байт) может перемещаться из
-- авторитетный сервер имен для распознавателя
-- Can_TCP: логическое значение, указывает, что распознаватель может запрашивать через TCP
-- (что подразумевает чистый TCP-патч и авторитетный сервер имен
-- которые принимают TCP)

-- Код может быть выполнен несколько раз для одного запроса, например
-- пример, потому что резолвер сначала пытается использовать UDP, а затем повторяет попытку
-- с TCP.

если UDP то -- НАИБОЛЕЕ распространенный транспортный протокол для DNS
   если EDNS0 тогда
      если EDNS0_Size > MTU, то
         -- BIND по умолчанию, EDNS0_size = 4096 байт
         если DO_DNSSEC тогда
            -- BIND по умолчанию, даже если не настроена проверка
            если Min_Response_Size > MTU то -- Сегодня с корнем все не так
               если Очистить_Путь_для_фрагментов тогда
                  ХОРОШО;
               еще
                  -- Через некоторое время BIND переключится на no-EDNS0, начните заново
                  Retry("Ответы не получены, возможно, из-за EDNS0");
               конец, если;
            elsif Min_Response_Size > 512 тогда
               -- Фрагментации не произойдет
               если Очистить_Путь_Для_EDNS0 тогда
                  ОК; -- Это нормальный и типичный случай для BIND
                      -- решатель сегодня, со подписанным корнем
               еще
                  Retry("Ответы не получены, возможно, из-за EDNS0");
               конец, если;
            else -- Сегодня не произойдет, ответов от корня уже > 512
               ХОРОШО;
            конец, если;
         еще
            -- Без DNSSEC ответы будут короче, но некоторые
            -- ответов от корня уже > 512
            если Min_Response_Size > MTU, то
               -- Маловероятно, без DNSSEC
               если Очистить_Путь_для_фрагментов тогда
                  ХОРОШО;
               еще
                  Retry("Ответы не получены, возможно, из-за EDNS0");
               конец, если;
            elsif Min_Response_Size > 512 тогда
               если Очистить_Путь_Для_EDNS0 тогда
                  ХОРОШО;
               еще
                  Retry("Ответы не получены, возможно, из-за EDNS0");
               конец, если;
            else -- Наиболее распространенный случай сегодня, типичный беззнаковый
                 -- ответ 100-200 байт
               ХОРОШО;
            конец, если;
         конец, если;
      elsif EDNS0_Size >= 512 then -- Но меньше MTU
         если DO_DNSSEC тогда
            если Min_Response_Size > EDNS0_Size тогда
               -- Предполагается, что пакеты DNS с установленным битом TC приходят
               -- безопасно, не всегда верно
               Повторить("Усечение");
            elsif Min_Response_Size >= 512 тогда
               если Очистить_Путь_для_EDNS0 тогда
                  ХОРОШО;
               еще
                  Retry("Ответы не получены, возможно, из-за EDNS0");
               конец, если;
            else -- Сегодня это будет происходить нечасто, некоторые ответы от root уже > 512
               ОК; -- Не всегда, некоторые промежуточные устройства могут блокировать EDNS0
                   -- ответы, даже с размером 512 тогда
               если Очистить_Путь_Для_EDNS0 тогда
                  ХОРОШО;
               еще
                  Retry("Ответы не получены, возможно, из-за EDNS0");
               конец, если;
            еще
               ХОРОШО;
            конец, если;
         конец, если;
      иначе -- EDNS0 с размером 512 тогда
         Повторить("Усечение");
      еще
         ХОРОШО;
      конец, если;
   конец, если;
иначе -- TCP
   если Can_TCP тогда
      ОК; -- Но более высокая задержка и более высокая нагрузка на авторитетные серверы имен
   еще
      Error("Fallback to TCP failed"); -- Полный и тотальный отказ
   конец, если;
конец, если;

Answer 3

Еще одно решение для проверки вашей настройки, которое я нахожу гораздо более простым, чем Netalyzr, этоТест размера ответа OARC.