DNSSEC (DNS Security Extensions) menambahkan tanda tangan digital pada record DNS sehingga resolver dapat memverifikasi bahwa suatu jawaban benar-benar berasal dari pemilik domain dan tidak diubah di tengah jalan. DNSSEC tidak mengenkripsi apa pun; ia membuktikan keaslian lewat chain of trust (rantai kepercayaan) yang berawal dari root DNS.
DNS biasa tidak punya cara untuk membedakan jawaban asli dari jawaban palsu. DNSSEC, yang distandarkan dalam RFC 4033, 4034, dan 4035, menutup celah itu. Panduan ini menjelaskan jenis-jenis record yang terlibat, cara kerja validasi, dan kesalahan yang paling sering membuat domain bertanda tangan menjadi tidak dapat diakses.
Masalah yang diselesaikan DNSSEC
Resolver rekursif menerima jawaban pertama yang cocok dengan pertanyaannya. Penyerang yang bisa menyisipkan respons palsu, baik dengan berada di jalur jaringan maupun dengan memenangkan balapan melawan server asli dalam serangan cache poisoning, dapat mengarahkan pengguna resolver tersebut ke alamat IP pilihannya. Semua orang yang memakai resolver itu akan mendapat jawaban palsu sampai entri di cache kedaluwarsa.
DNSSEC membuat pemalsuan dapat terdeteksi. Setiap set record ditandatangani dengan private key milik zona, dan public key yang cocok dipublikasikan di DNS. Resolver yang melakukan validasi memeriksa tanda tangan dan menolak apa pun yang tidak terverifikasi. Jika Anda perlu menyegarkan pemahaman tentang resolver dan server otoritatif terlebih dahulu, baca apa itu DNS dan cara kerjanya.
Jenis record DNSSEC
| Record | Berada di | Fungsi |
|---|---|---|
DNSKEY | Zona yang ditandatangani | Public key yang dipakai untuk memverifikasi tanda tangan zona |
RRSIG | Zona yang ditandatangani | Tanda tangan atas satu set record (misalnya semua record A untuk sebuah nama), lengkap dengan waktu mulai dan akhir masa berlaku |
DS | Zona induk | Delegation Signer: hash dari key-signing key milik zona anak, yang menghubungkan induk dengan anak |
NSEC | Zona yang ditandatangani | Membuktikan bahwa suatu nama atau jenis record tidak ada dengan menyebutkan nama berikutnya yang ada sesuai urutan sortir |
NSEC3 | Zona yang ditandatangani | Sama seperti NSEC tetapi dengan nama yang di-hash (RFC 5155), sehingga lebih sulit untuk mendaftar semua nama dalam zona |
CDS / CDNSKEY | Zona yang ditandatangani | Memberi tahu zona induk record DS mana yang harus dipublikasikan, sehingga pembaruan dapat diotomatiskan (RFC 7344) |
Panduan kami tentang jenis record DNS membahas record biasa, seperti A, MX, dan TXT, yang dilindungi oleh tanda tangan ini.
Mengapa pembuktian ketiadaan diperlukan
Tanpa NSEC atau NSEC3, penyerang dapat memalsukan respons NXDOMAIN ("nama ini tidak ada"), yang tidak dapat membawa tanda tangannya sendiri karena tidak ada record yang bisa ditandatangani. Record NSEC memberi resolver pernyataan bertanda tangan bahwa tidak ada apa pun di antara dua nama, sehingga penyangkalan pun dapat diverifikasi.
Key-signing key dan zone-signing key
Sebagian besar zona memakai dua jenis key, yang keduanya dipublikasikan sebagai record DNSKEY:
- Zone-signing key (ZSK), flag DNSKEY
256: menandatangani set record biasa milik zona. Key ini dapat sering diganti tanpa melibatkan pihak lain. - Key-signing key (KSK), flag DNSKEY
257: hanya menandatangani set record DNSKEY. Hash-nya yang dimasukkan ke dalam record DS di zona induk, sehingga penggantiannya mengharuskan pembaruan di registrar.
Pemisahan peran ini membuat penggantian key rutin tetap berada di penyedia DNS Anda, sedangkan penggantian KSK yang lebih jarang adalah satu-satunya yang menyentuh zona induk. Sebagian konfigurasi memakai satu combined signing key sebagai gantinya, yang lebih sederhana dan umum dengan algoritma kurva eliptik modern seperti algoritma 13 (ECDSA P-256 dengan SHA-256).
Chain of trust
Tanda tangan hanya berguna jika resolver memercayai key yang membuatnya. DNSSEC membangun kepercayaan itu langkah demi langkah dari root, yang ditandatangani pada tahun 2010. Resolver yang melakukan validasi membawa KSK zona root sebagai trust anchor bawaan. Untuk memvalidasi www.example.com, resolver:
- Memakai trust anchor root untuk memverifikasi set DNSKEY milik root.
- Memverifikasi record DS bertanda tangan untuk
comdi zona root, lalu memeriksa apakah cocok dengan KSK di set DNSKEY milikcom. - Memverifikasi record DS bertanda tangan untuk
example.comdi zonacom, lalu memeriksa apakah cocok dengan KSK yang dipublikasikan olehexample.com. - Memakai set DNSKEY milik
example.comuntuk memverifikasi RRSIG atas record A milikwww.example.com.
Jika setiap mata rantai terverifikasi, jawabannya secure (aman). Jika zona induk tidak memiliki record DS untuk suatu zona, zona itu insecure (tidak bertanda tangan) dan jawabannya dikembalikan seperti biasa. Jika DS ada tetapi tanda tangannya tidak terverifikasi, jawabannya bogus.
Seperti apa hasil validasi: AD dan SERVFAIL
Ketika resolver yang melakukan validasi berhasil memverifikasi sebuah jawaban, ia mengatur flag AD (Authenticated Data) dalam respons. Anda bisa melihatnya dengan dig:
$ dig +dnssec www.example.com A @1.1.1.1
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
www.example.com. 300 IN A 192.0.2.10
www.example.com. 300 IN RRSIG A 13 3 300 20261101000000 20261011000000 12345 example.com. (signature data)Ketika validasi gagal, resolver tidak mengembalikan data yang mungkin palsu. Ia mengembalikan SERVFAIL, yang bagi pengguna tampak sama dengan situs yang tidak ada atau gangguan DNS. Untuk memastikan DNSSEC penyebabnya, ulangi kueri dengan pemeriksaan dinonaktifkan:
dig www.example.com A # status: SERVFAIL
dig +cd www.example.com A # status: NOERROR, jawaban dikembalikanJika kueri +cd (checking disabled) berhasil sedangkan kueri biasa gagal, berarti DNSSEC zona tersebut rusak. Cek DNSSEC kami menjalankan pemeriksaan ini untuk Anda dan menampilkan status DS, DNSKEY, dan tanda tangan.
Cara DNSSEC biasanya rusak
Pindah penyedia DNS tanpa menghapus record DS
Inilah kegagalan klasik. Record DS di registry masih menunjuk ke KSK milik penyedia lama. Setelah name server diganti, penyedia baru menyajikan zona tanpa tanda tangan atau menandatanganinya dengan key yang berbeda. Resolver yang melakukan validasi menemukan DS tanpa key yang cocok, menandai zona sebagai bogus, dan setiap pencarian mengembalikan SERVFAIL.
Migrasi yang aman berjalan seperti ini:
- Di registrar, hapus record DS.
- Tunggu sampai DS lama kedaluwarsa dari cache: setidaknya selama TTL record DS di zona induk, yang dapat Anda lihat dengan
dig example.com DS. Menunggu satu atau dua hari adalah batas aman yang lazim. - Ganti name server ke penyedia baru dan tunggu sampai record NS lama kedaluwarsa.
- Aktifkan DNSSEC di penyedia baru dan publikasikan record DS barunya di registrar.
Beberapa penyedia mendukung konfigurasi multi-signer yang menghindari masa tanpa tanda tangan, tetapi hal itu membutuhkan kerja sama antara kedua penyedia.
Tanda tangan kedaluwarsa
Setiap RRSIG memiliki waktu kedaluwarsa. Jika proses penandatanganan berhenti, misalnya pada server yang dikelola sendiri dengan job penandatanganan ulang yang gagal, tanda tangan pada akhirnya kedaluwarsa dan zona menjadi bogus.
Penggantian key yang terlalu cepat
Menghapus key lama sebelum cache mengambil key baru menyebabkan kegagalan pada resolver yang masih menyimpan set DNSKEY atau record DS lama. Penggantian key harus menghormati TTL yang terlibat.
Cara mengaktifkan DNSSEC untuk domain Anda
- Pastikan TLD Anda mendukung DNSSEC; sebagian besar TLD generik dan banyak TLD kode negara mendukungnya.
- Aktifkan penandatanganan DNSSEC di penyedia hosting DNS Anda. Penyedia akan membuat key dan menandatangani zona.
- Salin detail record DS (key tag, algoritma, jenis digest, dan digest) ke pengaturan DNSSEC di registrar Anda. Jika penyedia dan registrar Anda adalah perusahaan yang sama, langkah ini sering berjalan otomatis, dan sebagian registry mengambil record CDS secara otomatis.
- Verifikasi hasilnya dengan Cek DNSSEC kami dan pastikan pencarian biasa masih berfungsi dengan Cek DNS.
Pertanyaan yang sering diajukan
Apakah DNSSEC mengenkripsi kueri DNS saya?
Tidak. DNSSEC menyediakan keaslian dan integritas, bukan privasi. Kueri dan jawaban tetap terlihat di jaringan. Enkripsi berasal dari DNS over TLS atau DNS over HTTPS, yang melengkapi DNSSEC.
Apakah saya memerlukan DNSSEC jika situs saya memakai HTTPS?
Sertifikat HTTPS sudah mencegah jawaban DNS palsu menyamar sebagai situs Anda secara diam-diam, tetapi DNSSEC juga melindungi perutean email, record TXT yang dipakai untuk verifikasi, dan record lainnya. DNSSEC juga diperlukan untuk DANE, yang mempublikasikan informasi sertifikat TLS di DNS.
Mengapa domain saya berfungsi di sebagian jaringan tetapi tidak di jaringan lain?
Jika DNSSEC rusak, hanya resolver yang melakukan validasi yang mengembalikan SERVFAIL; resolver yang tidak melakukan validasi tetap menjawab. Itu membuat gangguan tampak bergantung pada jaringan.
Bagaimana cara mematikan DNSSEC dengan aman?
Hapus record DS di registrar terlebih dahulu, tunggu sampai kedaluwarsa dari cache, dan baru kemudian berhenti menandatangani zona. Melakukannya dengan urutan sebaliknya menyebabkan gangguan.