Pedoman Subnet Klien (DNS) EDNS

Pengantar

RFC 7871 – Subnet Klien di Kueri DNS – menentukan mekanisme untuk resolver rekursif seperti Google Public DNS untuk mengirim informasi alamat IP klien parsial ke server nama DNS yang kredibel. Jaringan Penayangan Konten (CDN) dan layanan yang sensitif terhadap latensi menggunakan ini untuk memberikan respons lokasi geografis yang akurat saat merespons pencarian nama yang masuk melalui resolver DNS publik.

RFC menjelaskan fitur ECS yang harus diterapkan oleh server nama otoritatif; tetapi pelaksana tidak selalu mengikuti persyaratan tersebut. Ada juga masalah operasional dan deployment ECS yang tidak ditangani RFC yang dapat menyebabkan masalah untuk resolver seperti Google Public DNS yang mendeteksi dukungan ECS secara otomatis di server nama otoritatif, serta resolver yang memerlukan daftar yang diizinkan ECS, seperti OpenDNS.

Panduan ini dimaksudkan untuk membantu operator dan operator DNS resmi menghindari banyak kesalahan umum yang dapat menyebabkan masalah untuk ECS.

Definisi Istilah

Kami menggunakan istilah berikut untuk menjelaskan operasi ECS:

  • Server nama menerapkan (atau mendukung) ECS jika membalas kueri ECS dengan respons ECS yang memiliki opsi ECS yang cocok (meskipun opsi ECS selalu memiliki panjang awalan cakupan /0 global).

  • Zona akan diaktifkan ECS jika kueri ECS ke server namanya dikirim dengan awalan sumber bukan nol menerima respons ECS dengan cakupan bukan nol.

