EDNS 클라이언트 서브넷 (ECS) 가이드라인

소개

RFC 7871 - DNS 쿼리의 클라이언트 서브넷은 Google Public DNS와 같은 재귀 리졸버에 대해 부분적인 클라이언트 IP 주소 정보를 권한 있는 DNS 네임서버로 전송하는 메커니즘을 정의합니다. 콘텐츠 전송 네트워크 (CDN) 및 지연 시간에 민감한 서비스는 이를 사용하여 공개 DNS 리졸버를 통해 발생하는 이름 조회에 응답할 때 정확한 지리적 위치 응답을 제공합니다.

RFC는 권한 있는 네임서버가 구현해야 하는 ECS 기능을 설명하지만 구현자가 이러한 요구사항을 항상 따르는 것은 아닙니다. 또한 RFC로 해결하지 않는 ECS 작업 및 배포 문제도 있습니다. 이는 Google Public DNS와 같이 권한 있는 네임서버에서 ECS 지원을 자동 감지하는 리졸버와 OpenDNS와 같이 ECS 허용 목록이 필요한 리졸버에 문제를 일으킬 수 있습니다.

이 가이드라인은 공신력 있는 DNS 구현자와 작업자가 ECS에 문제를 일으킬 수 있는 많은 일반적인 실수를 방지할 수 있도록 돕기 위한 것입니다.

용어 정의

Google에서는 ECS 작업을 설명하기 위해 다음 용어를 사용합니다.

  • 네임서버는 ECS 쿼리에 ECS 옵션이 일치하는 ECS 쿼리에 응답하는 경우 ECS를 구현 (또는 지원)합니다(ECS 옵션에 항상 전역 /0 범위 프리픽스 길이가 있는 경우에도 해당).

  • 0이 아닌 소스 프리픽스와 함께 전송되는 ECS 쿼리가 0이 아닌 범위를 포함하는 ECS 응답을 수신하는 경우 영역이 ECS가 사용 설정됩니다.

