Manfaat Keamanan

Pengantar: Ancaman dan mitigasi keamanan DNS

Karena desain Sistem Nama Domain yang terbuka dan terdistribusi, serta penggunaannya atas User Datagram Protocol (UDP), DNS rentan terhadap berbagai bentuk serangan. Risiko DNS rekursif atau publik bersifat "terbuka" atau sangat berisiko, karena tidak membatasi paket yang masuk ke sekumpulan alamat IP sumber yang diizinkan. Kami terutama khawatir dengan dua jenis serangan umum:

  • Serangan spoofing yang menyebabkan poisoning cache DNS. Berbagai jenis spoofing dan eksploitasi pemalsuan DNS berlimpah, yang bertujuan untuk mengalihkan pengguna dari situs sah ke situs berbahaya. Hal ini termasuk yang disebut serangan Kaminsky, saat penyerang mengambil kontrol yang sah atas seluruh zona DNS.
  • Serangan Denial-of-service (DoS). Penyerang mungkin meluncurkan serangan DDoS terhadap resolver itu sendiri, atau membajak resolver untuk meluncurkan serangan DoS pada sistem lain. Serangan yang menggunakan server DNS untuk meluncurkan serangan DoS pada sistem lain dengan memanfaatkan ukuran respons/data DNS besar dikenal sebagai serangan amplifikasi.

Setiap class serangan dibahas lebih lanjut di bawah ini.

Serangan keracunan cache

Ada beberapa varian serangan spoofing DNS yang dapat mengakibatkan keracunan cache, tetapi skenario umumnya adalah sebagai berikut:

  1. Penyerang mengirimkan beberapa kueri DNS target untuk nama domain yang diketahui server tersebut tidak berwenang, dan kecil kemungkinannya untuk berada di cache server.
  2. Resolver mengirimkan permintaan ke server nama lain (yang alamat IP-nya juga dapat diprediksi oleh penyerang).
  3. Sementara itu, penyerang akan memenuhi server korban dengan respons palsu yang tampak berasal dari server nama yang didelegasikan. Respons berisi data yang pada akhirnya menyelesaikan domain yang diminta ke alamat IP yang dikontrol oleh penyerang. File ini mungkin berisi data jawaban untuk nama yang di-resolve atau, lebih buruk lagi, token tersebut dapat mendelegasikan otoritas delegasi ke server nama yang dimiliki oleh penyerang, sehingga mereka dapat mengontrol seluruh zona.
  4. Jika salah satu respons palsu cocok dengan permintaan resolver (misalnya, berdasarkan nama kueri, jenis, ID, dan port sumber resolver) dan diterima sebelum respons dari server nama asli, resolver akan menerima respons palsu dan meng-cache-nya, dan menghapus respons asli.
  5. Kueri berikutnya untuk domain atau zona yang disusupi akan dijawab dengan resolusi DNS palsu dari cache. Jika penyerang telah menentukan waktu aktif yang sangat lama pada respons palsu, catatan palsu akan tetap berada dalam cache selama mungkin tanpa pembaruan.

Untuk mengetahui pengantar terbaik terkait serangan Kaminsky, lihat Panduan Ilustrasi tentang Kerentanan DNS Kaminsky.

Serangan DoS dan amplifikasi

Resolver DNS tunduk pada ancaman DoS biasa yang mengganggu semua sistem jaringan. Namun, serangan amplifikasi menjadi perhatian khusus karena resolver DNS adalah target menarik bagi penyerang yang mengeksploitasi resolver dan rasio ukuran respons terhadap permintaan yang besar untuk mendapatkan bandwidth gratis tambahan. Resolver yang mendukung EDNS0 (Extension Mechanisms untuk DNS) sangat rentan karena ukuran paket yang jauh lebih besar yang dapat ditampilkan.

