요약

  • RFC 8490은 연결된 DNS 전송과 확립된 DNS Stateful Operations 세션을 구분합니다. 상태는 소켓이 우연히 존재하기 때문이 아니라 명시적인 성공 교환이 이루어진 이후에만 시작됩니다.
  • 메시지 식별자, 단일 Primary TLV 규칙, 분리된 비활성 타이머와 keepalive 타이머, Retry Delay 및 종료 의미론은 보편적 배포를 입증한다고 주장하지 않으면서도 장기 유지 상태를 유한하고 귀속 가능하게 만듭니다.
  • 중요한 제어 질문은 연결이 살아 있는지 여부가 아니라, 각 작업을 누가 만들었고 무엇이 그 타당성을 유지하며 어떤 한계가 그것을 끝내고 재연결을 어떤 근거가 지배하는가입니다.

위임 권한이 없는 소켓

전통적인 DNS는 간결한 약속을 합니다. 클라이언트가 질문하고, 서버가 응답합니다. TCP는 하나의 연결 위에서 이런 교환을 여러 번 수행할 수 있지만, 열린 연결 자체가 어느 쪽 끝점도 구독을 설정하거나 이후 변경을 푸시하거나 응답 이후 애플리케이션 상태를 유지할 권한이 있음을 말해 주지는 않습니다. 전송 연속성은 애플리케이션 권한이 아닙니다.

RFC 8490은 2019년 3월에 발표되었으며 Ray Bellis가 Stuart Cheshire, John Dickinson, Sara Dickinson, Ted Lemon, Tom Pusateri와 함께 저술한 문서입니다. 이 문서는 OPCODE 6 아래에서 DNS Stateful Operations, 즉 DSO를 정의합니다. 이 문서는 원래의 DNS 사양과 이후의 DNS-over-TCP 요구 사항을 갱신합니다. 그 결정적 전환은 개념적입니다. 양쪽 끝점이 지속적인 DNS 작업이 존재한다는 것과 그 작업을 지배하는 규칙을 모두 알고 있는 상태에 이름을 붙인 것입니다.

클라이언트는 먼저 연결을 가집니다. 일반적인 DNS 요청을 보낼 수 있습니다. 그 연결은 성공한 DSO 요청과 그에 맞는 응답이 이루어진 이후에만, 그리고 좁게 규정된 early-data 사례를 제외하고 DSO 세션이 됩니다. 구형 서버가 이 오프코드를 이해하지 못한다면, 클라이언트는 상태가 확립된 것처럼 안전하게 행동할 수 없습니다. 침묵이 계속되면 결국 중단과 알려진 상태의 새 연결이 필요합니다. 따라서 살아 있는 소켓은 도달 가능성의 증거이며, 새 프로토콜에 대한 동의가 아닙니다.

하나의 작업이 메시지를 소유한다

DSO는 12바이트 DNS 헤더는 재사용하지만 일반적인 질문·응답 섹션은 재사용하지 않습니다. 그 작업은 Type-Length-Value 구조로 전달됩니다. 모든 메시지는 하나의 Primary TLV를 갖습니다. 그 기본 작업이 이 메시지가 확인(응답)이 필요한 요청인지, 응답을 받아서는 안 되는 단방향 메시지인지를 결정합니다.

MESSAGE ID가 이 차이를 보이게 만듭니다. DSO 요청은 0이 아닌 식별자를 사용하고 일치하는 값을 가진 응답을 반드시 이끌어야 합니다. 단방향 메시지는 0을 사용합니다. 이는 구현이 모든 신호를 트랜잭션으로 취급하거나 모든 트랜잭션을 발신 후 망각 통지로 취급하는 것을 막습니다. 또한 요청은 파이프라인으로 처리되고 응답은 순서를 벗어나 도착할 수 있으면서, 수신자는 메시지를 수신된 순서대로 처리해야 합니다.

단일 기본 작업 규칙은 작은 헌법적 선택입니다. EDNS는 하나의 OPT 레코드에 여러 옵션을 결합할 수 있어, 각 옵션 사양이 처리가 인정되는지 어떻게 인정되는지 스스로 설명해야 합니다. DSO는 대신 각 작업에 자기 메시지와 하나의 결과 코드를 부여합니다. 추가 TLV는 기본 작업의 정의가 허용하는 경우에만 기본 작업을 한정할 수 있습니다. 알 수 없는 기본 TLV는 전용 DSOTYPENI 응답을 받고, 알 수 없는 추가 TLV는 무시됩니다. 확장성은 더 이상 인식되지 않은 의미가 받아들여졌다고 가장할 필요가 없습니다.

