요약

  • EDNS Client Subnet은 중간 리졸버가 상위 DNS 질의에 잘라낸 클라이언트 네트워크 프리픽스를 담아, 리졸버 자신의 주소를 유일한 지역성 힌트로 대체할 수 있게 합니다.
  • 리졸버는 소스 프리픽스 중 몇 비트를 공개할지를 통제하며, 권한 서버는 맞춤 답이 캐시에서 얼마나 넓게 재사용될 수 있는지를 규정하는 스코프 프리픽스를 돌려줍니다.
  • 이 옵션은 지리, 신원 또는 동의를 증명하지 않습니다. RFC 7871은 개인정보와 캐시 비용을 문서화했고, 이후 RFC 8932는 개인정보 서비스에 ECS를 피하거나 사용을 최소화하고 공개하도록 권고했습니다.

이용자가 보내지 않은 질의

ECS 이전에는 토폴로지에 민감한 권한 서버가 재귀 리졸버의 소스 주소를 보았습니다. 리졸버와 이용자가 가까이 있으면 이것이 클라이언트 네트워크를 어림할 수 있지만, 중앙화된 리졸버는 자신의 네트워크 위치에서 먼 클라이언트까지 서비스할 수 있었습니다. 따라서 리졸버에 맞춘 답은 그 뒤에 있는 사람에게는 부적절한 답일 수 있었습니다.

RFC 7871은 중간 네임서버가 질의의 출발 네트워크에 대한 정보를 전달할 수 있게 하는 EDNS0 옵션을 문서화했습니다. 리졸버는 클라이언트에 대한 전체 정보를 전달하는 것이 아니라, 주소 패밀리와 소스 프리픽스 길이, 그리고 그 프리픽스를 덮는 데 필요한 주소 비트만 보냅니다. 질의에서 스코프 프리픽스 길이는 0입니다. 이 옵션은 스텁 리졸버와 최종 이용자에게는 계속 투명할 수 있음에도, 리졸버의 개입을 패킷 안에서 명시적으로 만듭니다.

이 투명성이 본 글의 핵심 거버넌스 사실입니다. 상위 공개는 보통 몇 개의 네트워크 비트가 유용하고 수용 가능한지를 정한 정책에 따라 중개자가 수행합니다. 권한 서비스가 이 힌트를 활용해 더 나은 응답을 고를 수 있다면 클라이언트가 이득을 보지만, 그 권한과 협상하는 당사자는 클라이언트가 아닙니다.

두 개의 프리픽스 길이, 두 개의 결정

SOURCE PREFIX-LENGTH는 질의에서 주소의 앞쪽 몇 비트가 유효한지를 나타냅니다. 재귀 리졸버는 구성된 최대 캐시 가능 길이를 갖고 있으며 전체 주소보다 짧게 사용해야 합니다. 들어온 질의에 이미 더 짧은 ECS 프리픽스가 실려 있다면, 다음 구간으로 전달하는 리졸버는 그 한도를 넘는 클라이언트 비트를 공개해서는 안 됩니다. 주소 필드는 그에 맞게 잘리고 필요한 마지막 옥텟까지만 채워집니다.

SCOPE PREFIX-LENGTH는 응답에서 다른 역할을 합니다. 앞쪽 몇 비트가 그 답이 의도된 네트워크를 정의하는지를 말합니다. 짧은 스코프는 답이 더 넓은 범위를 커버할 수 있음을 뜻하고, 긴 스코프는 권한에 공급된 소스 프리픽스가 가장 적절한 맞춤 답을 고르기에 충분히 구체적이지 않았음을 신호할 수 있습니다.

어느 숫자도 위치를 증명하지 않습니다. RFC 7871은 토폴로지적 거리를 지리와 구별합니다. 지도상으로 멀리 떨어진 기계가 네트워크상으로는 가까울 수 있고, 이웃이 네트워크상으로는 멀 수 있습니다. 또한 이 옵션은 권한이 맞춤 응답을 고르는 방식을 정의하지 않습니다. 스코프는 답의 재사용을 규율할 뿐, 선택된 서버가 가장 가깝거나 빠르거나 최선이라는 것을 인증하지 않습니다.

캐시가 프로토콜의 일부가 되다