Dalam skenario amplifikasi, serangan dilakukan sebagai berikut:

  1. Penyerang mengirimkan kueri server DNS korban menggunakan alamat IP sumber palsu. Kueri dapat dikirim dari satu sistem atau jaringan sistem, semuanya menggunakan alamat IP palsu yang sama. Kueri ini ditujukan untuk data yang diketahui penyerang akan menghasilkan respons yang jauh lebih besar, hingga beberapa puluh kali1, ukuran kueri asli (yaitu nama "amplifikasi" serangan).
  2. Server korban mengirimkan respons besar ke alamat IP sumber yang diteruskan dalam permintaan palsu, yang membebani sistem dan menyebabkan situasi DoS.

Mitigasi

Solusi standar sistem untuk kerentanan DNS adalah DNSSEC. Namun, hingga diterapkan secara universal, resolver DNS terbuka harus mengambil beberapa tindakan secara independen untuk mengurangi ancaman yang diketahui. Banyak teknik yang telah diusulkan; lihat IETF RFC 5452: Langkah-langkah untuk membuat DNS lebih tahan terhadap jawaban palsu untuk ringkasan sebagian besar teknik tersebut. Di Google Public DNS, kami telah menerapkan dan merekomendasikan pendekatan berikut:

  • Mengamankan kode Anda dari buffer overflow, terutama kode yang bertanggung jawab untuk mengurai dan membuat serialisasi pesan DNS.
  • Resource mesin yang terlalu banyak disediakan untuk melindungi dari serangan DoS langsung pada resolver itu sendiri. Karena alamat IP sepele bagi penyerang untuk dipalsukan, tidak mungkin untuk memblokir kueri berdasarkan alamat IP atau subnet; satu-satunya cara efektif untuk menangani serangan semacam itu adalah dengan hanya menyerap beban.
  • Menerapkan pemeriksaan validitas dasar paket respons dan kredibilitas server nama untuk melindungi dari keracunan cache sederhana. Ini adalah mekanisme standar dan pemeriksaan kesehatan yang harus dilakukan oleh resolver cache yang sesuai dengan standar.
  • Menambahkan entropi untuk meminta pesan, guna mengurangi kemungkinan serangan poisoning spoofing/cache yang lebih canggih seperti serangan Kaminsky. Ada banyak teknik yang disarankan untuk menambahkan entropi. Di bawah ini, kami memberikan ringkasan manfaat, batasan, dan tantangan dari setiap teknik tersebut, dan membahas cara kami menerapkannya di Google Public DNS.
  • Menghapus kueri duplikat, untuk mengatasi kemungkinan quot;serangan ulang tahun".
  • Permintaan pembatasan kapasitas, untuk mencegah serangan DoS dan amplifikasi.
  • Memantau layanan untuk IP klien menggunakan bandwidth terbanyak dan mengalami rasio ukuran respons terhadap permintaan tertinggi.

DNSSEC

Standar Domain Name Security Extensions (DNSSEC) ditetapkan dalam beberapa RFC IETF: 4033, 4034, 4035, dan 5155.

Resolver yang menerapkan serangan keracunan cache DNSSEC DNSSEC dengan memverifikasi keaslian respons yang diterima dari server nama. Setiap zona DNS memiliki sekumpulan pasangan kunci pribadi/publik dan untuk setiap data DNS, tanda tangan digital unik akan dihasilkan dan dienkripsi menggunakan kunci pribadi tersebut. Selanjutnya, kunci publik yang sesuai akan diautentikasi melalui rantai kepercayaan oleh kunci yang termasuk dalam zona induk. Resolver yang sesuai dengan DNSSEC menolak respons yang tidak berisi tanda tangan yang benar. DNSSEC efektif mencegah respons dirusak, karena dalam praktiknya, tanda tangan hampir tidak mungkin dipalsukan tanpa akses ke kunci pribadi.

Mulai Januari 2013, Google Public DNS sepenuhnya mendukung DNSSEC. Kami menerima dan meneruskan pesan berformat DNSSEC serta memvalidasi respons untuk autentikasi yang benar. Kami sangat menganjurkan resolver lain untuk melakukan hal yang sama.

