요약

  • DNS TC 비트는 응답이 전송 채널의 용량을 초과했음을 나타냅니다. RFC 2181은 나중에 이 의미 경계를 정밀하게 만들었습니다. TC는 응답에 필요한 RRset을 온전히 포함할 수 없을 때 설정되며, 클라이언트는 잘린 응답을 무시하고 보이는 레코드를 완전한 것으로 취급해서는 안 됩니다.
  • TCP가 더 큰 재시도를 전송했지만, 그것은 예외적인 최후 수단으로 남지 않았습니다. RFC 7766은 범용 DNS에서 UDP와 TCP 지원을 필수로 정하고 리졸버가 TCP를 먼저 선택할 수 있게 했으며, RFC 9210은 TCP 용량, 필터링, 모니터링을 평범한 운영 책임으로 만들었습니다.

솔직한 답은 한 봉투에 담기지 않았다

최초의 DNS 명세는 서로 다른 두 성질을 결합했습니다. UDP는 평범한 질문을 저렴하게 만들었습니다. 연결 설정이 없고, 상태도 거의 없으며, 다른 서버로의 재전송도 쉽습니다. 그러나RFC 1035는 UDP DNS 메시지를 IP와 UDP 헤더를 제외한 512바이트로 제한했습니다. 더 긴 메시지는 잘려야 했습니다.

이 한도는 위험한 모호성을 낳을 수 있었습니다. 다섯 개의 레코드가 존재하는데 세 개만 들어간다면, 소비자는 세 개를 권위적인 집합으로 읽을 수 있습니다. 그러면 전송 용량 부족이 네임스페이스에 대한 사실로 위장하게 됩니다.

DNS는 정반대의 진술을 위해TC비트를 예약했습니다. 메시지가 채널이 허용하는 것보다 길어서 잘렸다는 것입니다. TC는 이름이 존재하지 않는다는 말도, 보이는 레코드가 더 바람직하다는 말도, 서버가 자신의 관점을 바꿨다는 말도 아니었습니다. 현재 담는 그릇이 불충분하다는 것만을 말했습니다.

따라서 그 작은 비트는 단순한 크기 경고 이상을 담았습니다. 이름을 서술할 권위가 그 서술을 전달하는 기계적 장치와 분리되도록 유지했습니다.

RRset은 하나의 근거 단위로 남아야 했다

10년 뒤RFC 2181은 중요한 모호성을 제거했습니다. 같은 소유자 이름, 클래스, 타입을 가진 레코드들은 자원 레코드 집합(RRset)을 이룹니다. 질의가 그 데이터를 요구할 때, 집합이 바로 중요한 단위입니다.

TC는 응답에 필요한 RRset을 온전히 포함할 수 없을 때만 설정되어야 합니다. 단지 유용한 부가 정보를 위한 공간이 부족한 것은 다릅니다. 서버는 그 부가 RRset 전체를 생략하고 TC를 끈 상태로 응답을 보낼 수 있으며, 빠진 보조 데이터가 필요한 클라이언트는 별도로 물어볼 수 있습니다.

TC가 설정되면 규칙은 더 엄격해집니다. 클라이언트는 그 응답을 무시하고, TCP처럼 더 큰 응답을 허용하는 메커니즘을 통해 다시 질의해야 합니다. 부분 RRset은 물리적으로 패킷에 남아 있을 수 있지만, 사용 가능한 답의 지위를 얻지는 못합니다.

이것이 이 설계의 가장 깊은 선택입니다. 수신자는 어떤 바이트가 중요했는지 추측하거나 매력적인 조각을 오래된 캐시 상태와 병합하도록 요구받지 않습니다. 불완전함은 빠진 집합을 요구한 질의에 대해 응답을 무효로 만듭니다.

서버는 경계를 알렸고, 리졸버가 다음 수를 골랐다

TC는 부정적 능력 신호입니다. 서버는 이 전송이 담지 못한 것을 보고합니다. 클라이언트를 대신해 연결을 열지도, 모든 미래의 전송 방식을 지시하지도 않습니다.

익숙한 순서에서 리졸버는 UDP 질의를 보내고,TC=1을 받으면, 같은 서버에게 TCP로 질문을 반복하거나 적절한 대안을 시도합니다. TCP는 각 DNS 메시지 앞에 2바이트 길이 필드를 두며 하나의 데이터그램보다 큰 응답도 전달할 수 있습니다. 대신 연결 상태, 접수 결정, 타임아웃 비용이 따라옵니다.

그 비용은 그것을 부담하는 당사자에게 남습니다. 리졸버는 재시도할지, 연결을 재사용할지, 다른 서버를 고를지 결정합니다. 서버는 얼마나 많은 연결을 접수할지, 유휴 세션을 얼마나 유지할지 결정합니다. 어느 결정도 중개자에게 DNS 데이터를 재해석할 권한을 주지 않습니다.