Panduan untuk Server Nama yang Diotorisasi

  1. Semua server nama resmi untuk zona yang mengaktifkan ECS harus mengaktifkan ECS untuk zona tersebut.

    • Meskipun hanya satu server nama yang tidak menerapkan ECS atau mengaktifkannya untuk zona, server nama ini dengan cepat menjadi sumber data yang paling di-cache. Karena responsnya memiliki cakupan global, cakupan tersebut digunakan (hingga TTL-nya berakhir) sebagai respons terhadap semua kueri untuk nama yang sama (terlepas dari subnet klien). Respons dari server yang menerapkan ECS dan mengaktifkannya hanya digunakan untuk kueri dari klien dalam cakupan tertentu, sehingga cenderung tidak digunakan dibandingkan respons cakupan global.

  2. Server nama otoritatif yang menerapkan ECS MUST2 mengirimkan respons ECS ke kueri ECS untuk semua zona yang disalurkan dari alamat IP atau nama host NS, bahkan untuk zona yang tidak diaktifkanCS.

    • Google Public DNS mendeteksi dukungan ECS secara otomatis berdasarkan alamat IP, bukan nama host server nama atau zona DNS, karena jumlah alamat lebih kecil daripada jumlah nama host server nama dan jauh lebih kecil daripada jumlah zona DNS. Jika server nama otoritatif tidak selalu mengirim respons ECS ke kueri EEC (bahkan untuk zona yang tidak mengaktifkan ECS), Google Public DNS dapat berhenti mengirimkan kueri ECS kepadanya.

  3. Server nama otoritatif yang menerapkan ECS harus merespons semua kueri ECS dengan respons ECS, termasuk respons negatif dan rujukan.

    • Masalah yang sama tentang deteksi otomatis dukungan ECS juga berlaku di sini.

    • Respons negatif (NXDOMAIN dan NODATA) SHOULD3 menggunakan cakupan global/0 untuk caching dan kompatibilitas yang lebih baik dengan RFC 7871.

    • Selain NXDOMAIN dan NODATA (NOERROR dengan bagian jawaban kosong), respons error lain pada kueri ECS (terutama SERVFAILED dan REFUSED) harus menyertakan opsi ECS yang cocok dengan cakupan global /0.

      • Jika server nama otoritatif mencoba menghapus beban dari serangan DoS, server tersebut dapat menampilkan SERVFAILED tanpa data ECS; hal ini akan berulang kali menyebabkan Google Public DNS berhenti mengirim kueri dengan ECS (yang dapat mengurangi jumlah kueri sah yang dikirimkannya, tetapi tidak akan memengaruhi kueri serangan subdomain secara acak). Mengurangi pemuatan kueri yang sah selama serangan DoS mungkin atau mungkin tidak meningkatkan tingkat keberhasilan kueri yang sah (meskipun respons dapat disalurkan dari cache untuk semua klien).

        Pendekatan pelepasan beban yang lebih efektif adalah mengirim semua respons dengan cakupan global /0 sehingga Google Public DNS terus mengirim kueri EEC. Hal ini memungkinkan Google Public DNS menampilkan respons berdasarkan lokasi geografis banyak segera setelah serangan berhenti, karena tidak perlu mendeteksi ulang dukungan ECS, hanya untuk mengkueri ulang setelah TTL respons cakupan global berakhir.

    • Respons rujukan (delegasi) juga harus memiliki data ECS yang cocok dan HARUS4 menggunakan cakupan /0 global. Perhatikan bahwa respons delegasi tidak pernah diteruskan ke klien yang alamatnya muncul di data ECS, sehingga semua data NS, A, atau AAAA yang berlokasi geografis harus dipilih oleh alamat IP klien resolver, bukan data ECS.

  4. Server nama otoritatif yang menerapkan ECS harus menyertakan opsi ECS yang cocok sebagai respons terhadap semua jenis kueri yang diterima dengan opsi ECS. Tindakan ini tidak cukup baik untuk merespons kueri alamat IPv4 (A) dengan data ECS; respons terhadap A, AAAA, PTR, MX, atau jenis kueri lainnya harus memiliki data atau resolver ECS yang cocok dapat menghapus respons sebagai respons yang mungkin dipalsukan, dan Google Public DNS dapat berhenti mengirim kueri dengan data ECS.

    Secara khusus, respons ECS ke kueri SOA, NS, dan DS harus selalu menggunakan cakupan /0 global untuk caching yang lebih baik dan tampilan delegasi yang konsisten (respons yang berlokasi geografis untuk kueri A/AAAA untuk nama host server nama tidak masalah). Respons untuk semua jenis kueri (misalnya TXT, PTR, dll) yang tidak berubah berdasarkan data ECS tidak boleh menggunakan cakupan yang sama dengan panjang awalan sumber, harus menggunakan cakupan /0 global untuk caching yang lebih baik dan mengurangi beban kueri.

  5. Server nama otoritatif yang menampilkan respons CNAME yang mendukung ECS SHOULD5 hanya menyertakan CNAME pertama dalam rantai, dan target akhir rantai CNAME harus mengaktifkan ECS ke panjang awalan cakupan yang sama. Karena ambiguitas dalam spesifikasi ECS, beberapa resolver rekursif (terutama Tidak Terikat6) dapat menampilkan respons dengan cakupan domain non-CNAME final (/0 jika tidak diaktifkan ECS).

  6. Data ECS dapat berisi alamat IPv6 bahkan untuk server nama khusus IPv4 (dan sebaliknya, meskipun server nama khusus IPv6 jarang ditemukan).

    • Server nama harus merespons dengan data opsi ECS yang valid (/cakupan 0 dapat digunakan, tetapi alamat sumber dan panjang awalan harus cocok).

    • ECS untuk zona dapat diaktifkan secara terpisah untuk alamat IPv4 dan IPv6.

  7. Server nama otoritatif yang menampilkan respons berkemampuan ECS HARUS TIDAK7 awalan cakupan tumpang-tindih dalam jawaban mereka. Contoh awalan cakupan yang tumpang-tindih adalah sebagai berikut:

    • Kueri dengan awalan sumber 198.18.0.0/15: respons A dengan awalan cakupan 198.0.0.0/8

    • Kueri dengan awalan sumber 198.51.100/24: respons B dengan awalan cakupan 198.51.0.0/16

    Jika klien mengkueri resolver rekursif berkemampuan ECS dalam urutan di atas, kedua kueri tersebut mungkin mendapatkan respons A, karena cakupan respons yang di-cache A menyertakan cakupan awalan kueri kedua. Meskipun kueri klien dibuat dalam urutan yang berlawanan, dan kedua kueri diteruskan ke server nama yang kredibel, respons yang di-cache dapat berakhir pada waktu yang berbeda; kueri berikutnya ke resolver rekursif dalam awalan yang tumpang-tindih 198.51.100/24 bisa mendapatkan respons A atau B.

  8. Saat menerapkan dukungan ECS untuk pertama kalinya pada server nama, gunakan alamat IP yang baru untuk server nama yang menayangkan zona yang diaktifkan ECS ini.

    • Saat server nama resmi yang menerapkan ECS, tetapi menampilkan hasil cakupan global, mulai menampilkan jawaban yang diaktifkan ECS untuk zona, DNS Publik Google mulai menampilkan respons berdasarkan lokasi geografis ke kueri segera setelah TTL dari respons cakupan global sebelumnya berakhir.

    • Deteksi otomatis DNS Publik Google dari dukungan ECS sangat jarang mencoba kueri ECS untuk alamat IP (atau nama host server nama) jika tidak ada dukungan ECS yang terdeteksi secara otomatis (waktu tunggu habis, pengembalian FORMERR, BADVERS, atau pengiriman respons non-ECS). Implementasi ECS baru pada alamat IP tersebut (atau nama host NS) dideteksi secara otomatis dengan sangat lambat, atau tidak sama sekali.

  9. Pastikan koneksi jaringan dapat diandalkan dan semua batas respons yang ditetapkan cukup tinggi sehingga server nama tidak menghapus kueri (atau lebih buruk lagi, respons dengan error yang tidak memiliki opsi ECS yang cocok).

    • Untuk server nama yang menerapkan pembatasan rasio respons pada kueri ECS, respons terbaik adalah NODATA dengan tanda truncation (TC) yang ditetapkan, yang hanya berisi bagian pertanyaan yang cocok dan opsi ECS yang cocok.

  10. Kirim respons tepat waktu ke semua kueri (idealnya dalam 1 detik).

    • Penggunaan layanan pencarian Geo-IP online untuk kueri ECS tidak akan berfungsi dengan baik, karena latensi kumulatif kueri DNS dan layanan Geo-IP online tidak mungkin terjadi dalam satu detik. Deteksi otomatis Google Public DNS dari dukungan ECS menganggap respons tertunda sebagai indikasi dukungan ECS yang buruk atau tidak lengkap, dan mengurangi kemungkinan kueri di masa mendatang dikirim dengan ECS. Jika respons cukup tertunda, tindakan tersebut akan berhenti mengirimkan kueri ECS.

Referensi RFC 7871 dan catatan kaki lainnya

1 https://tools.ASPMX.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.ASPMX.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.ASPMX.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.ASPMX.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.ASPMX.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-Mei/003875.html

Penggunaan cakupan domain final dalam rantai CNAME tidak berbahaya dalam Unbound, karena biasanya di-deploy sebagai stub lokal atau resolver penerusan, dengan semua klien berada di subnet yang sama dan akan mendapatkan respons yang sama.

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