UDP memberi DNS transport dengan overhead rendah, tetapi source address dapat dipalsukan dan balasannya dapat ditiru oleh pengirim off-path. DNS Cookies menambahkan sedikit state yang dibuat klien dan, setelah kontak dengan server yang mendukungnya, state yang dibuat server. Mekanisme ini menaikkan biaya pemalsuan off-path tanpa mengharuskan server menyimpan tabel sesi untuk setiap klien.

Cakupannya sengaja terbatas. RFC 7873 mendeskripsikan DNS Cookies sebagai keamanan transaksi ringan terhadap serangan denial-of-service, amplifikasi, pemalsuan, dan cache poisoning dari pihak off-path. Mekanisme ini tidak melindungi dari pihak yang dapat mengamati pertukaran DNS. RFC 9018 kemudian memperketat konstruksi cookie agar server anycast dengan implementasi berbeda dapat saling beroperasi.

DNS Cookies menggunakan EDNS option code 10. Klien yang belum memiliki Server Cookie mengirim Client Cookie sepanjang delapan byte. Setelah menerima Server Cookie, request berikutnya dapat membawa kedua nilai.

request pertama:
  Client Cookie

response server:
  Client Cookie | Server Cookie

request berikutnya:
  Client Cookie | Server Cookie

Kedua field melayani arah pertukaran yang berbeda. Client Cookie memberi klien nilai yang dapat diperiksa pada balasan. Server Cookie memberi server bukti bahwa pengirim pada source address yang terlihat sebelumnya menerima response yang terkait dengan Client Cookie tersebut.

Client Cookie harus berbeda untuk IP server yang berbeda. RFC 9018 menetapkan Client Cookie 64-bit dengan entropi 64 bit dan merekomendasikan penyimpanannya bersama Server Cookie terkait selama IP klien tetap stabil.

Server Cookie bukan sekadar token acak yang disimpan dalam tabel lookup. Konstruksinya dapat mengikat nilai itu secara kriptografis ke input yang dapat diperoleh kembali oleh server ketika request berikutnya tiba.

RFC 9018 mendefinisikan format interoperabel dengan version, reserved field, timestamp, dan hash:

Server Cookie =
  Version | Reserved | Timestamp | Hash

Untuk versi yang didefinisikan, hash menggunakan HMAC-SHA-256 yang dipotong menjadi 64, 128, 192, atau 256 bit. Input-nya mencakup Client Cookie, version, reserved field, timestamp, dan IP klien. Server dapat menghitung ulang nilai dari secret miliknya dan konteks request, alih-alih menyimpan state cookie untuk setiap klien.

Properti ini penting bagi infrastruktur authoritative yang menerima volume traffic UDP besar. Pemeriksaan validitas dapat tetap terikat pada server secret dan metadata request tanpa membuat alokasi berumur panjang bagi setiap source address.

Pengirim off-path dapat menempatkan alamat korban pada source field request UDP. Tanpa pemeriksaan tambahan, response DNS dikirim ke korban tersebut.

Server Cookie mengubah state yang berguna bagi pengirim seperti itu. Untuk menyertakan cookie valid bagi alamat palsu dan Client Cookie terkait, pengirim memerlukan nilai yang dibuat untuk konteks tersebut. Response yang membawa nilai itu dikirim menuju source address yang diklaim, bukan menuju pengirim off-path yang memakai alamat lain.

Ini menjadi dasar pembatasan amplifikasi dari request palsu. Server dapat menerapkan penanganan lebih ketat ketika request tidak memiliki Server Cookie valid dan pemrosesan normal ketika cookie yang dikenali tersedia. RFC 7873 mengizinkan pilihan kebijakan seperti membuang request, mengembalikan BADCOOKIE, atau memprosesnya ketika hanya Client Cookie yang diberikan.

Mekanisme ini tidak menjadikan alamat IP sebagai identitas. Sinyal yang diberikan adalah indikasi return-routability yang lemah untuk pertukaran terkini.