이 구조가 효율적인 이유는 저렴한 경로가 자신의 한계를 스스로 선언할 수 있기 때문입니다. 신뢰할 수 있는 이유는 그 선언이 저렴한 경로가 불완전한 결과를 진실로 세탁하지 못하게 막기 때문입니다.

EDNS는 봉투를 넓혔지, 보장을 넓히지 않았다

RFC 6891은 DNS에 확장 메커니즘을 부여하고 요청자가 자신이 받을 수 있는 UDP 페이로드 크기를 알리도록 했습니다. 낡은 512바이트 상한은 모든 교환을 서술하지 않게 되었고, 더 큰 답도 종종 UDP에 머물 수 있었습니다.

그러나 광고된 숫자는 경로상의 모든 링크, 터널, 방화벽, 호스트가 그 크기의 데이터그램을 전달할 것이라는 근거가 아닙니다. IP 단편화는 사라지거나, 필터링되거나, 악용될 수 있습니다. DNSSEC도 서명과 증명 자료를 추가했고, IPv6와 새 레코드 용도는 답이 커지는 경우를 늘렸습니다.

따라서 EDNS와 TC는 서로 다른 역할을 합니다. EDNS는 제공된 용량을 진술합니다. TC는 구성된 응답이 사용 가능한 용량에 맞지 않았다는 것을 진술합니다. 예산을 늘린다고 해서 정직한 넘침 신호와 다른 전송 수단의 필요성이 사라지지 않습니다.

이 구분은 운영적으로 중요합니다. 광고된 버퍼 크기를 경로 보장으로 취급하면 TC 응답조차 없이 타임아웃이 생길 수 있습니다. EDNS를 TCP의 대체물로 취급하면 UDP 전달이 실패했을 때 큰 답을 회수할 신뢰할 만한 방법이 리졸버에게 없게 됩니다.

TCP는 의례적 예외가 아니게 되었다

오랫동안 TCP 위의 DNS는 흔히 영역 전송과 지나치게 큰 재시도의 경로로 서술되었습니다. 그 어휘는 구현과 방화벽이 이를 이례적인 것으로 취급하도록 부추겼습니다. 그 결과는 취약한 계약이었습니다. 헤더는 클라이언트에게 더 큰 용량을 찾으라고 지시하면서, 네트워크는 프로토콜이 기대하는 그 용량을 막을 수 있었습니다.

2016년에 발표된RFC 7766은 TCP를 더 단단한 지반 위에 놓았습니다. 범용 권위 서버, 재귀 서버, 포워더, 스텁 리졸버는 UDP와 TCP를 모두 지원해야 합니다. 더 미묘하게, 이 문서는 영역 전송이 아닌 질문은 UDP로 시작해야 한다고 요구하는 오래된 규칙을 완화했습니다. 리졸버는 로컬 운영상의 이유로 TCP를 먼저 선택할 수 있고 이미 열린 연결을 재사용해야 합니다.

그리하여 TCP는 단지 너무 커진 응답에 대한 벌이 아니라 타당한 대안이 되었습니다. 이 교정은 또한 역사적 메커니즘이 거짓 보편 주장이 되는 것을 막습니다. TC는 종종 TCP를 유발하지만, 현대의 DNS 전송 선택은 하나의 고정된 2단계 의식보다 넓습니다.

신뢰할 수 있는 경로를 확장하려면 새 규율이 필요했다

TCP 핸드셰이크는 지연을 추가할 수 있습니다. 답 하나마다 연결을 닫으면 그 비용을 반복적으로 치르게 됩니다. 그래서 RFC 7766은 연결 재사용과 질의 파이프라이닝을 권장합니다. 클라이언트는 이전 응답을 기다리지 않고 여러 질문을 보낼 수 있고, 서버는 그것들을 동시에 처리합니다.

답은 순서가 뒤바뀌어 돌아올 수 있습니다. 클라이언트는 스트림 순서가 질문 순서와 같다고 가정하지 말고 미해결 질의와 답을 짝지어야 합니다. 서버는 하나의 TCP 세그먼트를 하나의 완전한 DNS 메시지로 착각해서는 안 되며, 스트림 데이터는 DNS 길이 프레이밍에 따라 조립되어야 합니다.

확장은 절제에도 달려 있습니다. 클라이언트는 개별 서버에 대한 동시 연결을 최소화해야 합니다. 서버는 클라이언트별 또는 서브넷별 한도를 둘 수 있습니다. 유휴 세션은 정책에 따라 닫혀야 하고, 타임아웃은 공격자가 스트림 조각을 떨어뜨리는 것을 보상하지 않도록 완전한 DNS 메시지를 기준으로 해야 합니다.