권한 네임서버 가이드라인

  1. ECS 지원 영역의 모든 권한 네임서버는 영역에 ECS를 사용 설정해야 합니다.

    • 하나의 네임서버만 ECS를 구현하거나 영역에 사용 설정하지 않더라도 빠르게 대부분의 캐시된 데이터의 소스가 됩니다. 응답에는 전역 범위가 있으므로 TTL이 만료될 때까지 클라이언트 서브넷과 관계없이 동일한 이름의 모든 쿼리에 대한 응답으로 사용됩니다. ECS를 구현하고 사용 설정하는 서버의 응답은 특정 범위 내의 클라이언트의 쿼리에만 사용되므로 전역 범위 응답보다 사용될 가능성이 훨씬 낮습니다.

  2. ECS를 구현하는 신뢰할 수 있는 네임서버는 반드시 2 ECS가 사용 설정되지 않은 영역인 경우에도 IP 주소 또는 NS 호스트 이름에서 제공하는 모든 영역의 ECS 쿼리에 ECS 응답을 보내야 합니다.

    • 주소 수가 네임서버 호스트 이름 수보다 작고 DNS 영역 수보다 훨씬 작기 때문에 Google 공개 DNS는 네임서버 호스트 이름 또는 DNS 영역 대신 IP 주소로 ECS 지원을 자동으로 감지합니다. 권한 네임서버가 ECS 쿼리에 항상 ECS 응답을 전송하지는 않는 경우 (ECS가 사용 설정되지 않은 영역에도 사용 가능) Google Public DNS에서 ECS 쿼리 전송을 중지할 수 있습니다.

  3. ECS를 구현하는 신뢰할 수 있는 네임서버는 부정적인 응답 및 추천 응답을 포함하여 ECS 응답을 포함하는 모든 ECS 쿼리에 응답해야 합니다.

    • ECS 지원 자동 감지와 동일한 문제도 여기에 적용됩니다.

    • 음성 응답 (NXDOMAIN 및 NODATA)은 RFC 7871과의 호환성을 향상하고 캐싱하기 위해 전역 /0 범위를 사용해야 합니다3.

    • NXDOMAIN 및 NODATA 외에, ECS 쿼리에 대한 다른 오류 응답(특히 SERVFAIL 및 REFUSED)에는 전역 /0 범위와 일치하는 ECS 옵션이 포함되어야 합니다.

      • 권한 있는 네임서버에서 DoS 공격을 통해 로드를 해제하려고 하면 ECS 데이터 없이 SERVFAIL을 반환할 수 있습니다. 이렇게 하면 Google 공개 DNS에서 ECS를 통한 쿼리 전송을 중지합니다. 이로 인해 적법한 쿼리 수가 줄어들 수 있지만 임의 하위 도메인 공격 쿼리에는 영향을 주지 않습니다. DoS 공격 중에 적법한 쿼리 로드를 줄이면 적법한 쿼리의 성공률이 개선되거나 개선되지 않을 수 있습니다(모든 클라이언트의 캐시에서 응답을 제공할 수 있음).

        보다 효과적인 부하 쉐이딩 접근 방식은 Google Public DNS가 ECS 쿼리를 계속 전송하도록 전역 /0 범위로 모든 응답을 전송하는 것입니다. 이렇게 하면 공격이 중지된 직후 훨씬 더 빨리 지리적 위치에 있는 응답을 Google Public DNS에서 반환할 수 있습니다. ECS 지원을 다시 감지할 필요가 없으며 전역 범위 응답 TTL이 만료되면 다시 쿼리하기만 하면 됩니다.

    • 추천 (위임) 응답에는 일치하는 ECS 데이터도 있어야 하며 전역 /0 범위를 사용해야 합니다4. 위임 응답은 ECS 데이터에 주소가 표시되는 클라이언트에 전달되지 않으므로, ECS 데이터가 아닌 Resolver의 클라이언트 IP 주소로 지리적으로 식별된 NS, A 또는 AAAA 레코드를 선택해야 합니다.

  4. ECS를 구현하는 신뢰할 수 있는 네임서버는 ECS 옵션으로 수신된 모든 쿼리 유형에 대한 응답으로 일치하는 ECS 옵션을 포함해야 합니다. ECS 데이터가 있는 IPv4 주소 (A) 쿼리에 응답하기에는 충분하지 않습니다. A, AAAA, PTR, MX 또는 기타 쿼리 유형에 대한 응답은 일치하는 ECS 데이터를 포함해야 하며, 응답이 거짓일 가능성이 있는 응답을 삭제할 수 있으며 Google 공개 DNS는 ECS 데이터가 있는 쿼리 전송을 중지할 수 있습니다.

    특히 SOA, NS, DS 쿼리에 대한 ECS 응답은 항상 더 나은 캐싱과 위임의 일관적인 뷰를 위해 전역 /0 범위를 사용해야 합니다(네임서버 호스트 이름에 대한 A/AAAA 쿼리에 대한 지리적 위치 응답은 정상임). ECS 데이터에 따라 변경되지 않는 모든 쿼리 유형 (예: TXT, PTR)에 대한 응답은 소스 프리픽스 길이와 동일한 범위를 사용해서는 안 됩니다. 더 나은 캐싱 및 쿼리 로드를 줄이기 위해 전역 /0 범위를 사용해야 합니다.

  5. ECS가 사용 설정된 CNAME 응답을 반환하는 권한 있는 네임서버는 반드시5 체인의 첫 번째 CNAME만 포함해야 하며 CNAME 체인의 최종 타겟은 동일한 범위의 프리픽스 길이로 ECS가 사용 설정되어야 합니다. ECS 사양의 모호성으로 인해 일부 재귀 리졸버(특히 Unbound6)는 CNAME이 아닌 최종 도메인 범위(ECS가 사용 설정되지 않은 경우 /0)의 응답을 반환할 수 있습니다.

  6. ECS 데이터에는 IPv4 전용 네임서버의 경우 IPv6 주소가 포함될 수 있으며 그 반대의 경우도 마찬가지입니다. 단, IPv6 전용 네임서버는 드물게 있습니다.

    • 네임서버가 유효한 ECS 옵션 데이터로 응답해야 합니다(/0 범위는 괜찮지만 소스 주소와 프리픽스 길이는 반드시 일치해야 함).

    • 영역의 ECS는 IPv4 및 IPv6 주소용으로 별도로 사용 설정할 수 있습니다.

  7. ECS 지원 응답을 반환하는 권한 있는 네임서버는 답변에 범위 프리픽스가 겹치면 안 됩니다7. 중복되는 범위 프리픽스의 예는 다음과 같습니다.

    • 소스 프리픽스가 198.18.0.0/15인 쿼리: 범위 프리픽스가 198.0.0.0/8인 응답 A

    • 소스 프리픽스가 198.51.100/24인 쿼리: 범위 프리픽스가 198.51.0.0/16인 응답 B

    클라이언트가 위의 순서에 따라 ECS 지원 재귀 리졸버를 쿼리하면 두 쿼리 모두 응답 A를 얻을 수 있습니다. 캐시된 응답 A의 범위에 두 번째 쿼리의 프리픽스 범위가 포함되기 때문입니다. 클라이언트 쿼리가 반대 순서로 작성되어 있고 두 쿼리가 신뢰할 수 있는 네임서버로 전달되더라도 캐시된 응답은 다른 시간에 만료될 수 있습니다. 후속 쿼리가 중복되는 프리픽스 198.51.100/24에 있으면 응답 A 또는 B를 받을 수 있습니다.

  8. ECS 지원을 네임서버에서 처음으로 구현할 때는 이러한 ECS 사용 설정 영역을 제공하는 네임서버에 새 IP 주소를 사용하세요.

    • ECS를 구현했지만 전역 범위 결과를 반환하는 권한 있는 네임서버에서 영역의 ECS를 사용 설정하면 반환되면 Google Public DNS는 이전 전역 범위 응답의 TTL이 만료되는 즉시 지리적으로 쿼리에 대한 응답을 반환하기 시작합니다.

    • ECS 지원의 Google 공개 DNS 자동 감지는 ECS 지원 부족 (제한 시간, FORMERR, BADVERS 또는 비 ECS 응답 전송)이 자동 감지될 때 IP 주소(또는 네임서버 호스트 이름)에 대해 ECS 쿼리를 거의 시도하지 않습니다. 이러한 IP 주소 (또는 NS 호스트 이름)의 새 ECS 구현은 매우 느리게 감지되거나 전혀 감지되지 않습니다.

  9. 네트워크 연결을 신뢰할 수 있는지, 응답률 제한이 충분히 높게 설정되어 네임서버가 쿼리를 삭제하지 않는지 확인합니다(또는 상응하는 ECS 옵션이 없는 오류로 응답).

    • ECS 쿼리에 응답 비율 제한을 구현하는 네임서버의 경우 가장 적합한 응답은 잘라내기 (TC) 플래그가 설정된 NODATA이며 일치하는 질문 섹션과 일치하는 ECS 옵션만 포함되어 있습니다.

  10. 모든 쿼리에 시기적절하게 응답합니다 (1초 이내가 가장 좋음).

    • DNS 쿼리 및 온라인 Geo-IP 서비스의 누적 지연 시간은 1초 이내일 가능성이 낮으므로 ECS 쿼리에 온라인 Geo-IP 조회 서비스를 안정적으로 사용할 수 없습니다. ECS 지원에 대한 Google 공개 DNS 자동 감지는 응답이 지연되면 ECS 지원이 미흡하거나 불완전하다는 것을 나타내므로 향후 쿼리가 ECS와 함께 전송될 가능성을 줄입니다. 응답이 충분히 지연되면 ECS 쿼리 전송이 중지됩니다.

