Каковы последствия того, что корневой сервер L теперь публикует DURZ?

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

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

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

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

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

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

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

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

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

-- Pseudo-code (syntax more or less Ada-like) to show what happens to
--  a DNS resolver when the root is signed and the responses become
--  larger.

-- Background information:
--    https://www.dns-oarc.net/oarc/services/replysizetest
--    RFC 5625
--    SSAC report #35 http://www.icann.org/committees/security/sac035.pdf

-- Stephane Bortzmeyer 

-- Variables used:
--   EDNS0: boolean, indicates if the resolver sends EDNS0 requests
--   EDNS0_Size: positive integer, the buffer size advertised by EDNS0
--   DO_DNSSEC: boolean, the DO flag indicating DNSSEC support by the resolver
--   Min_Response_Size: integer, the minimum (after dropping
--     unnecessary RR) size of the DNS response sent by the authoritative
--     server
--   Clean_path_for_fragments: boolean, indicates that UDP fragments
--     can travel from the authoritative name server to the resolver
--   Clean_Path_For_EDNS0: boolean, indicates that EDNS0 responses
--     (which may be larger than 512 bytes) can travel from the
--     authoritative name server to the resolver
--   Can_TCP: boolean, indicates that the resolver can ask through TCP
--     (which implies a clean TCP patch and an authoritative name server
--     which accept TCP)

-- The code can be executed several times for one request, for
--  instance because a resolver tries first with UDP, then retries
--  with TCP.

if UDP then -- MOst common transport protocol for DNS
   if EDNS0 then
      if EDNS0_Size > MTU then
         -- BIND default, EDNS0_size = 4096 bytes
         if DO_DNSSEC then
            -- BIND default, even if not configured for validation
            if Min_Response_Size > MTU then -- Not the case today with the root
               if Clean_Path_for_fragments then
                  OK;
               else
                  -- After a while BIND will switch to no-EDNS0, start over
                  Retry("Responses not received may be because of EDNS0");
               end if;
            elsif Min_Response_Size > 512 then
               -- No fragmentation will occur
               if Clean_Path_For_EDNS0 then
                  OK; -- That's the normal and typical case for a BIND
                      -- resolver today, with the signed root
               else
                  Retry("Responses not received may be because of EDNS0");
               end if;
            else -- Won't occur today, responses from the root are already > 512
               OK;
            end if;
         else
            -- Without DNSSEC, responses wil be shorter but some
            --  responses from the root already are > 512
            if Min_Response_Size > MTU then
               -- Unlikely, without DNSSEC
               if Clean_Path_for_fragments then
                  OK;
               else
                  Retry("Responses not received may be because of EDNS0");
               end if;
            elsif Min_Response_Size > 512 then
               if Clean_Path_For_EDNS0 then
                  OK;
               else
                  Retry("Responses not received may be because of EDNS0");
               end if;
            else -- Most common case today, the typical unsigned
                 -- answer is 100-200 bytes
               OK;
            end if;
         end if;
      elsif EDNS0_Size >= 512 then -- But lower than the MTU
         if DO_DNSSEC then
            if Min_Response_Size > EDNS0_Size then
               -- This assumes that DNS packets with TC bit set arrive 
               -- safely, not always true
               Retry("Truncation");
            elsif Min_Response_Size >= 512 then
               if Clean_Path_for_EDNS0 then
                  OK;
               else
                  Retry("Responses not received may be because of EDNS0");
               end if;
            else -- Won't often occur today, some responses from the root are already > 512
               OK; -- Not always, some middleboxes may block EDNS0
                   -- responses, even with size  512 then
               if Clean_Path_For_EDNS0 then
                  OK;
               else
                  Retry("Responses not received may be because of EDNS0");
               end if;
            else
               OK;
            end if;
         end if;
      else -- EDNS0 with size  512 then
         Retry("Truncation");
      else
         OK;
      end if;
   end if;
else -- TCP
   if Can_TCP then
      OK; -- But higher latency and higher load on authoritative name servers
   else
      Error("Fallback to TCP failed"); -- Complete and total failure
   end if;
end if;

Другое решение для проверки вашей установки, которое я считаю намного проще, чем Netalyzr, - это Тест размера ответа OARC.