ECS를 인식하는 캐시도 여전히 이름, 타입, 클래스라는 평범한 DNS 튜플에서 시작합니다. 그런 다음 프리픽스 매칭으로 캐시된 응답 집합 가운데 하나를 고릅니다. 응답 레코드는 응답이 기술한 네트워크에 묶이며, 소스 길이·스코프 길이·리졸버의 최대 캐시 길이 사이의 관계가 항목을 어떻게 재사용할 수 있는지를 결정합니다.

응답에 ECS 옵션이 없으면 리졸버는 보통 이를 스코프 /0으로 취급해 모든 클라이언트 주소에 적용합니다. 권한 서버가 REFUSED를 돌려주면, ECS를 인식하는 리졸버는 ECS 없이 재시도하여 옵션에 대한 거부를 같은 응답 코드의 다른 용법과 구분할 수 있게 합니다.

이 추가 차원에는 비용이 따릅니다. 같은 이름·타입·클래스에 대해 서로 다른 네트워크가 서로 다른 캐시 답을 요구할 수 있습니다. RFC 7871은 캐시 증대, 재사용 감소, 서버 부하 증가를 경고하고, 클라이언트가 명확한 이득을 얻는 경우에만 ECS를 켜고 기본 구성에서는 끄며, 유지하는 네트워크와 답의 수를 제한하도록 권고합니다.

거부 경로가 중요한 옵트아웃

스텁 리졸버는 SOURCE PREFIX-LENGTH를 0으로 하여 ECS를 보낼 수 있습니다. 이 지시를 받은 재귀 리졸버는 상위 질의에 클라이언트의 주소 정보를 담아서는 안 되며, ECS를 생략하거나 자신의 주소 정보를 대신 사용할 수 있습니다. 전달 리졸버는 공개를 넓히지 않고 들어온 한도를 보존해야 합니다.

와이어 규칙은 명확하지만, RFC 7871의 2016년 개인정보 비고는 당시 이 선호를 표현하는 실질적 지원이 제한적이었다는 점도 기록했습니다. 이 관찰은 역사적 것이며 현재의 채택 주장이 아닙니다. 여기에 쓰인 출처 집합에는 애플리케이션, 공개 리졸버 또는 운영자 정책에 대한 현재 인구조사가 없습니다.

RFC 8932는 2020년 DNS 개인정보 서비스를 위한 문제를 다시 정립했습니다. 암호화는 특정 관찰자로부터 클라이언트-리졸버 전송을 보호하지만, 리졸버는 여전히 질의를 보고 그 정보를 상위로 보낼 수 있습니다. 이 BCP는 서비스가 소스 프리픽스 0을 존중하고, 상위로 ECS를 보내지 않거나 그렇게 하지 않는 서비스를 제공해야 한다고 규정합니다. 운영자가 ECS를 사용한다면, 운영상 가능한 가장 짧은 프리픽스를 고르고, 이상적으로는 그 정보를 받는 상위 서버를 제한하며, 프리픽스 길이와 정책을 공개해야 합니다.

개인정보와 DNSSEC은 서로 다른 통제

DNSSEC는 프리픽스를 인증된 클라이언트 문맥으로 바꾸지 않습니다. RFC 7871은 대부분의 DNSSEC 레코드를 /0으로 스코프하도록 권고하며, RRSIG는 자신이 서명하는 RRset에 계속 묶입니다. 검증은 DNSSEC의 규칙에 따라 DNS 데이터를 보호할 수 있지만, 리졸버의 프리픽스 공개 결정에 서명하거나, 지리를 증명하거나, 권한의 지역성 정책을 인증하지는 않습니다.

따라서 역사적 교훈은 ECS가 DNS 개인정보를 무력화했거나 더 나은 전송을 보장했다는 것이 아닙니다. 지역성 최적화가 두 가지 중개자 정책을 지속되게 만들었다는 것입니다. 즉, 리졸버가 이용자를 대신해 무엇을 공개하는가, 그리고 권한이 이후 캐시 재사용을 어떻게 분할하는가입니다. 이는 프로토콜 동작에 대한 본지의 해석이며, 오늘날 네트워크가 ECS를 어떻게 배치하는지에 대한 측정이 아닙니다.

출처