RFC 7871 참조 및 기타 각주

1https://tools.ietf.org/html/rfc7871#page-12

FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match those in the query. Echoing back these values helps to mitigate certain attack vectors, as described in Section 11.

2 https://tools.ietf.org/html/rfc7871#section-7.2.1

An Authoritative Nameserver that implements this protocol and receives an ECS option MUST include an ECS option in its response to indicate that it SHOULD be cached accordingly, regardless of whether the client information was needed to formulate an answer.

3https://tools.ietf.org/html/rfc7871#section-7.4

It is RECOMMENDED that no specific behavior regarding negative answers be relied upon, but that Authoritative Nameservers should conservatively expect that Intermediate Nameservers will treat all negative answers as /0; therefore, they SHOULD set SCOPE PREFIX-LENGTH accordingly.

4https://tools.ietf.org/html/rfc7871#section-7.4

The delegations case is a bit easier to tease out. In operational practice, if an authoritative server is using address information to provide customized delegations, it is the resolver that will be using the answer for its next iterative query. Addresses in the Additional section SHOULD therefore ignore ECS data, and the Authoritative Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations.

5https://tools.ietf.org/html/rfc7871#page-12

For the specific case of a Canonical Name (CNAME) chain, the Authoritative Nameserver SHOULD only place the initial CNAME record in the Answer section, to have it cached unambiguously and appropriately. Most modern Recursive Resolvers restart the query with the CNAME, so the remainder of the chain is typically ignored anyway.

6https://unbound.net/pipermail/unbound-users/2015-May/003875.html

CNAME 체인에서 최종 도메인의 범위를 사용하는 것은 Unbound에서 일반적으로 무해합니다. 모든 클라이언트가 동일한 서브넷에 있고 동일한 응답을 받게 되는 로컬 스텁 또는 전달 리졸버로 배포되기 때문입니다.

7https://tools.ietf.org/html/rfc7871#page-13

Authoritative Nameservers might have situations where one Tailored Response is appropriate for a relatively broad address range, such as an IPv4 /20, except for some exceptions, such as a few /24 ranges within that /20. Because it can't be guaranteed that queries for all longer prefix lengths would arrive before one that would be answered by the shorter prefix length, an Authoritative Nameserver MUST NOT overlap prefixes.

When the Authoritative Nameserver has a longer prefix length Tailored Response within a shorter prefix length Tailored Response, then implementations can either:

  1. Deaggregate the shorter prefix response into multiple longer prefix responses, or

  2. Alert the operator that the order of queries will determine which answers get cached, and either warn and continue or treat this as an error and refuse to load the configuration.

...

When deaggregating to correct the overlap, prefix lengths should be optimized to use the minimum necessary to cover the address space, in order to reduce the overhead that results from having multiple copies of the same answer. As a trivial example, if the Tailored Response for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then the Authoritative Nameserver would need to provide Tailored Responses for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and 1.2.3/24 to B.