Gunakan DNSSEC lanjutan

Halaman ini menyediakan beberapa opsi konfigurasi Domain Name System Security Extensions (DNSSEC) lanjutan yang dapat digunakan jika Anda mengaktifkan DNSSEC untuk zona terkelola. Opsi ini bervariasi, mulai dari berbagai algoritma penandatanganan dan denial-of-eksistensi, hingga kemampuan untuk menggunakan jenis data yang memerlukan atau merekomendasikan DNSSEC untuk penggunaannya.

Untuk mengetahui ringkasan konseptual DNSSEC, lihat ringkasan DNSSEC.

Mendelegasikan subdomain yang ditandatangani DNSSEC

Anda dapat mengaktifkan DNSSEC untuk subdomain yang didelegasikan setelah mengaktifkan DNSSEC untuk domain primer. Guna mengaktifkan DNSSEC untuk subdomain yang didelegasikan, buat data DS dalam zona Cloud DNS terlebih dahulu. Anda juga harus membuat satu atau beberapa data NS.

Agar dapat membuat data DS untuk subdomain yang didelegasikan, Anda harus mendapatkan data DS untuk zona tersebut. Jika zona yang didelegasikan juga dihosting di Cloud DNS, Anda bisa mendapatkan data DS dari Konsol Google Cloud atau dari Google Cloud CLI.

Konsol

1. Di konsol Google Cloud, buka halaman Cloud DNS.

   Buka Cloud DNS

2. Buka zona terkelola yang data DS-nya ingin Anda lihat.

3. Untuk melihat data DS untuk zona tersebut, di pojok kanan atas halaman Zone details, klik Registrar Setup.

4. Data DS tersedia di halaman Registrar Setup.

5. Untuk membuat data NS, ikuti petunjuk di Menambahkan data.

gcloud

1. Guna mendapatkan informasi data DS untuk subdomain yang didelegasikan, jalankan perintah berikut:

   gcloud dns dns-keys list --zone EXAMPLE_ZONE
   

   Ganti EXAMPLE_ZONE dengan nama zona DNS subdomain yang didelegasikan di project Anda.

   Outputnya akan terlihat seperti berikut:

   ID  KEY_TAG  TYPE          IS_ACTIVE  DESCRIPTION
   0   1234     KEY_SIGNING   True
   1   12345    ZONE_SIGNING  True
   

2. Untuk mendapatkan data DS lengkap dan semua detail kunci, Anda memerlukan ID Kunci KEY_SIGNING (KSK), yang biasanya nol (0). Jalankan perintah berikut:

   gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \
      --format "value(ds_record())"
   

   Ganti kode berikut:

   • EXAMPLE_ZONE: nama zona DNS subdomain yang didelegasikan di project Anda
   • KSK_ID: nomor ID KSK, biasanya 0

   Outputnya terlihat mirip dengan yang berikut ini:

   44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
   

3. Salin output dari perintah sebelumnya untuk menggunakannya di langkah berikutnya.

4. Guna membuat data DS untuk subdelegasi yang aman, jalankan perintah berikut untuk memulai transaksi:

   gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
   

   Ganti EXAMPLE_ZONE dengan nama zona DNS induk di project tempat Anda membuat data untuk subdomain yang didelegasikan.

   Outputnya akan terlihat seperti berikut:

   Transaction started [transaction.yaml].
   

5. Selanjutnya, jalankan perintah berikut untuk menambahkan kumpulan data:

   gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \
      --ttl TIME_TO_LIVE \
      --type DS \
      --name subdomain.example.com \
      "DS_RECORD_AND_KEY"
   

   Ganti kode berikut:

   • EXAMPLE_ZONE: nama zona DNS induk di project Anda
   • TIME_TO_LIVE: waktu aktif untuk zona dalam detik, misalnya 3600
   • subdomain.example.com: subdomain dari nama DNS zona
   • DS_RECORD_AND_KEY: data dan kunci DS yang Anda dapatkan di langkah 2, seperti 44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

   Outputnya akan terlihat seperti berikut:

   44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
   Record addition appended to transaction at [transaction.yaml].
   

6. Untuk menambahkan data NS, gunakan perintah berikut:

   gcloud dns record-sets transaction add --zone EXAMPLE_ZONE \
      --ttl TIME_TO_LIVE \
      --type NS \
      --name subdomain.example.com \
   

   Ganti kode berikut:

   • EXAMPLE_ZONE: nama zona DNS induk di project Anda
   • TIME_TO_LIVE: waktu aktif untuk zona dalam detik, misalnya 3600
   • subdomain.example.com: subdomain dari nama DNS zona

