Menggunakan DNSSEC lanjutan

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

Untuk mengetahui ringkasan konseptual DNSSEC, lihat Ringkasan DNSSEC.

Mendelegasikan subdomain bertanda tangan DNSSEC

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

Untuk membuat data DS bagi subdomain yang didelegasikan, Anda harus mendapatkan data DS untuk zona tersebut. Jika zona yang didelegasikan juga dihosting di Cloud DNS, Anda dapat memperoleh 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, 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. 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 Penandatanganan Kunci (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 akan terlihat mirip seperti berikut:

   44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
   

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

4. Untuk 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 set 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 (TTL) untuk zona dalam detik, seperti 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: time to live (TTL) 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 yang ditetapkan ke subdomain yang didelegasikan saat subdomain tersebut dibuat. Informasi ini dapat dilihat di dialog Registrar setup sebelumnya. Detail data DS dan NS yang diperlukan 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 denial-of-existence.

Anda dapat mengubah setelan DNSSEC (misalnya, algoritma yang digunakan untuk menandatangani data secara kriptografis) 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 untuk zona Anda terlebih dahulu di registrar domain Anda untuk memastikan bahwa resolver yang memvalidasi DNSSEC masih dapat me-resolve nama di zona tersebut. Untuk mengetahui detailnya, lihat Menonaktifkan DNSSEC untuk zona terkelola.

Perintah berikut mengaktifkan DNSSEC dengan ECDSA dan NSEC 256 bit 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 memberikan panjang kunci atau algoritma KSK atau ZSK, Anda harus memberikan semua panjang kunci dan algoritma tersebut serta argumennya dalam perintah:

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

Anda dapat menentukan denial-of-existence sebagai NSEC atau NSEC3 secara independen 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 nilai default berikut:

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

Perbedaan keamanan dan performa antara RSASHA256 dan RSASHA512 sangatlah kecil, dan ukuran respons yang ditandatangani bersifat identik. Panjang kunci itu 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 bertanda tangan 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 itu umum, tetapi tidak universal. Hanya beberapa registry dan bahkan lebih sedikit 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 dihitung.

Hindari penggunaan algoritma yang berbeda untuk KSK dan ZSK di zona terkelola Anda; tindakan ini mengurangi kompatibilitas dan dapat membahayakan keamanan. Beberapa resolver yang memvalidasi DNSSEC mungkin gagal memvalidasi zona dengan algoritma DNSKEY yang tidak digunakan untuk menandatangani semua data di zona tersebut. Hal ini berlaku meskipun RFC 6840 menyatakan "they must not insist that all algorithms ... in the DNSKEY RRset work". 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 bersifat tetap: NSEC3 opt-out dinonaktifkan untuk keamanan, dan ada satu iterasi hash tambahan (total dua) dengan salt 64 bit.

NSEC memiliki respons yang sedikit lebih kecil, tetapi tidak ada perlindungan terhadap zone walking. Penggunaan NSEC juga dapat mengurangi kueri untuk domain yang tidak ada. Google Public DNS dan beberapa resolver yang memvalidasi DNSSEC lainnya dapat mensintesis 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 diamankan sepenuhnya dengan DNSSEC, Anda dapat mulai menggunakan beberapa jenis data DNS baru yang menggunakan jaminan keaslian dan integritas zona bertanda tangan DNSSEC untuk meningkatkan keamanan layanan lain.

SSHFP

Data SSHFP berisi sidik jari kunci publik server SSH yang dapat digunakan oleh 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 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 menimbulkan konsekuensi keamanan yang serius. Ikuti aturan ini untuk menghindari timbulnya kerentanan keamanan:

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

Tidak mengikuti aturan ini dapat memungkinkan penyerang membuat data SSHFP yang di-spoofing untuk server Anda guna meniru identitasnya, sehingga membuat 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 umum yang ada atau manajemen konfigurasi. Untuk melihat contoh dan link lainnya, lihat SSHFP records: DNS providing public ssh host keys.

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 serangkaian certificate authority (CA) yang dikonfigurasi sebelumnya yang menandatanganinya.

Dengan begitu, 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 dikonfigurasi sebelumnya.

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

DANE (Domain Authentication of Named Entities), sebagaimana 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 bisa Anda manfaatkan.

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 dari SIDNLabs dapat Anda gunakan untuk menguji deployment DANE untuk HTTPS.

Verifikasi sertifikat TLS SMTP (Email)

Protokol email SMTP bersifat 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. Menguji validator email Anda juga akan 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 bertanda tangan DNSSEC memberikan keyakinan yang lebih besar terhadap keasliannya. Hal ini penting untuk publikasi kunci publik OpenPGP (GnuPG) berbasis DNS, yang tidak ditandatangani oleh pihak-pihak terkenal seperti CA X.509.

Misalnya, jika Alice memublikasikan data TXT seperti berikut di zona an.example bertanda tangan DNSSEC, dan menghosting salinan kunci publik yang dienkapsulasi ASCII di URI yang diberikan, Bob dapat mencari kunci OpenPGP untuk [e-mail] dengan keamanan yang wajar (hal 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 Version 1 PKA ini (seperti yang disebut dalam Publishing Keys in 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 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 hkp: URI 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 mengaksesnya (beberapa server kunci menyediakan URL HTTP port 80).

TXT (SPF, DKIM, dan DMARC)

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

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

• DKIM: Memublikasikan serangkaian kunci publik yang digunakan untuk memverifikasi bahwa email dikirim dari suatu domain, dan melindungi pesan agar tidak dimodifikasi selama pengiriman.

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

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

Menggunakan jenis set data lain yang ditingkatkan oleh DNSSEC

Selain TXT, ada beberapa jenis set data lain yang diuntungkan dari DNSSEC, meskipun tidak memerlukannya.

CAA

Set 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 yang divalidasi domain (DV) (seperti LetsEncrypt.org) tidak menerbitkan sertifikat untuk domain Anda.

Data CAA umum memiliki format sederhana seperti 0 issue "best-ca.example" yang memungkinkan CA best-ca.example (dan bukan CA lain) menerbitkan sertifikat untuk nama di domain tempat set data CAA berada. Jika Anda ingin mengizinkan beberapa CA menerbitkan sertifikat, buat beberapa data CAA.

RFC 6844 memberikan detail lebih lanjut tentang penggunaan jenis set 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 maju biasa, seperti service.example.com, RFC 4025 bagian 1.2 mengharuskan gateway keamanan untuk mencari data IPSECKEY di zona balik ip6.arpa dan in-addr.arpa.

Dukungan DNSSEC untuk zona balik bersifat 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 balik.

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

Langkah berikutnya

• 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.