L 루트 서버의 실제 효과가 무엇인지 궁금합니다.오늘 DURZ 게시될거야. nanog 메일링 리스트에는누군가가 말했다DNSSEC를 사용하지 않는 경우에도 서명된 영역을 게시하는 루트 이름 서버의 시스템적 효과를 평가하는 것이 중요합니다. 한편 K 루트 서버 변경 사항에 대한 RIPE 자체 게시 정보에는 다음과 같은 내용이 있다고 나와 있습니다.확인자가 DNSSEC를 사용하지 않으면 문제가 없습니다.. 누군가 이 문제를 해결해 주실 수 있나요? DNSSEC는 지저분하고 얽힌 웹인 것 같습니다.
확인자에서 DNSSEC를 활성화하지 않은 경우 루트 서버에 대한 향후 변경 사항에 대해 걱정할 사항이 있습니까?
답변1
너5월뭔가를 볼 수 있지만 어느 정도는 실행 중인 DNS 소프트웨어에 따라 다릅니다.
특히 BIND는 DO특별히 DNSSEC 레코드를 요청하거나 DNSSEC 유효성 검사를 수행하지 않는 경우에도 업스트림 쿼리에 "DNSSEC OK"(일명 ) 비트를 설정합니다.
이러한 상황에서 루트 서버는 추가 DNSSEC 레코드를 다시 보낼 수 있습니다.5월네트워크 장비가 손상되었거나 경로에 방화벽이 잘못 구성된 경우 드물지만 문제가 발생할 수 있습니다.
이러한 문제는 대부분 패킷 크기와 관련이 있습니다. 일부 키트는 버그가 있는 펌웨어나 공급업체의 권장 구성 오류로 인해 길이가 512바이트를 초과하는 DNS UDP 패킷을 좋아하지 않습니다. 내 것을 보아라RFC 5625상세 사항은. RFC에서 보고한 대부분의 DNSSEC 관련 문제는 소비자 등급 장비와 관련이 있으며 비정상적인 구성에서만 발생합니다.
키트에 대규모 UDP 패킷에 문제가 있는 경우 대체 방법은 TCP를 사용하는 것입니다. 그러나 일부 (잘못된) 보안 담당자는 TCP를 통한 아웃바운드 DNS를 비활성화하도록 방화벽을 구성하여 대체를 중단합니다. 보다이것TCP를 통한 DNS에 대한 자세한 내용은 IETF 초안입니다.
그런데 가능한 DNS 문제에 대한 네트워크 구성을 테스트하려면 다음을 적극 권장합니다.훌륭한 네탈라이저UC 버클리 ICSI 웹사이트.
그러나 분명히 말하면 대부분의 DNS 전문가는~ 아니다DNSSEC 도입으로 인해 심각한 문제가 예상됩니다. 여러 TLD(.org 및 .se 포함)가 이미 서명되었으며 이로 인해 인터넷이 붕괴되지 않았습니다.
DURZ는 여름에 전체 루트 영역이 DNSSEC로 넘어가기 전에 네트워크 문제가 있는 희귀 사이트가 문제를 해결할 수 있도록 DNSSEC가 필연적으로 생성하는 더 큰 응답을 점진적으로 단계적으로 진행하려는 의도적인 시도입니다.
답변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: 부울, 확인자에 의한 DNSSEC 지원을 나타내는 DO 플래그
-- 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이면 -- 현재 루트의 경우는 그렇지 않습니다.
Clean_Path_for_fragments인 경우
좋아요;
또 다른
-- 잠시 후 BIND는 no-EDNS0으로 전환되고 다시 시작됩니다.
Retry("EDNS0 때문에 응답을 받지 못했습니다.");
종료하면;
elsif Min_Response_Size > 512 그런 다음
-- 조각화가 발생하지 않습니다.
Clean_Path_For_EDNS0이면
좋아요; -- 이는 BIND의 정상적이고 일반적인 경우입니다.
-- 오늘 서명된 루트가 있는 리졸버
또 다른
Retry("EDNS0 때문에 응답을 받지 못했습니다.");
종료하면;
else -- 오늘은 발생하지 않습니다. 루트의 응답이 이미 512보다 큽니다.
좋아요;
종료하면;
또 다른
-- DNSSEC가 없으면 응답은 더 짧아지지만 일부
-- 루트의 응답이 이미 512보다 큽니다.
Min_Response_Size > MTU인 경우
-- DNSSEC가 없으면 가능성이 낮습니다.
Clean_Path_for_fragments인 경우
좋아요;
또 다른
Retry("EDNS0 때문에 응답을 받지 못했습니다.");
종료하면;
elsif Min_Response_Size > 512 그런 다음
Clean_Path_For_EDNS0이면
좋아요;
또 다른
Retry("EDNS0 때문에 응답을 받지 못했습니다.");
종료하면;
else -- 오늘날 가장 일반적인 경우로, 전형적인 unsigned
-- 대답은 100-200바이트입니다.
좋아요;
종료하면;
종료하면;
elsif EDNS0_Size >= 512 then -- 하지만 MTU보다 낮습니다.
DO_DNSSEC이면
Min_Response_Size > EDNS0_Size인 경우
-- TC 비트가 설정된 DNS 패킷이 도착했다고 가정합니다.
-- 안전하게, 항상 사실은 아닙니다
재시도("잘림");
elsif Min_Response_Size >= 512 그러면
Clean_Path_for_EDNS0이면
좋아요;
또 다른
Retry("EDNS0 때문에 응답을 받지 못했습니다.");
종료하면;
else -- 오늘은 자주 발생하지 않습니다. 루트의 일부 응답이 이미 512보다 큽니다.
좋아요; -- 항상 그런 것은 아니지만 일부 미들박스는 EDNS0을 차단할 수 있습니다.
-- 크기 512에서도 응답
Clean_Path_For_EDNS0이면
좋아요;
또 다른
Retry("EDNS0 때문에 응답을 받지 못했습니다.");
종료하면;
또 다른
좋아요;
종료하면;
종료하면;
else -- 크기가 512인 EDNS0
재시도("잘림");
또 다른
좋아요;
종료하면;
종료하면;
그렇지 않으면 - TCP
Can_TCP이면
좋아요; -- 그러나 권한 있는 이름 서버에서는 대기 시간이 길고 로드가 더 높습니다.
또 다른
Error("TCP로의 대체 실패"); -- 완전하고 총체적인 실패
종료하면;
종료하면;
답변3
Netalyzr보다 훨씬 간단하다고 생각되는 설정을 테스트하는 또 다른 솔루션은 다음과 같습니다.OARC 응답 크기 테스트.