7. Masukkan RRData berikut:

   ns-cloud-e1.googledomains.com. \
   ns-cloud-e2.googledomains.com. \
   ns-cloud-e3.googledomains.com. \
   ns-cloud-e4.googledomains.com.
   

   Catatan: Pilihan server nama untuk data NS bergantung pada sharding server nama tempat subdomain yang didelegasikan ditetapkan saat data tersebut dibuat. Informasi ini terlihat dalam dialog penyiapan Registrar sebelumnya—detail data DS dan NS yang diperlukan akan muncul bersamaan.

   Outputnya akan terlihat seperti berikut:

   Record addition appended to transaction at [transaction.yaml].
   

8. Untuk menjalankan transaksi, gunakan perintah berikut:

   gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE
   

   Ganti EXAMPLE_ZONE dengan nama zona DNS di project Anda.

   Outputnya akan terlihat seperti berikut:

   Executed transaction [transaction.yaml] for managed-zone [dns-example].
   Created     [https://dns.googleapis.com/dns/v1/projects/example/managedZones/example_zone/changes/42].
   ID  START_TIME                STATUS
   42  2019-08-08T23:12:49.100Z  PENDING
   

Menggunakan opsi penandatanganan lanjutan

Saat mengaktifkan DNSSEC untuk zona terkelola, atau membuat zona terkelola dengan DNSSEC, Anda dapat memilih algoritma penandatanganan DNSSEC dan jenis penolakan keberadaan.

Anda dapat mengubah setelan DNSSEC (misalnya, ke algoritme yang digunakan untuk menandatangani data secara kristografis) untuk zona terkelola sebelum mengaktifkan DNSSEC. Jika DNSSEC sudah diaktifkan untuk zona terkelola, untuk melakukan perubahan, nonaktifkan DNSSEC terlebih dahulu, lakukan perubahan yang diperlukan, lalu gunakan perintah berikut untuk mengaktifkan kembali DNSSEC:

gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on

Ganti EXAMPLE_ZONE dengan nama zona DNS di project Anda.

Untuk mengetahui detailnya, lihat Mengaktifkan DNSSEC untuk zona terkelola yang ada.

Catatan: Jika ingin domain Anda di-resolve saat DNSSEC dinonaktifkan, Anda harus menonaktifkan DNSSEC terlebih dahulu untuk zona Anda di registrar domain guna memastikan bahwa resolver yang memvalidasi DNSSEC masih dapat menyelesaikan nama di zona. Untuk mengetahui detailnya, lihat Menonaktifkan DNSSEC untuk zona terkelola.

Perintah berikut mengaktifkan DNSSEC dengan ECDSA dan NSEC 256-bit untuk paket respons DNSSEC terkecil yang ditandatangani yang mungkin menggunakan Cloud DNS:

gcloud dns managed-zones update EXAMPLE_ZONE \
  --dnssec-state on \
  --ksk-algorithm ECDSAP256SHA256 --ksk-key-length 256 \
  --zsk-algorithm ECDSAP256SHA256 --zsk-key-length 256 \
  --denial-of-existence NSEC

Ganti EXAMPLE_ZONE dengan nama zona DNS di project Anda.

Jika memberikan algoritma KSK atau ZSK atau panjang kunci, Anda harus menyediakan semuanya dan argumennya dalam perintah:

--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length

Anda dapat menentukan penolakan eksistensi sebagai NSEC atau NSEC3 terlepas dari algoritma.

Opsi dan argumen algoritma yang didukung tercantum dalam tabel berikut. Cloud DNS tidak mengizinkan penggunaan algoritma atau parameter lainnya.

Algoritma	Panjang KSK	Panjang ZSK	Komentar
RSASHA256	2048	1024, 2048
RSASHA512	2048	1024, 2048	Tidak didukung secara luas
ECDSAP256SHA256	256	256
ECDSAP384SHA384	384	384	Tidak didukung secara luas

Jika tidak ada algoritma yang ditentukan, Cloud DNS akan menggunakan setelan default berikut:

Jenis kunci	Algoritme default	Panjang kunci default
Kunci penandatanganan kunci (KSK)	RSASHA256	2048
Kunci penandatanganan zona (ZSK)	RSASHA256	1024

Perbedaan keamanan dan performa antara RSASHA256 dan RSASHA512 minimal, dan ukuran respons yang ditandatangani identik. Panjang kunci sangat penting: kunci yang lebih panjang lebih lambat dan respons lebih besar (lihat analisis ukuran respons untuk zona root dan TLD, serta analisis performa sisi server di Windows).

Dukungan resolver untuk ECDSA terbatas pada sistem yang cukup baru. Resolver lama yang tidak dapat memvalidasi zona yang ditandatangani ECDSA menganggapnya tidak ditandatangani, yang mungkin tidak aman jika Anda menggunakan jenis data baru yang mengandalkan DNSSEC. Dukungan registrar dan registry untuk ECDSA 256 bit sudah umum, tetapi tidak universal. Hanya sedikit registry dan lebih sedikit lagi registrar yang mendukung ECDSA 384-bit. Penggunaan ECDSA dapat efektif jika Anda tidak perlu mendukung klien lama; tanda tangannya jauh lebih kecil dan lebih cepat untuk dihitung.

Hindari penggunaan algoritma yang berbeda untuk KSK dan ZSK di zona terkelola karena akan mengurangi kompatibilitas dan dapat membahayakan keamanan. Beberapa resolver yang memvalidasi DNSSEC mungkin menggagalkan validasi untuk zona dengan algoritma DNSKEY yang tidak digunakan untuk menandatangani semua data di zona tersebut. Hal ini benar meskipun RFC 6840 mengatakan "mereka tidak boleh bersikeras bahwa semua algoritma ... dalam DNSKEY RRset berfungsi". Jika hal ini tidak menjadi masalah (sebagian besar resolver yang memvalidasi mengikuti RFC 6840), Anda dapat menggunakan RSASHA256 untuk KSK dan ECDSA untuk ZSK jika registrar domain atau registry TLD Anda tidak mendukung ECDSA dan Anda memerlukan ukuran respons yang lebih kecil.

NSEC3 adalah jenis penolakan eksistensi default; jenis ini menawarkan perlindungan terbatas terhadap petugas {i>zone walker<i} yang mencoba menemukan semua data di zona Anda. Setelan NSEC3PARAM telah diperbaiki: opt-out NSEC3 dinonaktifkan untuk keamanan, dan ada satu iterasi hash tambahan (total dua) dengan salt 64-bit.

NSEC memiliki respons yang sedikit lebih kecil, tetapi tidak memiliki perlindungan terhadap penentuan zona waktu. Menggunakan NSEC juga dapat mengurangi kueri untuk domain yang tidak ada. Google Public DNS dan beberapa resolver validasi DNSSEC lainnya dapat menyintesis respons negatif dari data NSEC yang disimpan dalam cache tanpa membuat kueri untuk zona Cloud DNS Anda.

RFC 8624 berisi panduan tambahan tentang pemilihan algoritme.

Menggunakan jenis data DNS baru dengan zona yang diamankan oleh DNSSEC

Setelah domain Anda diamankan sepenuhnya dengan DNSSEC, Anda dapat memulai dengan menggunakan beberapa jenis data DNS baru yang menggunakan jaminan keaslian dan integritas zona yang ditandatangani DNSSEC untuk meningkatkan keamanan layanan lainnya.

SSHFP

Data SSHFP berisi sidik jari kunci publik server SSH yang dapat digunakan aplikasi klien SSH untuk memvalidasi server SSH. Klien SSH biasanya memerlukan interaksi pengguna untuk mengonfirmasi kunci publik server pada koneksi pertama dan menghasilkan peringatan jika kunci diubah. Klien SSH yang dikonfigurasi untuk menggunakan SSHFP selalu menggunakan kunci dalam data SSHFP server untuk server tersebut; hanya kunci untuk server tanpa data SSHFP yang akan disimpan untuk digunakan kembali.

Format rekaman SSHFP adalah sebagai berikut:

• Angka algoritma
• Nomor jenis sidik jari
• Sidik jari kunci server

Nomor algoritma untuk SSH adalah sebagai berikut:

1. RSA
2. DSA
3. ECDSA
4. ED25519

Jenis sidik jari adalah sebagai berikut:

• SHA-1 (tidak digunakan lagi, hanya untuk kompatibilitas)
• SHA-256

Perhatian: Penggunaan data SSHFP yang tidak tepat dapat memiliki konsekuensi keamanan serius. Ikuti aturan berikut untuk menghindari terciptanya kerentanan keamanan:

• Jangan buat data SSHFP di zona yang tidak diamankan dengan DNSSEC.
• Jangan pernah mengonfigurasi klien SSH agar menggunakan SSHFP untuk domain yang tidak diamankan dengan DNSSEC.
• Jangan pernah mengonfigurasi klien SSH untuk menggunakan SSHFP, kecuali jika klien tersebut memvalidasi DNSSEC atau menggunakan resolver validasi, seperti Google Public DNS.

Jika aturan ini tidak diikuti, penyerang dapat membuat data SSHFP spoofing agar server Anda dapat meniru identitasnya, sehingga koneksi SSH ke server menjadi tidak aman dan rentan terhadap serangan.

StackExchange memiliki saran untuk membuat SSHFP, dan ada alat untuk menghasilkannya dengan memindai server, menggunakan file host yang dikenal atau pengelolaan konfigurasi yang sudah ada. Untuk mengetahui contoh dan link lainnya, lihat Data SSHFP: DNS menyediakan kunci host SSH publik.

TLSA dan DANE

Data TLSA berisi informasi yang dapat digunakan untuk memvalidasi sertifikat X.509 (seperti sertifikat yang digunakan oleh HTTPS) tanpa bergantung pada salah satu dari kumpulan certificate authority (CA) yang telah dikonfigurasi untuk menandatanganinya.

Hal ini memungkinkan Anda menyiapkan CA sendiri dan membuat sertifikat untuk HTTPS. Hal ini juga mengizinkan validasi sertifikat untuk protokol seperti SMTP jika biasanya tidak ada dukungan aplikasi untuk CA tepercaya yang telah dikonfigurasi sebelumnya.

Perhatian: Jangan buat data TLSA di zona yang tidak diamankan dengan DNSSEC. Sebagian besar aplikasi yang menggunakan data TLSA memerlukan validasi DNSSEC, sehingga pembuatan data semacam itu tidak akan berpengaruh. Namun, tindakan ini dapat menimbulkan kerentanan pada aplikasi yang salah dikonfigurasi.

DANE (Autentikasi Domain Entitas Bernama), seperti yang ditentukan dalam RFC 6698 dan RFC terkait, menggunakan data TLSA dengan cara tertentu untuk mengamankan banyak protokol dan aplikasi. IETF Journal and Internet Society memiliki artikel pengantar dan ringkasan DANE yang bermanfaat.

HTTPS

DANE memungkinkan Anda mengonfigurasi server HTTPS dengan aman menggunakan sertifikat yang dibuat dengan infrastruktur CA Anda sendiri berdasarkan OpenSSL atau CFSSL Cloudflare.

Validator DANE untuk server HTTPS SIDNLabs sangat membantu untuk menguji deployment DANE untuk HTTPS.

Verifikasi sertifikat TLS SMTP (Email)

Protokol email SMTP rentan terhadap serangan downgrade yang menonaktifkan enkripsi, dan DANE menyediakan cara untuk mencegah serangan ini.

Internet Society memiliki tutorial dua bagian tentang penggunaan DANE untuk SMTP dengan sertifikat gratis dan otomatis yang tersedia dari Let's Encrypt, termasuk saran untuk menghindari penggunaan format data TLSA tertentu dengan sertifikat Let's Encrypt:

• Bagian 1
• Bagian 2

Anda dapat menemukan saran yang bagus (dan validator domain DANE untuk HTTPS dan SMTP) di Common Kesalahan. Menguji validator email Anda juga memeriksa DANE.

Verifikasi sertifikat TLS XMPP (Jabber chat)

XMPP (dan layanan lain yang menggunakan catatan SRV) juga dapat memanfaatkan DANE. Contoh XMPP menggunakan konfigurasi DANE-SRV seperti yang ditetapkan dalam RFC 7673.

Pengaitan kunci publik TXT (OpenPGP / GnuPG)

Data TXT dapat digunakan tanpa DNSSEC, tetapi data TXT yang ditandatangani dengan DNSSEC memberikan keyakinan yang lebih besar terhadap keasliannya. Hal ini penting untuk kunci publik OpenPGP (GnuPG) publikasi berbasis DNS, yang tidak ditandatangani oleh pihak terkenal seperti X.509 CA.

Misalnya, jika Alice memublikasikan data TXT seperti berikut di zona an.example yang ditandatangani DNSSEC, dan menghosting salinan kunci publik berlapis ASCII di URI yang diberikan, Bob dapat mencari kunci OpenPGP untuk [e-mail] dengan keamanan yang wajar (ini bukan pengganti validasi web-of-trust, tetapi memungkinkan enkripsi OpenPGP dengan pihak yang sebelumnya tidak dikenal):

    alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"

Anda dapat menggunakan instructions ini untuk membuat data TXT PKA Versi 1 ini (seperti yang dipanggil dalam Kunci Publikasi di DNS).

Panduan lengkap untuk memublikasikan kunci PGP di DNS menjelaskan cara membuat data OpenPGP CERT (tetapi Cloud DNS tidak mendukung data CERT atau OPENPGPKEY).

Jika mendaftarkan kunci OpenPGP di Keybase.io, Anda tidak perlu menghosting kunci di server Anda sendiri. Sebagai gantinya, Anda dapat menggunakan URL seperti https://keybase.io/KEYBASE_USERNAME/key.asc (mengganti KEYBASE_USERNAME dengan nama pengguna Keybase.io Anda).

Jika telah mengupload kunci OpenPGP ke server kunci, Anda juga dapat menggunakan hkp: URI untuk server kunci tersebut, seperti hkp://subkeys.pgp.net atau hkp://pgp.mit.edu, meskipun pengguna di belakang firewall yang memblokir port 11371 mungkin tidak dapat menjangkaunya (beberapa server kunci menyediakan port 80 URL HTTP).

TXT (SPF, DKIM, dan DMARC)

Berikut adalah tiga jenis data TXT lain yang dapat digunakan untuk mengamankan layanan email serta mencegah spammer dan scammer mengirim email yang tampaknya berasal dari domain Anda (meskipun sebenarnya bukan):

• SPF: Menentukan server SMTP (berdasarkan nama domain atau alamat IP) yang dapat mengirim email untuk domain.

• DKIM: Memublikasikan kumpulan kunci publik yang digunakan untuk memverifikasi bahwa email dikirim dari domain, dan melindungi pesan agar tidak diubah saat dalam pengiriman.

• DMARC: Menentukan kebijakan dan pelaporan domain untuk validasi SPF dan DKIM serta pelaporan error.

Untuk memverifikasi bahwa domain dikonfigurasi dengan benar untuk menggunakan ketiga jenis data ini, Anda dapat menggunakan Menguji validator email. Untuk menemukan saran yang berguna terkait cara mengonfigurasi data SPF, lihat FAQ tentang kesalahan umum.

Menggunakan jenis kumpulan catatan lainnya yang ditingkatkan oleh DNSSEC

Selain TXT, ada beberapa jenis kumpulan catatan lain yang mendapatkan manfaat dari DNSSEC, meskipun tidak memerlukannya.

CAA

Kumpulan data Otorisasi Otoritas Sertifikasi (CAA) memungkinkan Anda mengontrol CA publik mana yang dapat membuat TLS atau sertifikat lainnya untuk domain Anda. Kontrol ini paling berguna (dan efektif) jika Anda ingin memastikan bahwa CA publik yang menerbitkan sertifikat yang divalidasi domain (DV) (seperti LetsEncrypt.org) tidak menerbitkan sertifikat untuk domain Anda.

Data CAA standar memiliki format sederhana seperti 0 issue "best-ca.example" yang memungkinkan best-ca.example CA (dan tidak ada CA lainnya) mengeluarkan sertifikat untuk nama di domain tempat kumpulan data CAA berada. Jika Anda ingin mengizinkan beberapa CA menerbitkan sertifikat, buat beberapa data CAA.

RFC 6844 memberikan detail lebih lanjut tentang penggunaan jenis kumpulan data CAA, dan sangat merekomendasikan penggunaan DNSSEC.

IPSECKEY

Anda juga dapat mengaktifkan enkripsi oportunistik melalui tunnel IPsec dengan memublikasikan data IPSECKEY. Implementasi VPN IPsec strongSwan memiliki plugin yang menggunakan data IPSECKEY.

Selain menempatkan data IPSECKEY di zona penerusan biasa, seperti service.example.com, RFC 4025 bagian 1.2 mengharuskan gateway keamanan untuk mencari data IPSECKEY di zona terbalik ip6.arpa dan in-addr.arpa.

Dukungan DNSSEC untuk zona terbalik kurang umum dibandingkan untuk zona maju dan memerlukan Internet Service Provider (ISP) yang menerapkan DNSSEC. Namun, ada beberapa ISP yang dapat mendukung DNSSEC untuk delegasi zona terbalik.

Zona terbalik untuk alamat IP eksternal VM Compute Engine belum mendukung delegasi.

Langkah selanjutnya

• Untuk membuat, mengupdate, mencantumkan, dan menghapus zona terkelola, lihat Mengelola zona.
• Untuk menemukan solusi atas masalah umum yang mungkin Anda alami saat menggunakan Cloud DNS, lihat Pemecahan masalah.
• Untuk mendapatkan ringkasan Cloud DNS, lihat ringkasan Cloud DNS.