하나가 아니라 두 개의 시계

장기 유지 상태는 자원 문제를 만듭니다. 조용한 연결은 버려졌을 수도 있고, 변경을 기다리는 유효한 구독을 운반하고 있을 수도 있습니다. RFC 8490은 따라서 비활성 타임아웃과 keepalive 간격을 분리합니다.

비활성 타이머는 유용한 작업에 관한 것입니다. 일반적인 요청이 응답을 기다리는 동안에는 작동하지 않으며, 장기 작업은 메시지가 흐르지 않더라도 취소될 때까지 활성 상태로 남습니다. keepalive 타이머는 지속적인 도달 가능성에 관한 것입니다. keepalive 트래픽은 NAT와 방화벽 상태를 유지하고 피어들이 여전히 통신할 수 있음을 확인할 수 있지만, 그것은 일반적인 DNS 활동이 아닙니다. 펄스는 경로가 살아 있음을 증명하며, 유지된 상태가 여전히 가치가 있음을 증명하지는 않습니다.

이 구분은 두 가지 정반대의 오류를 막습니다. 모든 조용한 구간을 버려짐으로 다루면 유용한 구독이 끊임없이 무너질 것입니다. 어떤 keepalive 패킷이든 애플리케이션 권한을 영원히 갱신한다면 오래된 상태는 불멸이 될 수 있습니다. 운영자는 두 시계와 함께, 상태 유지를 정당화하는 미해결 작업에 대한 가시성까지 필요로 합니다.

우르르 몰리지 않고 상태를 끝내기

지속 세션에는 출구도 필요합니다. DSO는 Retry Delay를 정의하여 서버가 세션을 종료하고 클라이언트에게 재연결 전 얼마나 기다려야 하는지 알려줄 수 있게 합니다. 이유 코드는 일상적인 재시작, 형식 오류 입력, 자원 고갈 또는 재구성을 구분할 수 있습니다. 이러한 신호들은 클라이언트가 통제된 종료를 재연결 폭풍으로 바꾸지 않도록 합니다.

이 신호는 유한한 증거로 남습니다. SERVFAIL은 부하 분산을 가리킬 수 있지만 고갈의 사적 원인은 드러내지 않습니다. REFUSED는 이전 작업이 더 이상 서비스될 수 없음을 가리킬 수 있지만, 부정행위나 영구 철회의 증거는 아닙니다. 재시도 지연은 조정 지시이며, 클라이언트의 소유권이 아닙니다.

전송 경계 역시 의도적입니다. DSO는 신뢰할 수 있고 순서가 유지되는 세션 의미론을 요구하며, DNS over TCP와 DNS over TLS에 대해 정의됩니다. 이러한 세션 속성이 없는 일반 DNS/UDP 위에서는 동작하지 않습니다. DNS over HTTPS 위에서도 동작하지 않는데, HTTP에는 자체적인 세션 장치가 있기 때문입니다. 암호화는 채널을 보호할 수 있지만, DSO는 모든 피어를 신뢰할 수 있는 존재로 만들거나 유지된 모든 작업을 적절한 것으로 만들지 않습니다.

이후 작업이 사용할 수 있는 상태

RFC 8765는 DSO를 DNS Push Notifications에 사용합니다. 구독자는 변경을 요청하고 전체 네임스페이스를 반복 폴링하지 않고 이후 업데이트를 받을 수 있습니다. 이 구체적 사용은 프레임워크가 왜 중요했는지 보여 줍니다. 혁신은 단순히 더 긴 연결이 아니라, 다른 프로토콜이 지속적인 작업을 안전하게 얹을 수 있는 공유 수명 주기입니다.

IANA DNS Parameters 레지스트리는 DSO 타입 코드와 DSO 오류 코드를 기록합니다. 등록은 확장 공간을 공개하고 충돌에 저항하게 만듭니다. 하지만 그것은 얼마나 많은 구현이 지원하는지, 타이머가 얼마나 잘 구성되어 있는지, 특정 배포가 연결을 올바르게 공유하는지를 측정하지 않습니다.

Ray Bellis의 기여는 이 경계의 규율을 통해 읽는 것이 가장 좋습니다. 이 RFC는 상태에 대한 영구 권리를 주장하지 않습니다. 확립, 사용, 침묵, 도달 가능성, 과부하, 종료, 재시도를 서로 다른 이벤트로 만듭니다. 바로 그 점이 이후의 DNS 기능들이 지속성에 의존하면서도, 지속성 자체가 보이지 않는 권한이 되는 것을 막아 줍니다.

출처