Hướng dẫn về mạng con của máy khách EDNS (ECS)

Giới thiệu

RFC 7871 – Mạng con máy khách trong truy vấn DNS – xác định cơ chế cho các trình phân giải định kỳ như DNS công khai của Google để gửi một phần thông tin địa chỉ IP của ứng dụng khách đến các máy chủ định danh DNS có thẩm quyền. Mạng phân phối nội dung (CDN) và các dịch vụ nhạy cảm về độ trễ sử dụng tính năng này để cung cấp các phản hồi chính xác theo vị trí địa lý khi phản hồi các yêu cầu tra cứu tên thông qua trình phân giải DNS công khai.

RFC mô tả các tính năng của ECS mà các máy chủ định danh đáng tin cậy phải triển khai; nhưng trình triển khai không phải lúc nào cũng tuân thủ các yêu cầu đó. Ngoài ra, còn có các vấn đề về việc vận hành và triển khai ECS mà RFC không giải quyết được, có thể gây ra vấn đề cho các trình phân giải như DNS Google Public có chức năng tự động phát hiện tính năng hỗ trợ ECS trong các máy chủ định danh có thẩm quyền, cũng như các trình phân giải yêu cầu danh sách cho phép ECS, như OpenDNS.

Các nguyên tắc này nhằm giúp trình triển khai và toán tử DNS đáng tin cậy tránh được nhiều lỗi phổ biến có thể gây ra sự cố cho ECS.

Định nghĩa về các thuật ngữ

Chúng tôi sử dụng các thuật ngữ sau đây để mô tả hoạt động của ECS:

  • Máy chủ định danh triển khai (hoặc hỗ trợ) ECS nếu máy chủ trả lời các truy vấn ECS bằng các phản hồi ECS có tùy chọn ECS phù hợp (ngay cả khi các tùy chọn ECS luôn có độ dài tiền tố phạm vi toàn cầu /0).

  • Một khu vực được bật ECS nếu các truy vấn ECS đến các máy chủ định danh của ứng dụng được gửi với tiền tố nguồn khác 0 sẽ nhận được phản hồi ECS có phạm vi khác 0.