Kami juga menyimpan respons NSEC dalam cache seperti yang ditentukan dalam IETF RFC 8198: Aggressive Use of DNSSEC-Validated Cache. Hal ini dapat mengurangi kueri NXDOMAIN ke server nama yang menerapkan DNSSEC dan menggunakan NSEC untuk jawaban negatif.

Transportasi terenkripsi sisi klien

Google Public DNS menawarkan dukungan untuk protokol transportasi terenkripsi, DNS over HTTPS, dan DNS over TLS. Protokol ini mencegah gangguan, penyadapan dan spoofing, yang sangat meningkatkan privasi dan keamanan antara klien dan Google Public DNS. DNS melengkapi DNSSEC untuk memberikan pencarian DNS yang diautentikasi secara menyeluruh.

Menerapkan pemeriksaan validitas dasar

Beberapa kerusakan cache DNS dapat disebabkan oleh ketidaksesuaian yang tidak disengaja dan tidak selalu berbahaya antara permintaan dan respons (misalnya, mungkin karena server nama yang salah dikonfigurasi, bug pada software DNS, dan sebagainya). Setidaknya, resolver DNS harus melakukan pemeriksaan untuk memverifikasi kredibilitas dan relevansi server nama. Kami merekomendasikan (dan mengimplementasikan) semua pertahanan berikut:

  • Jangan tetapkan bit rekursif dalam permintaan keluar, dan selalu ikuti rantai delegasi secara eksplisit. Menonaktifkan bit rekursif memastikan bahwa resolver Anda beroperasi dalam mode "iteratif" sehingga Anda dapat membuat kueri setiap server nama dalam rantai delegasi secara eksplisit, bukan mengizinkan server nama lain untuk menjalankan kueri ini atas nama Anda.
  • Tolak pesan respons yang mencurigakan. Lihat di bawah untuk mengetahui detail tentang hal yang kami anggap "mencurigakan".
  • Jangan tampilkan data A ke klien berdasarkan glue record yang di-cache dari permintaan sebelumnya. Misalnya, jika Anda menerima kueri klien untuk ns1.example.com, Anda harus menyelesaikan masalah alamat tersebut, bukan mengirim data A berdasarkan glue record yang di-cache yang ditampilkan dari server nama TLD .com.

Menolak respons yang tidak memenuhi kriteria yang diperlukan

Google Public DNS menolak semua hal berikut:

  • Respons yang tidak dapat diurai atau tidak dapat diurai.
  • Respons yang kolom kuncinya tidak cocok dengan kolom yang sesuai dalam permintaan. Ini mencakup ID kueri, IP sumber, port sumber, IP tujuan, atau nama kueri. Lihat RFC 5452, Bagian 3 untuk mengetahui deskripsi lengkap perilaku spoofing DNS.
  • Rekaman yang tidak relevan dengan permintaan.
  • Data jawaban yang rantai CNAME-nya tidak dapat kami buat ulang.
  • Data (dalam jawaban, otoritas, atau bagian tambahan) yang tidak kredibel oleh server nama yang merespons. Kami menentukan "kredibilitas" server nama berdasarkan tempatnya di rantai delegasi untuk domain tertentu. Google Public DNS meng-cache informasi rantai delegasi, dan kami memverifikasi setiap respons masuk terhadap informasi yang di-cache untuk menentukan kredibilitas server nama yang merespons untuk menanggapi permintaan tertentu.

Menambahkan entropi ke permintaan

Setelah resolver melakukan pemeriksaan kesehatan dasar, penyerang harus memenuhi resolver korban dengan respons untuk mencocokkan ID kueri, port UDP (dari permintaan), alamat IP (dari respons), dan nama kueri dari permintaan asli sebelum server nama yang sah melakukannya.

Sayangnya, pencapaian ini sulit dicapai, karena satu-satunya kolom pengidentifikasi yang unik, ID kueri, hanya sepanjang 16 bit (yaitu untuk peluang 1/65.536 dalam melakukannya dengan benar). Kolom lain juga memiliki rentang yang terbatas, sehingga jumlah total kombinasi unik relatif rendah. Lihat RFC 5452, Bagian 7 untuk penghitungan kombinatorik yang terlibat.

