Menggunakan DNSSEC lanjutan

Halaman ini menyediakan beberapa opsi konfigurasi Domain Name System Security Extensions (DNSSEC) lanjutan yang dapat Anda gunakan jika mengaktifkan DNSSEC untuk zona terkelola. Opsi ini berkisar dari berbagai algoritma penandatanganan dan penolakan keberadaan hingga kemampuan untuk menggunakan jenis data yang memerlukan atau merekomendasikan DNSSEC untuk penggunaannya.

Untuk ringkasan konseptual DNSSEC, lihat ringkasan DNSSEC.

Mendelegasikan subdomain yang ditandatangani DNSSEC

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

Untuk membuat data DS bagi subdomain yang didelegasikan, Anda harus mendapatkan data DS untuk zona. Jika zona yang didelegasikan juga dihosting di Cloud DNS, Anda dapat mendapatkan data DS dari konsol Google Cloud atau dari Google Cloud CLI.

Konsol

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

   Membuka Cloud DNS

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

3. Untuk melihat data DS untuk zona, di pojok kanan atas halaman Detail zona, klik Penyiapan Pendaftar.

4. Data DS tersedia di halaman Penyiapan Pendaftar.

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

gcloud

1. Untuk 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. Untuk membuat data DS bagi 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: time to live untuk zona dalam detik, seperti 3600
   • subdomain.example.com: subdomain dari nama DNS zona
   • DS_RECORD_AND_KEY: data DS dan kunci 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: time to live untuk zona dalam detik, seperti 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 shard server nama tempat subdomain yang didelegasikan ditetapkan saat dibuat. Informasi ini dapat dilihat di dialog Penyiapan pendaftar sebelumnya—detail data DS dan NS yang diperlukan akan muncul bersama.

   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 denial-of-existence.

Anda dapat mengubah setelan DNSSEC (misalnya, ke algoritma yang digunakan untuk menandatangani data secara kriptografis) untuk zona terkelola sebelum mengaktifkan DNSSEC. Jika DNSSEC sudah diaktifkan untuk zona terkelola, untuk melakukan perubahan, pertama-tama nonaktifkan DNSSEC, 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 untuk zona Anda terlebih dahulu di registrar domain untuk memastikan bahwa resolver yang memvalidasi DNSSEC masih dapat me-resolve nama di zona. Untuk mengetahui detailnya, lihat Menonaktifkan DNSSEC untuk zona terkelola.

Perintah berikut mengaktifkan DNSSEC dengan ECDSA 256-bit dan NSEC untuk paket respons bertanda tangan DNSSEC terkecil 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 Anda memberikan algoritma atau panjang kunci KSK atau ZSK, Anda harus memberikan semuanya dan argumennya dalam perintah:

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

Anda dapat menentukan denial-of-existence 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.

Algoritme	Panjang KSK	Panjang ZSK	Komentar
RSASHA256	2048	1.024, 2.048
RSASHA512	2048	1.024, 2.048	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 sangat kecil, dan ukuran respons yang ditandatangani identik. Panjang kunci memang penting: kunci yang lebih panjang lebih lambat dan responsnya 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 umum, tetapi tidak universal. Hanya ada sedikit registry dan bahkan lebih sedikit pendaftar yang mendukung ECDSA 384-bit. Menggunakan ECDSA dapat efektif jika Anda tidak perlu mendukung klien lama; tanda tangan jauh lebih kecil dan lebih cepat dihitung.