Nguyên tắc dành cho máy chủ định danh được ủy quyền

  1. Tất cả máy chủ định danh có thẩm quyền cho vùng hỗ trợ ECS phải bật ECS cho vùng đó.

    • Ngay cả khi chỉ có một máy chủ định danh không triển khai ECS hoặc bật dịch vụ này cho vùng, thì máy chủ định danh đó sẽ nhanh chóng trở thành nguồn của hầu hết dữ liệu được lưu vào bộ nhớ đệm. Vì phản hồi có phạm vi toàn cầu nên chúng được sử dụng (cho đến khi thời gian tồn tại (TTL) của chúng hết hạn) làm phản hồi cho tất cả truy vấn có cùng tên (bất kể mạng con của máy khách nào). Phản hồi từ các máy chủ có triển khai ECS và bật tính năng này chỉ được dùng cho các truy vấn từ ứng dụng khách trong phạm vi cụ thể, vì vậy, chúng ít có khả năng được sử dụng hơn so với phản hồi của phạm vi toàn cầu.

  2. Các máy chủ định danh được ủy quyền triển khai ECS PHẢI2 gửi phản hồi ECS tới các truy vấn ECS cho tất cả các vùng được phân phát từ địa chỉ IP hoặc tên máy chủ NS, ngay cả đối với các vùng không được bật ECS.

    • Google Public DNS tự động phát hiện dịch vụ hỗ trợ ECS theo địa chỉ IP thay vì dùng tên máy chủ định danh hoặc vùng DNS của máy chủ vì số lượng địa chỉ nhỏ hơn số lượng tên máy chủ của máy chủ định danh và nhỏ hơn nhiều so với số lượng vùng DNS. Nếu máy chủ định danh có thẩm quyền không luôn gửi phản hồi ECS cho các truy vấn ECS (ngay cả đối với các khu vực chưa bật ECS), thì DNS công khai của Google có thể ngừng gửi các truy vấn ECS.

  3. Các máy chủ định danh có thẩm quyền triển khai ECS phải phản hồi mọi truy vấn ECS bằng các phản hồi ECS, bao gồm cả phản hồi phủ định và phản hồi giới thiệu.

    • Những vấn đề tương tự về hỗ trợ tự động phát hiện ECS cũng được áp dụng tại đây.

    • Phản hồi phủ định (NXDOMAIN và NODATA) KHÔNG3 sử dụng phạm vi toàn bộ /0 để lưu vào bộ nhớ đệm và khả năng tương thích tốt hơn với RFC 7871.

    • Bên cạnh NXDOMAIN và NODATA (NOERROR với phần câu trả lời trống), các phản hồi lỗi khác cho các cụm từ tìm kiếm ECS (đặc biệt là SERVJCT và REFUSED) phải bao gồm một tùy chọn ECS phù hợp có phạm vi toàn cầu /0.

      • Nếu một máy chủ định danh có thẩm quyền đang cố gắng giảm tải từ một cuộc tấn công DoS, thì máy chủ định danh đó có thể trả về một SERVJCT mà không có dữ liệu ECS; việc này liên tục khiến DNS công khai của Google ngừng gửi các truy vấn bằng ECS (điều này có thể làm giảm số lượng truy vấn hợp lệ mà các máy chủ này gửi nhưng không ảnh hưởng đến các truy vấn miền con ngẫu nhiên). Việc giảm số lượt truy vấn hợp lệ trong một cuộc tấn công vào DoS có thể giúp cải thiện tỷ lệ thành công cho các truy vấn hợp lệ (mặc dù các phản hồi có thể được phân phát từ bộ nhớ đệm cho tất cả khách hàng).

        Một phương pháp hiệu quả hơn để giảm tải là gửi tất cả phản hồi có phạm vi /0 toàn cục để DNS công khai của Google tiếp tục gửi truy vấn ECS. Điều này cho phép Google Public DNS trả về các phản hồi được định vị địa lý nhiều ngay sau khi cuộc tấn công dừng lại, vì hệ thống không cần phải phát hiện lại khả năng hỗ trợ ECS, mà chỉ cần truy vấn lại sau khi TTL phản hồi phạm vi toàn cầu hết hạn.

    • Các phản hồi giới thiệu (ủy quyền) cũng phải có dữ liệu ECS phù hợp và KHÔNG4 sử dụng phạm vi /0 toàn cục. Lưu ý rằng các phản hồi ủy quyền không bao giờ được chuyển tiếp đến các ứng dụng khách có địa chỉ xuất hiện trong dữ liệu ECS, vì vậy, mọi bản ghi NS, A hoặc AAAA được định vị địa lý phải được chọn theo địa chỉ IP của ứng dụng trình phân giải, chứ không phải dữ liệu ECS.

  4. Các máy chủ định danh được ủy quyền triển khai ECS phải bao gồm một tuỳ chọn ECS phù hợp trong các phản hồi cho tất cả các loại truy vấn nhận được bằng tuỳ chọn ECS. Không đủ để phản hồi truy vấn địa chỉ IPv4 (A) bằng dữ liệu ECS; các phản hồi cho A, AAAA, PTR, MX hoặc mọi loại truy vấn khác phải có dữ liệu ECS phù hợp hoặc trình phân giải có thể bỏ nội dung phản hồi dưới dạng nội dung phản hồi có thể bị giả mạo, và DNS Google Public có thể ngừng gửi truy vấn bằng dữ liệu ECS.

    Cụ thể, phản hồi ECS cho các truy vấn SOA, NS và DS phải luôn sử dụng phạm vi toàn bộ /0 để lưu vào bộ nhớ đệm tốt hơn và chế độ xem ủy quyền nhất quán (các phản hồi được định vị địa lý cho các truy vấn A/AAAA cho tên máy chủ máy chủ định danh là OK). Phản hồi cho mọi loại truy vấn (ví dụ: TXT, PTR, v.v.) không thay đổi dựa trên dữ liệu ECS không được sử dụng phạm vi bằng với độ dài tiền tố nguồn, chúng nên sử dụng phạm vi /0 chung để lưu vào bộ nhớ đệm tốt hơn và giảm tải truy vấn.

  5. Các máy chủ định danh được ủy quyền trả về phản hồi CNAME đã bật ECS KHÔNG5 chỉ bao gồm CNAME đầu tiên trong chuỗi và mục tiêu cuối cùng của chuỗi CNAME phải được bật ECS để có cùng độ dài tiền tố phạm vi. Do sự không rõ ràng trong thông số kỹ thuật ECS, một số trình phân giải định kỳ (đặc biệt là Không ràng buộc6) có thể trả về phản hồi có phạm vi của miền không phải CNAME cuối cùng (/0 nếu không được bật ECS).

  6. Dữ liệu ECS có thể chứa địa chỉ IPv6 ngay cả đối với máy chủ định danh chỉ có IPv4 (và ngược lại, mặc dù rất hiếm máy chủ định danh chỉ có IPv6).

    • Máy chủ định danh cần phải phản hồi bằng dữ liệu tùy chọn ECS hợp lệ (/0 phạm vi là được, nhưng địa chỉ nguồn và độ dài tiền tố phải khớp).

    • Bạn có thể bật riêng ECS cho một vùng cho địa chỉ IPv4 và IPv6.

  7. Các máy chủ định danh có thẩm quyền trả về phản hồi hỗ trợ ECS PHẢI KHÔNG7 chồng chéo tiền tố phạm vi trong câu trả lời. Ví dụ về các tiền tố phạm vi trùng lặp như sau:

    • Truy vấn có tiền tố nguồn 198.18.0.0/15: phản hồi A với tiền tố phạm vi 198.0.0.0/8

    • Truy vấn có tiền tố nguồn 198.51.100/24: phản hồi B có tiền tố phạm vi 198.51.0.0/16

    Nếu ứng dụng truy vấn trình phân giải định kỳ hỗ trợ ECS theo thứ tự trên, thì cả hai truy vấn đều có thể nhận được phản hồi A, vì phạm vi của phản hồi đã lưu vào bộ nhớ đệm A bao gồm phạm vi tiền tố của truy vấn thứ hai. Ngay cả khi các truy vấn ứng dụng được thực hiện theo thứ tự ngược lại và cả hai truy vấn này đều được chuyển tiếp đến các máy chủ định danh có thẩm quyền, các phản hồi được lưu vào bộ nhớ đệm có thể hết hạn vào các thời điểm khác nhau; các truy vấn tiếp theo tới trình phân giải đệ quy trong tiền tố trùng lặp 198.51.100/24 có thể nhận được phản hồi A hoặc B.

  8. Khi triển khai hỗ trợ ECS lần đầu trên máy chủ định danh, hãy sử dụng địa chỉ IP mới cho máy chủ định danh phục vụ các vùng bật ECS này.

    • Khi các máy chủ định danh có thẩm quyền đã triển khai ECS nhưng trả về kết quả phạm vi toàn cầu bắt đầu trả về câu trả lời đã bật ECS cho một vùng, DNS công khai của Google sẽ bắt đầu trả về các phản hồi được định vị địa lý cho các truy vấn ngay khi TTL của các phản hồi phạm vi toàn cầu trước đó đã hết hạn.

    • Tính năng tự động phát hiện DNS công khai của Google hỗ trợ ECS rất hiếm khi thử các truy vấn ECS cho một địa chỉ IP (hoặc tên máy chủ của máy chủ định danh) khi dịch vụ này tự động phát hiện không hỗ trợ ECS (thời gian chờ, trả về FORMERR, BADVERS hoặc gửi phản hồi không phải ECS). Việc triển khai ECS mới trên các địa chỉ IP đó (hoặc tên máy chủ NS) được tự động phát hiện rất chậm hoặc hoàn toàn không phát hiện được.

  9. Hãy đảm bảo rằng kết nối mạng đáng tin cậy và mọi giới hạn về tốc độ phản hồi được đặt đủ cao để máy chủ định danh không bỏ qua các cụm từ tìm kiếm (hoặc tệ hơn là phản hồi lỗi thiếu tùy chọn ECS phù hợp).

    • Đối với các máy chủ định danh triển khai giới hạn tốc độ phản hồi trên các truy vấn ECS, phản hồi tốt nhất là NODATA với tập hợp cờ cắt ngắn (TC) chỉ chứa một phần câu hỏi phù hợp và một tuỳ chọn ECS phù hợp.

  10. Gửi câu trả lời kịp thời cho tất cả các truy vấn (tốt nhất là trong vòng 1 giây).

    • Việc sử dụng dịch vụ tra cứu IP-Địa lý trực tuyến cho các truy vấn ECS sẽ không hoạt động ổn định, vì độ trễ tích luỹ của truy vấn DNS và dịch vụ Địa lý IP trực tuyến khó có thể nằm trong vòng một giây. Tính năng tự động phát hiện DNS công khai của Google hỗ trợ ECS sẽ xem xét các phản hồi bị chậm trễ là dấu hiệu cho thấy hỗ trợ ECS kém hoặc chưa hoàn chỉnh, và làm giảm khả năng các truy vấn trong tương lai được gửi bằng ECS. Nếu có đủ phản hồi, thì quá trình sẽ ngừng gửi các truy vấn ECS.

Tài liệu tham khảo RFC 7871 và các chú thích cuối trang khác

1 https://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.

3 https://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.

4 https://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.

5 https://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.

6 https://unbound.net/pipermail/unbound-users/2015–Tháng 5/003875.html

Việc sử dụng phạm vi của miền cuối cùng trong chuỗi CNAME là vô hại trong Unbound, vì miền này thường được triển khai dưới dạng trình phân giải chuyển tiếp hoặc trình phân giải chuyển tiếp cục bộ, trong đó tất cả ứng dụng đều nằm trong cùng một mạng con và sẽ nhận được cùng một phản hồi.

7 https://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.