Oleh karena itu, tantangannya adalah menambahkan entropi sebanyak mungkin ke paket permintaan, sesuai dengan format standar pesan DNS, agar lebih sulit bagi penyerang untuk mencocokkan kombinasi kolom yang valid dengan jendela peluang. Kami merekomendasikan, dan telah menerapkan, semua teknik yang dibahas di bagian berikut.

Kami mempresentasikan ulasan yang diperbarui tentang teknik yang disebutkan di sini pada konferensi DNS OARC 38 pada Juli 2022. Presentasi ini juga mencakup rekomendasi untuk operator server nama.

Mengacak port sumber

Sebagai langkah dasar, jangan pernah izinkan paket permintaan keluar menggunakan port UDP 53 default, atau menggunakan algoritme yang dapat diprediksi untuk menetapkan beberapa port (misalnya penambahan sederhana). Gunakan rentang port yang luas mulai dari 1.024 hingga 65.535 yang diizinkan di sistem Anda, dan gunakan generator angka acak yang andal untuk menetapkan port. Misalnya, Google Public DNS menggunakan ~15 bit, untuk menerima sekitar 32.000 nomor port yang berbeda.

Perhatikan bahwa jika server Anda di-deploy di belakang firewall, load balancer, atau perangkat lain yang menjalankan terjemahan alamat jaringan (NAT), perangkat tersebut dapat membatalkan pengacakan port pada paket keluar. Pastikan Anda mengonfigurasi perangkat NAT untuk menonaktifkan pengacakan port.

Mengacak pilihan server nama

Beberapa resolver, saat mengirimkan permintaan ke root, TLD, atau server nama lainnya, memilih alamat IP server nama berdasarkan jarak terpendek (latensi). Sebaiknya Anda mengacak alamat IP tujuan untuk menambahkan entropi pada permintaan keluar. Di Google Public DNS, kami cukup memilih server nama secara acak di antara server nama yang dikonfigurasi untuk setiap zona, sehingga lebih memilih server nama yang cepat dan andal.

Jika khawatir dengan latensi, Anda dapat menggunakan banding waktu round-trip (RTT), yang terdiri dari pengacakan dalam rentang alamat yang berada di bawah ambang batas latensi tertentu (misalnya 30 md, 300 md, dll.).

Cookie DNS

RFC 7873 menentukan opsi EDNS0 untuk menambahkan cookie 64-bit ke pesan DNS. Klien DNS yang mendukung klien menyertakan cookie 64-bit acak dan secara opsional (jika diketahui) cookie server dalam permintaan. Jika server pendukung menemukan bahwa opsi cookie valid dalam permintaan, mencerminkan cookie klien dan cookie server yang benar dalam respons. Klien pendukung kemudian dapat memverifikasi respons yang berasal dari server yang diharapkan dengan memverifikasi cookie klien dalam respons.

Jika server nama tidak mendukung cookie DNS, dua opsi berikut dapat digunakan untuk menambahkan entropi.

Mengacak kasus dalam nama kueri

Standar DNS mewajibkan server nama memperlakukan nama dengan ketidakpekaan huruf besar/kecil. Misalnya, nama example.com dan EXAMPLE.COM harus ditetapkan ke alamat IP yang sama2. Selain itu, semua minoritas server nama akan menggemakan kembali nama dalam respons, seperti yang muncul dalam permintaan, mempertahankan kasus asli.

