UDP membuat DNS efisien, tetapi source address dapat dipalsukan oleh pengirim off-path. Query kecil yang membawa alamat korban dapat memicu response yang lebih besar menuju korban tersebut, sehingga terbentuk reflection dan amplification. Response palsu juga relevan bagi resolver karena penyerang dapat mencoba menyisipkan jawaban sebelum response yang sah tiba.

DNS Cookies menambahkan token transaksi ringan pada batas ini. RFC 7873 menetapkan option COOKIE pada EDNS, sedangkan RFC 9018 memperbarui konstruksi sisi server agar implementasi dapat saling beroperasi, termasuk pada deployment anycast multi-vendor. Cakupan mekanisme ini sengaja terbatas: mekanisme tersebut menaikkan biaya pemalsuan off-path, tetapi bukan enkripsi, autentikasi data DNS, atau perlindungan dari adversary yang dapat mengamati traffic pada jalur.

Client yang mendukung DNS Cookies mengirim Client Cookie delapan byte dalam option COOKIE. RFC 9018 menetapkan bahwa nilainya perlu sulit ditebak, merekomendasikan entropi 64 bit, dan mewajibkan Client Cookie yang berbeda untuk setiap IP address server.

Pertukaran pertama dapat digambarkan sebagai berikut:

client                                      server
  |                                            |
  | query + Client Cookie -------------------> |
  |                                            |
  | <--- response + Client Cookie + Server Cookie
  |                                            |
  | query + Client Cookie + Server Cookie ---> |

Client memeriksa bahwa response membawa Client Cookie yang diharapkan. Sistem off-path yang tidak dapat mengamati pertukaran harus menebak nilai tersebut untuk membuat response palsu yang lolos pemeriksaan ini.

Client Cookie bukan kredensial bersama. Server tidak memerlukan provisioning awal secret milik client, dan setiap client dapat memilih konstruksinya sendiri. Deployment tetap terpisah dari identitas akun atau autentikasi aplikasi.

Setelah menerima Client Cookie, server yang mendukung mekanisme ini mengembalikan Server Cookie. Pada query berikutnya, client mengirim kedua nilai. Server kemudian dapat memvalidasi bahwa token sesuai dengan source address request yang terlihat dan Client Cookie terkait.

RFC 9018 menetapkan Server Cookie version 1 yang interoperable. Field hash dihitung dengan SipHash-2-4 atas Client Cookie, field version dan reserved, timestamp, serta IP address client, dengan Server Secret sebagai key. Server Cookie version 1 lengkap berukuran 16 byte, sehingga request yang membawa Client Cookie delapan byte beserta Server Cookie tersebut memiliki option COOKIE 24 byte.

Desain ini dapat tetap stateless terhadap masing-masing client. Server yang memiliki secret dapat menghitung ulang nilai yang diharapkan tanpa menyimpan session record untuk setiap requester. Properti ini berguna pada skala DNS, ketika state bergaya handshake untuk source UDP arbitrer dapat menjadi titik tekanan resource tambahan.

Validasi mengubah keputusan amplification

Nilai keamanannya muncul ketika server membedakan request dengan Server Cookie valid dari request yang hanya mengklaim suatu source IP address.

Penyerang off-path dapat mengirim query awal dengan alamat korban yang dipalsukan, tetapi Server Cookie yang dihasilkan menuju korban, bukan penyerang. Tanpa mengamati response tersebut, penyerang tidak memiliki token yang diperlukan untuk menunjukkan penerimaan pada alamat yang diklaim. Server karena itu dapat menerapkan perilaku response yang lebih ketat pada request tanpa cookie valid.

RFC 7873 menggambarkannya sebagai perlindungan terbatas terhadap DNS amplification, pemalsuan denial-of-service, dan upaya cache poisoning dari penyerang off-path. Enforcement cookie dapat membatasi request palsu menjadi error response pendek yang terkena rate limit, alih-alih membiarkannya memicu jawaban besar menuju korban.

Hal ini tidak membuat setiap response DNS berukuran besar menjadi aman. Kebijakan deployment, response-rate control, exposure recursion, perilaku EDNS, dan hardening DNS lain tetap relevan. DNS Cookies menyediakan satu sinyal: bukti bahwa requester sebelumnya menerima token server pada source address yang direpresentasikan oleh pertukaran tersebut.

Anycast memerlukan validasi yang konsisten

RFC 7873 merekomendasikan penggunaan Server Secret yang sama pada node dalam satu anycast set, tetapi algoritma cookie masih banyak diserahkan kepada implementasi. Kondisi tersebut menimbulkan masalah interoperabilitas: satu node dapat menerbitkan cookie yang tidak dapat divalidasi implementasi lain pada anycast address yang sama.

RFC 9018 menangani masalah tersebut dengan menetapkan konstruksi version 1 dan mewajibkan implementasi Server Cookie menggunakannya. Server Secret harus dapat dikonfigurasi agar node dalam deployment anycast dapat menghasilkan hasil validasi yang konsisten.

Rotasi secret juga memerlukan koordinasi. RFC 9018 menjelaskan transisi bertahap: secret baru didistribusikan sebelum dipakai untuk menghasilkan cookie, sedangkan secret sebelumnya tetap diterima sementara untuk verifikasi. Pola ini mencegah perubahan routing anycast normal berubah menjadi kegagalan cookie yang sebenarnya dapat dihindari selama rotasi.

Batas perlindungan berhenti pada pengamat on-path

DNS Cookies berjalan di dalam pesan DNS dan tidak memberikan confidentiality. Adversary yang dapat mengamati pertukaran dapat melihat nilai cookie dan berada di luar threat model off-path yang menjadi sumber manfaat utama mekanisme ini.

DNS Cookies juga tidak menggantikan DNSSEC. DNSSEC mengautentikasi data DNS bertanda tangan melalui trust model miliknya; DNS Cookies memberi resistansi ringan pada level transaksi terhadap pemalsuan off-path. TSIG dan SIG(0) juga melayani use case authenticated-message yang berbeda.

NAT membentuk batas lain. Beberapa client dapat terlihat menggunakan satu external address. RFC 7873 membahas kondisi ketika host di belakang NAT yang sama dapat memperoleh Server Cookie yang terkait dengan external address tersebut. Pemeriksaan Client Cookie tetap menambah resistansi terhadap response palsu, tetapi sinyal source address tidak segranular satu host internal.

Token kecil membentuk prasyarat yang berguna

DNS Cookies tidak mengubah UDP menjadi transport yang terautentikasi. Properti pentingnya lebih sempit: server dapat meminta bukti bahwa requester menerima token sebelumnya pada source address yang diklaim, sementara client dapat mensyaratkan token acaknya sendiri kembali bersama response.

Prasyarat tersebut ringan, dapat diterapkan secara bertahap, kompatibel dengan NAT dan anycast bila diimplementasikan dengan tepat, serta berfokus pada pola penyalahgunaan DNS yang umum. Untuk reflection off-path dan pemalsuan response, memaksa penyerang memiliki nilai yang dikirim melalui jalur jaringan sebenarnya mengubah blind spoofing menjadi masalah yang memerlukan informasi yang semestinya tidak dimiliki penyerang.

Cybersecurity DNS DNS Cookies DDoS Network Security