신뢰할 수 있는 경로는 공짜가 아닙니다. 표준의 답은 그것을 비활성화하는 것이 아니라 자원 권한을 상호운용성 의무 옆에 두는 것이었습니다.

운영자는 드디어 DNS의 양쪽을 모두 보아야 했다

RFC 9210은 구현 지원을 운영 계약으로 만들었습니다. 리졸버와 서버는 UDP와 TCP를 모두 서비스해야 하고, 네트워크 운영자는 일반적인 경우 둘 다 허용해야 합니다. TCP DNS를 필터링하는 것은 UDP에서 살아남지 못하는 답의 회수 경로를 제거하므로 유해합니다.

이 요구는 한도를 폐지하지 않습니다. 서버는 자원에 상한을 둘 수 있지만, 다른 전송 방식이 충분했을 수 있다는 이유만으로 질의를 거부해서는 안 됩니다. 그것은 중요한 권력 배분입니다. 운영자는 하나의 전송 방식을 DNS 진실의 이등급 공급원으로 만들지 않으면서 용량에 대한 통제를 유지합니다.

모니터링도 따라야 합니다. UDP만 이해하는 패킷 캡처는 정상 트래픽과 공격을 놓칩니다. TCP를 인식하는 도구는 스트림을 재조립하고, 재사용된 연결을 추적하고, 파이프라인된 질문을 이해하고, 순서가 바뀐 응답을 허용해야 합니다. 그렇지 않으면 완전성을 지키는 채널이 관측의 사각지대가 됩니다.

단편화는 낡은 비트를 새롭게 가치 있게 만들었다

후기 인터넷은 UDP에 가해지는 압력을 제거하지 않았습니다. 경로를 더 가변적으로 만들었을 뿐입니다.RFC 9715는 UDP 위의 DNS에서 IP 단편화를 피하고, 페이로드를 적용되는 가장 작은 제약으로 한정하며, 더 작은 상한이 없을 때 1400바이트를 권장 최대치로 사용할 것을 권합니다. 또한 단편화된 DNS/UDP 응답은 복원력과 캐시 오염 문제를 만든다는 점을 지적합니다.

이 문서는 TC의 원인과 효과를 바꾸지 않습니다. 응답이 안전하게 맞지 않는다면 잘림은 여전히 요청자를 취약한 데이터그램에서 멀리 보낼 수 있습니다. 단편화된 응답이 유용한 응답보다 먼저 사라진다면, 요청자는 결국 대안 전송 방식을 시도해야 합니다.

이것이 TCP가 항상 성공한다는 증명은 아닙니다. 차단된 포트, 과부하 서버, 자체 경로 문제에 부딪힐 수 있습니다. 그것은 더 오래 지속되는 발상의 증명입니다. 프로토콜은 자신의 근거가 불완전할 때 그 사실을 드러내고, 전체 답을 얻기 위한 다른 경로를 보존해야 합니다.

그 비트가 결코 증명하지 않은 것

TC=1은 DNSSEC 판정이 아닙니다. 검열, 공격, 부재, 잘못된 설정, 소유권을 증명하지 않습니다. 프록시가 레코드를 제거할 권한을 부여하지도 않으며, 생략된 Additional 섹션의 모든 RRset이 핵심 답을 쓸모없게 만들었다고 말하지도 않습니다.

또한 TCP를 유일하게 생각할 수 있는 더 큰 채널로 만들지도 않습니다. RFC 2181은 더 큰 응답을 허용하는 메커니즘의 예로 TCP를 들었을 뿐이며, 이후의 DNS 전송 방식들은 다른 선택을 추가했습니다. 불변량은 전송 방식의 이름이 아닙니다. 불완전한 필수 데이터는 완전한 것으로 취급될 수 없다는 것입니다.

그 불변량 덕분에 한 비트짜리 고백은 패킷 크기, 보안 자료, 전송 관행의 변화 속에서도 살아남았습니다. 인터넷은 모든 답이 첫 봉투에 맞기를 요구하지 않았습니다. 봉투가 실패했을 때 그 사실을 고백하기를 요구했습니다.

출처와 한계

최초의 비트와 512바이트 UDP 한도는RFC 1035에서, RRset과 클라이언트 행동은RFC 2181에서, 넓어진 UDP 제안은RFC 6891에서, 현재의 TCP 구현 및 운영 의무는RFC 7766과RFC 9210에서, 단편화 회피 지침은RFC 9715에서 나옵니다. 이 표준들은 현재의 전 세계 TC 비율, TCP 가용성, 방화벽 준수, 구현 기본값 또는 리졸버 성공률을 규정하지 않습니다.