Oleh karena itu, cara lain untuk menambahkan entropi ke permintaan adalah dengan secara acak memvariasikan huruf besar/kecil dalam nama domain yang dikueri. Teknik ini, juga dikenal sebagai "0x20" karena bit 0x20 digunakan untuk menetapkan kasus huruf US-ASCII, pertama kali diusulkan dalam draf internet Internet IETF Use of Bit 0x20 in DNS Labels to Meningkatkan Transaction Identity. Dengan teknik ini, respons server nama tidak hanya harus cocok dengan nama kueri, tetapi juga kasus dari setiap huruf dalam string nama; misalnya, wWw.eXaMpLe.CoM atau WwW.ExamPLe.COm. Tindakan ini dapat menambahkan sedikit atau tidak ada entropi pada kueri untuk domain level teratas dan root, tetapi entropi ini efektif untuk sebagian besar nama host.

Salah satu tantangan signifikan yang kami temukan saat menerapkan teknik ini adalah bahwa beberapa server nama tidak mengikuti perilaku respons yang diharapkan:

  • Beberapa server nama merespons dengan ketidakpekaan huruf besar/kecil: mereka menampilkan hasil yang sama dengan benar terlepas dari huruf besar/kecil dalam permintaan, tetapi respons tidak sesuai dengan kasus nama yang sama persis dalam permintaan.
  • Server nama lain merespons dengan sensitivitas huruf besar/kecil (melanggar standar DNS): server menangani nama yang setara secara berbeda, bergantung pada kasus dalam permintaan, gagal membalas sama sekali atau menampilkan respons NXDOMAIN yang salah yang cocok dengan kasus nama secara tepat dalam permintaan.
  • Beberapa server nama berfungsi dengan benar kecuali untuk kueri PTR di zona arpa.

Untuk kedua jenis server nama ini, mengubah kasus nama kueri akan menghasilkan hasil yang tidak diinginkan: untuk grup pertama, responsnya tidak dapat dibedakan dengan respons palsu; untuk grup kedua, responsnya (jika ada) bisa benar-benar salah.

Solusi kami saat ini untuk masalah ini adalah menggunakan pengacakan kasus hanya untuk server nama yang kami tahu menerapkan standar dengan benar. Kami juga mencantumkan subdomain pengecualian yang sesuai untuk setiap subdomain, berdasarkan analisis log kami. Jika respons yang tampaknya berasal dari server tersebut tidak berisi kasus yang benar, kami akan menolak respons tersebut. Server nama yang diaktifkan menangani lebih dari 70% traffic keluar kami.

Menambahkan label nonce ke nama kueri

Jika resolver tidak dapat langsung me-resolve nama dari cache, atau tidak dapat langsung membuat kueri ke server nama otoritatif, maka resolver harus mengikuti rujukan dari server nama root atau TLD. Dalam sebagian besar kasus, permintaan ke server nama root atau TLD akan menghasilkan rujukan ke server nama lain, bukan upaya untuk me-resolve nama ke alamat IP. Oleh karena itu, untuk permintaan semacam itu, sebaiknya Anda melampirkan label acak ke nama kueri untuk meningkatkan entropi permintaan, sekaligus tidak mengambil risiko untuk menyelesaikan nama yang tidak ada. Artinya, mengirim permintaan ke server nama perujuk untuk nama yang diawali dengan label nonce, seperti entriih-f10r3.www.google.com, harus menampilkan hasil yang sama dengan permintaan untuk www.google.com.

Meskipun dalam praktiknya permintaan tersebut berjumlah kurang dari 3% dari permintaan keluar, dengan asumsi traffic normal (karena sebagian besar kueri dapat dijawab langsung dari cache atau oleh satu kueri), ini adalah jenis permintaan yang diperlukan oleh penyerang untuk memaksakan penyelesaian masalah. Oleh karena itu, teknik ini bisa sangat efektif dalam mencegah eksploitasi gaya Kaminsky.