BADCOOKIE memulai atau menyegarkan state server

Klien mungkin belum memiliki Server Cookie, atau nilai cache dapat menjadi tidak valid setelah rotasi secret, perubahan alamat, atau konfigurasi anycast yang tidak konsisten. Protokol menyediakan jalur pemulihan eksplisit.

Server dapat mengembalikan response yang berisi Client Cookie dan Server Cookie baru. Ketika extended response code adalah BADCOOKIE, klien dengan Client Cookie yang cocok dapat mencoba kembali memakai Server Cookie baru tersebut.

klien -> server : Client Cookie + Server Cookie lama
server -> klien : BADCOOKIE + Server Cookie baru
klien -> server : Client Cookie + Server Cookie baru

RFC 7873 juga menetapkan perilaku fallback yang melibatkan TCP ketika percobaan dengan cookie yang baru diberikan tetap menerima BADCOOKIE. Dengan demikian, ketidakcocokan cookie tidak langsung diperlakukan sebagai kegagalan DNS permanen.

Anycast dapat mengarahkan paket berturut-turut untuk satu alamat server ke instance backend yang berbeda. Jika instance tersebut tidak dapat memvalidasi Server Cookie satu sama lain, klien dapat masuk ke siklus refresh berulang meskipun tetap menghubungi IP yang sama.

RFC 9018 menangani persoalan interoperabilitas ini dengan mendefinisikan konstruksi Server Cookie bersama. Server dalam satu set anycast tetap memerlukan perilaku pengelolaan secret yang kompatibel agar cookie dapat divalidasi lintas node. Spesifikasi tersebut juga memberi panduan untuk rotasi secret.

Persyaratan ini bersifat operasional, bukan model trust baru. DNS Cookies tetap terikat pada konteks jaringan yang terlihat; penanganan anycast bersama menjaga konteks tersebut tetap dapat digunakan ketika routing mengganti instance backend.

NAT diperhitungkan dengan menggabungkan alamat dan state klien

Banyak klien dapat terlihat memakai satu alamat NAT publik. Server Cookie yang hanya didasarkan pada alamat tersebut akan memberi semua klien di belakang NAT token return-routability yang sama.

DNS Cookies menghindari desain itu dengan memasukkan Client Cookie ke komputasi Server Cookie. Klien di belakang alamat terjemahan yang sama karena itu dapat membawa nilai berbeda yang diterbitkan server.

Hal ini tidak mengisolasi host berbahaya yang berbagi jalur jaringan dalam setiap kondisi. Namun, server tidak mereduksi seluruh klien di belakang satu alamat terjemahan menjadi satu nilai cookie hanya karena IP eksternalnya identik.

Cookies tidak menggantikan DNSSEC atau DNS terenkripsi

DNS Cookies tidak mengautentikasi record DNS sebagai data bertanda tangan. DNSSEC menyediakan autentikasi asal dan integritas bagi data DNS bertanda tangan melalui chain of trust; DNS Cookies menangani persoalan tingkat transaksi yang berbeda.

Mekanisme ini juga tidak menyediakan kerahasiaan. Pengamat on-path dapat melihat traffic DNS plaintext biasa beserta cookie yang dibawanya. RFC 7873 secara eksplisit mengecualikan perlindungan terhadap pihak on-path dari batas keamanan mekanisme ini.

Batas tersebut penting dalam deployment. DNS Cookies berguna sebagai filter ringan terhadap spoofing dan amplifikasi off-path, terutama melalui UDP, tetapi bukan pengganti umum untuk autentikasi record, transport terenkripsi, TSIG, atau SIG(0). Nilai keamanannya berasal dari properti yang lebih sempit: request atau reply dapat membawa state terkini yang tidak dapat begitu saja diturunkan oleh pengirim off-path dari header DNS yang terlihat dan source address palsu.

Keamanan Siber DNS DNS Cookies UDP Keamanan Jaringan