Hindari penggunaan algoritma yang berbeda untuk KSK dan ZSK di zona terkelola Anda; hal ini akan mengurangi kompatibilitas dan dapat membahayakan keamanan. Beberapa resolver yang memvalidasi DNSSEC dapat gagal melakukan validasi untuk zona dengan algoritma DNSKEY yang tidak digunakan untuk menandatangani semua data dalam zona. Hal ini benar meskipun RFC 6840 mengatakan "mereka tidak boleh bersikeras bahwa semua algoritma ... dalam RRset DNSKEY berfungsi". Jika hal ini tidak menjadi masalah (sebagian besar resolver validasi 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 denial-of-existence default; jenis ini menawarkan perlindungan terbatas terhadap zone walker 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 zone walking. Penggunaan NSEC juga dapat mengurangi kueri untuk domain yang tidak ada. Google Public DNS dan beberapa resolver lain yang memvalidasi DNSSEC dapat menyintesis respons negatif dari data NSEC yang di-cache tanpa mengkueri zona Cloud DNS Anda.

RFC 8624 berisi panduan tambahan tentang pemilihan algoritma.

Menggunakan jenis data DNS baru dengan zona yang diamankan DNSSEC

Setelah domain Anda sepenuhnya diamankan 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 catatan SSHFP server untuk server tersebut; hanya kunci untuk server tanpa catatan SSHFP yang disimpan untuk digunakan kembali.

Format data SSHFP adalah sebagai berikut:

• Nomor 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 yang serius; ikuti aturan ini untuk menghindari pembuatan kerentanan keamanan:

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

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

StackExchange memiliki saran untuk membuat SSHFP, dan ada alat untuk membuatnya dengan memindai server, menggunakan file host yang diketahui atau pengelolaan konfigurasi yang ada. Untuk contoh dan link selengkapnya, lihat Data SSHFP: DNS yang 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 kumpulan certificate authority (CA) yang telah dikonfigurasi sebelumnya yang menandatanganinya.

Dengan demikian, Anda dapat menyiapkan CA sendiri dan membuat sertifikat untuk HTTPS. Hal ini juga memungkinkan validasi sertifikat untuk protokol seperti SMTP yang biasanya tidak memiliki dukungan aplikasi untuk CA tepercaya yang telah dikonfigurasi sebelumnya.

Perhatian: Jangan buat data TLSA di zona yang tidak diamankan DNSSEC. Sebagian besar aplikasi yang menggunakan data TLSA memerlukan validasi DNSSEC, sehingga membuat data tersebut tidak akan berpengaruh. Namun, hal ini dapat menimbulkan kerentanan dalam aplikasi yang salah dikonfigurasi.

DANE (Domain Authentication of Named Entities), seperti yang ditentukan dalam RFC 6698 dan RFC terkait, menggunakan data TLSA dengan cara tertentu untuk mengamankan banyak protokol dan aplikasi. IETF Journal dan Internet Society memiliki artikel pengantar dan ringkasan DANE yang berguna.

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 berguna 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 sangat baik (dan validator domain DANE untuk HTTPS dan SMTP) di Kesalahan Umum. Uji validator email Anda juga memeriksa DANE.

Verifikasi sertifikat TLS XMPP (chat Jabber)

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

Asosiasi kunci publik TXT (OpenPGP / GnuPG)

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

Misalnya, jika Alice memublikasikan data TXT seperti berikut di zona an.example yang ditandatangani DNSSEC, dan menghosting salinan kunci publik yang dilindungi 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 petunjuk ini untuk membuat data TXT PKA Versi 1 ini (seperti yang disebut dalam Memublikasikan Kunci di DNS).

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

Jika Anda 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 (ganti KEYBASE_USERNAME dengan nama pengguna Keybase.io Anda).

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

TXT (SPF, DKIM, dan DMARC)

Berikut adalah tiga jenis data TXT lainnya yang dapat Anda gunakan untuk mengamankan layanan email dan mencegah spammer serta scammer mengirim email yang tampak berasal dari domain Anda (meskipun tidak):

• SPF: Menentukan server SMTP (menurut 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 dalam pengiriman.

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

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

Menggunakan jenis kumpulan data lain yang ditingkatkan oleh DNSSEC

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

CAA

Kumpulan data Certification Authority Authorization (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 validasi 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 CA best-ca.example (dan tidak ada CA lain) menerbitkan 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 menyarankan 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 maju biasa, seperti service.example.com, RFC 4025 bagian 1.2 memerlukan gateway keamanan untuk mencari data IPSECKEY di zona mundur ip6.arpa dan in-addr.arpa.

Dukungan DNSSEC untuk zona terbalik kurang umum dibandingkan dengan 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, memperbarui, 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.