Menerapkan teknik ini mengharuskan label nonce hanya digunakan untuk permintaan yang dijamin menghasilkan rujukan; yaitu, respons yang tidak berisi catatan di bagian jawaban. Namun, kami menemukan beberapa tantangan saat mencoba menentukan kumpulan permintaan tersebut:

  • Beberapa server nama TLD (ccTLD) dengan kode negara sebenarnya bersifat otoritatif untuk TLD (2LD) tingkat kedua lainnya. Meskipun memiliki dua label, 2LD berperilaku seperti TLD, itulah sebabnya 2LD sering kali ditangani oleh server nama ccTLD. Misalnya, server nama .uk juga bersifat otoritatif untuk zona mod.uk dan nic.uk, sehingga nama host yang terdapat dalam zona tersebut, seperti www.nic.uk, www.mod.uk, dan sebagainya. Dengan kata lain, permintaan ke server nama ccTLD untuk penyelesaian nama host tersebut tidak akan menghasilkan rujukan, tetapi dalam jawaban yang otoritatif; menambahkan label nonce ke nama host tersebut akan menyebabkan nama menjadi tidak dapat diselesaikan.
  • Terkadang server nama TLD (gTLD) generik menampilkan respons tidak resmi untuk server nama. Artinya, ada beberapa nama host server nama yang kebetulan berada di zona gTLD, bukan di zona untuk domain mereka. gTLD akan menampilkan jawaban yang tidak resmi untuk nama host ini, menggunakan glue record apa pun yang kebetulan ada di database-nya, bukan menampilkan rujukan. Misalnya, server nama ns3.indexonlineserver.com sebelumnya berada di zona gTLD .COM, bukan di zona indexonlineserver.com. Saat mengajukan permintaan ke server gTLD untuk n3.indexonlineserver.com, kami mendapatkan alamat IP untuknya, bukan rujukan. Namun, jika menambahkan label nonce, kita mendapatkan rujukan ke indexonlineserver.com, yang kemudian tidak dapat me-resolve nama host. Oleh karena itu, kami tidak dapat menambahkan label nonce untuk server nama yang memerlukan resolusi dari server gTLD.
  • Otoritas untuk zona dan hostname berubah dari waktu ke waktu. Hal ini dapat menyebabkan nama host yang tidak ditambahkan di awal yang dapat di-resolve menjadi tidak dapat diselesaikan jika rantai delegasi berubah.

Untuk mengatasi tantangan ini, kami mengonfigurasi pengecualian untuk nama host yang tidak dapat kami tambahkan dengan label nonce. Ini adalah nama host yang server respons TLD-nya menampilkan respons non-rujukan, sesuai dengan log server kami. Kami terus meninjau daftar pengecualian untuk memastikan daftar tersebut tetap valid dari waktu ke waktu.

Menghapus kueri duplikat

Resolver DNS rentan terhadap "serangan ulang tahun", sehingga dipanggil karena mengeksploitasi "paradoks ulang tahun" matematika, yang kemungkinan kecocokannya tidak memerlukan input dalam jumlah besar. Serangan ulang tahun melibatkan banjir pada server korban tidak hanya dengan respons palsu tetapi juga dengan kueri awal, yang mengandalkan resolver untuk mengeluarkan beberapa permintaan untuk resolusi nama tunggal. Semakin besar jumlah permintaan keluar, semakin besar kemungkinan penyerang akan cocok dengan salah satu permintaan tersebut dengan respons palsu: penyerang hanya memerlukan urutan 300 permintaan penayangan untuk memperoleh keberhasilan 50% dalam mencocokkan respons palsu, dan 700 permintaan untuk hampir berhasil 100%.

Untuk menghindari strategi serangan ini, Anda harus memastikan untuk menghapus semua kueri duplikat dari antrean keluar. Misalnya, Google Public DNS, tidak pernah mengizinkan lebih dari satu permintaan yang belum terselesaikan untuk nama kueri, jenis kueri, dan alamat IP tujuan yang sama.

Kueri yang membatasi kapasitas

