EDNS 클라이언트 서브넷

EDNS Client Subnet

ECS(EndNS Client Subnet)는 재귀 DNS 확인자DNS 쿼리를 수행하는 호스트 또는 클라이언트의 하위 네트워크를 지정할 수 있도록 하는 DNS 확장 메커니즘의 옵션이다.이는 일반적으로 클라이언트 컴퓨터가 반드시 재귀 확인자 근처에 있지 않을 때 DNS 기반 로드 밸런싱을 더 잘 사용하여 클라이언트 근처의 서비스 주소를 선택할 수 있도록 함으로써 컨텐츠 전달 네트워크의 데이터 전송 속도를 높이도록 하기 위한 것이다.[1][2]

권한 있는 이름 서버가 DNS 쿼리를 받으면 ECS DNS 확장을 이용하여 지리적으로 클라이언트 IP서브넷에 가까운 CDN에 대한 호스트 이름을 확인하므로 클라이언트는 가까운 CDN에 추가 요청을 함으로써 지연 시간을 줄인다.EDNS 클라이언트 서브넷 메커니즘이 다음에 지정됨 RFC7871.

개인 정보 보호 및 보안 관련 영향

ECS는 업스트림 해결사에게 클라이언트 네트워크 정보를 제공하기 때문에, 그 확장은 해결사가 그렇지 않으면 추론할 수 없는 클라이언트의 위치에 대한 일부 정보를 공개한다.[3]보안 연구원들은 ECS가 인터넷 감시를 수행하는 데 사용될 수 있다고 제안했다.[3]또한 ECS는 특정 클라이언트를 독이 든 DNS 레코드로만 재라우팅하기 위한 선택적인 DNS 캐시 중독 공격을 수행하는데 악용될 수 있다.[3]

지지부진 논란

자체 서비스 웹 아카이빙Archive.오늘 소유자는 Cloudflare 1.1.1.1이 이 필드의 내용을 Archive.의 공식 DNS 서버에 전달하지 않는 것에 대해 우려를 표명하고 이에 대응하여 사이트의 해결자가 Cloudflare DNS 요청이 유효하지 않은 것으로 간주하도록 구성함으로써 1.1.1이 웹 사이트 DNS를 해결하는 것을 효과적으로 차단함기록들[4]

사이트 소유자는 1.1.1.1이 너무 자주 반복 DNS 요청을 지리학적으로 최적이 아닌 방식으로 라우팅하여 해당 기능이 항상 사용 가능한 경우보다 연결 상태가 더 좋지 않다고 생각한다.[4]

클라우드플레어 CEO 매튜 프린스는 1.1.1.1이 ECS를 지원하지 않는 이유로 프라이버시 우려를 꼽았다.[5]

참조

  1. ^ "How it works". A Faster Internet. Archived from the original on 2018-03-28. Retrieved 2018-03-27.{{cite web}}: CS1 maint : 부적합한 URL(링크)
  2. ^ "EDNS Client Subnet (ECS) Guidelines Public DNS Google Developers". Google Developers. Retrieved 2018-04-02.
  3. ^ a b c Kintis P, Nadji Y, Dagon D, Farrell M, Antonakakis M (June 2016). "International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment Extended Abstract Chapter 17: Understanding the Privacy Implications of ECS" (PDF). Lecture Notes in Computer Science. Springer. 9721: 343–353. doi:10.1007/978-3-319-40667-1_17. ISBN 978-3-319-40667-1.
  4. ^ a b @archiveis (July 16, 2018). ""Having to do" is not so direct here" (Tweet) – via Twitter. Absence of EDNS and massive mismatch (not only on AS/Country, but even on the continent level) of where DNS and related HTTP requests come from causes so many troubles so I consider EDNS-less requests from Cloudflare as invalid.
  5. ^ Matthew Prince (4 May 2019). "Comment by Matthew Prince on Hacker News". Hacker News. Retrieved 4 October 2021. We don’t block archive.is or any other domain via 1.1.1.1. Doing so, we believe, would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service. Archive.is’s authoritative DNS servers return bad results to 1.1.1.1 when we query them. I’ve proposed we just fix it on our end but our team, quite rightly, said that too would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service. The archive.is owner has explained that he returns bad results to us because we don’t pass along the EDNS subnet information. This information leaks information about a requester’s IP and, in turn, sacrifices the privacy of users. This is especially problematic as we work to encrypt more DNS traffic since the request from Resolver to Authoritative DNS is typically unencrypted. We’re aware of real world examples where nationstate actors have monitored EDNS subnet information to track individuals, which was part of the motivation for the privacy and security policies of 1.1.1.1. EDNS IP subsets can be used to better geolocate responses for services that use DNS-based load balancing. However, 1.1.1.1 is delivered across Cloudflare’s entire network that today spans 180 cities. We publish the geolocation information of the IPs that we query from. That allows any network with less density than we have to properly return DNS-targeted results. For a relatively small operator like archive.is, there would be no loss in geo load balancing fidelity relying on the location of the Cloudflare PoP in lieu of EDNS IP subnets. We are working with the small number of networks with a higher network/ISP density than Cloudflare (e.g., Netflix, Facebook, Google/YouTube) to come up with an EDNS IP Subnet alternative that gets them the information they need for geolocation targeting without risking user privacy and security. Those conversations have been productive and are ongoing. If archive.is has suggestions along these lines, we’d be happy to consider them.