Mencegah serangan denial-of-service menimbulkan beberapa tantangan tertentu untuk resolver DNS rekursif terbuka:

  • Resolver rekursif terbuka adalah target yang menarik untuk meluncurkan serangan amplifikasi. Server ini berkapasitas tinggi dan memiliki keandalan tinggi serta dapat menghasilkan respons lebih besar dibandingkan server nama otoritatif biasa, terutama jika penyerang dapat memasukkan respons besar ke dalam cache-nya. Developer layanan DNS terbuka harus mencegah server mereka digunakan untuk meluncurkan serangan ke sistem lain.
  • Serangan penguatan dapat sulit dideteksi saat terjadi. Penyerang dapat meluncurkan serangan melalui ribuan resolver terbuka, sehingga setiap penyelesaian hanya melihat sebagian kecil dari keseluruhan volume kueri dan tidak dapat mengekstrak sinyal yang jelas bahwa itu telah disusupi.
  • Traffic berbahaya harus diblokir tanpa gangguan atau penghentian layanan DNS untuk pengguna biasa. DNS adalah layanan jaringan yang sangat penting, sehingga menonaktifkan server untuk menghentikan serangan tidak dapat dilakukan, dan juga tidak menolak layanan ke IP klien tertentu untuk terlalu lama. Resolver harus dapat memblokir serangan dengan cepat segera setelah dimulai, dan memulihkan layanan yang beroperasi sepenuhnya setelah serangan berakhir.

Pendekatan terbaik untuk melawan serangan DoS adalah dengan menerapkan mekanisme pembatasan kapasitas atau quot;throttling". Google Public DNS mengimplementasikan dua jenis kontrol tarif:

  • Pengontrolan kapasitas permintaan keluar ke server nama lainnya. Untuk melindungi server nama DNS lainnya terhadap serangan DoS yang dapat diluncurkan dari server resolver kami, Google Public DNS menerapkan batas QPS pada permintaan keluar dari setiap cluster penayangan untuk setiap alamat IP server nama.

  • Kontrol rasio respons keluar untuk klien. Untuk melindungi sistem lainnya terhadap amplifikasi dan serangan DoS (botnet) terdistribusi tradisional yang dapat diluncurkan dari server resolver kami, Google Public DNS melakukan dua jenis pembatasan kapasitas pada kueri klien:

    • Untuk melindungi dari serangan berbasis volume tradisional, setiap server menerapkan QPS per IP klien dan batas bandwidth rata-rata.
    • Untuk melindungi dari serangan amplifikasi, di mana respons yang besar terhadap kueri kecil dimanfaatkan, setiap server menerapkan faktor amplifikasi rata-rata per klien IP. Faktor amplifikasi rata-rata adalah rasio ukuran respons terhadap kueri yang dapat dikonfigurasi, yang ditentukan dari pola traffic historis yang diamati dalam log server kami.

    Jika kueri DNS dari satu alamat IP sumber melampaui tingkat QPS maksimum, kueri berlebih akan dihapus. Jika kueri DNS melalui UDP dari satu alamat IP sumber melampaui batas bandwidth atau amplifikasi rata-rata secara konsisten (respons besar yang sesekali akan diteruskan), kueri mungkin akan dihapus atau hanya respons kecil yang dapat dikirim. Respons kecil mungkin berupa respons error atau respons kosong dengan bit pemotongan yang ditetapkan (sehingga sebagian besar kueri yang sah akan dicoba ulang melalui TCP dan berhasil). Tidak semua sistem atau program akan mencoba lagi melalui TCP, dan DNS melalui TCP dapat diblokir oleh firewall di sisi klien, sehingga beberapa aplikasi mungkin tidak beroperasi dengan benar saat balasan terpotong. Meskipun demikian, pemotongan memungkinkan klien yang sesuai dengan RFC untuk berfungsi dengan benar dalam sebagian besar kasus.

  1. Lihat contoh Serangan Penguatan DNS sebagai contoh, dan diskusi yang baik tentang masalah secara umum. ↩

  2. RFC 1034, Pasal 3.5 berbunyi: ↩

    Perhatikan bahwa meskipun huruf besar dan kecil diizinkan dalam nama domain, tidak ada signifikansi yang dilampirkan pada kasus tersebut. Artinya, dua nama dengan ejaan yang sama tetapi menggunakan huruf besar/kecil harus diperlakukan sama.