Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Mengonfigurasi Amazon Route 53 sebagai layanan DNS Anda
Anda dapat menggunakan Amazon Route 53 sebagai layanan DNS untuk domain, seperti example.com. Saat menjadi layanan DNS, Route 53 merutekan lalu lintas internet ke situs web dengan menerjemahkan nama domain yang ramah seperti www.example.com ke dalam alamat IP numerik, seperti 192.0.2.1 yang digunakan komputer untuk terhubung satu sama lain. Ketika seseorang mengetik nama domain Anda di peramban atau mengirimkan email kepada Anda, kueri DNS diteruskan ke Route 53, yang merespons dengan nilai yang sesuai. Misalnya, Route 53 mungkin merespons dengan alamat IP untuk server web example.com.
**Hosting DNS vs. pendaftaran domain**
Bab ini mencakup penggunaan Route 53 *hanya untuk hosting DNS*. Ini berarti pendaftaran domain Anda tetap dengan registrar Anda saat ini, dan Anda akan terus membayar mereka untuk perpanjangan domain. Route 53 hanya akan mengelola pengaturan DNS Anda dan menangani kueri DNS untuk domain Anda.
Jika Anda ingin mentransfer pendaftaran domain Anda ke Route 53 juga (membuat Route 53 baik registrar dan layanan DNS Anda), lihat [Daftar periksa pra-transfer untuk transfer domain](domain-transfer-checklist.md) dan. [Mentransfer pendaftaran untuk domain ke Amazon Route 53](domain-transfer-to-route-53.md)
Dalam Bab ini, kami menjelaskan cara mengkonfigurasi Route 53 untuk merutekan lalu lintas internet Anda ke tempat yang tepat. Kami juga menjelaskan cara memigrasi layanan DNS ke Route 53 jika Anda saat ini menggunakan layanan DNS lain, dan cara menggunakan Route 53 sebagai layanan DNS untuk domain baru.
**Topics**
+ [Membuat Amazon Route 53 menjadi layanan DNS untuk domain yang ada](MigratingDNS.md)
+ [Mengonfigurasi perutean DNS untuk domain baru](dns-configuring-new-domain.md)
+ [Merutekan lalu lintas ke sumber daya](dns-routing-traffic-to-resources.md)
+ [Bekerja dengan zona yang di-hosting](hosted-zones-working-with.md)
+ [Bekerja dengan catatan](rrsets-working-with.md)
+ [Mengonfigurasi penandatanganan DNSSEC di Amazon Route 53](dns-configuring-dnssec.md)
+ [Menggunakan AWS Cloud Map untuk membuat catatan dan pemeriksaan kesehatan](autonaming.md)
+ [Kendala dan perilaku DNS](DNSBehavior.md)
+ [Topik terkait](dns-configuring-related-topics.md)
# Membuat Amazon Route 53 menjadi layanan DNS untuk domain yang ada
Jika Anda mentransfer satu atau beberapa pendaftaran domain ke Route 53, dan saat ini menggunakan registrar domain yang tidak menyediakan layanan DNS berbayar, Anda harus memigrasi layanan DNS sebelum memigrasi domain. Jika tidak, registrar akan berhenti menyediakan layanan DNS saat Anda mentransfer domain, dan situs web serta aplikasi web yang terkait akan menjadi tidak tersedia di internet. (Anda juga dapat memigrasi layanan DNS dari registrar saat ini ke penyedia layanan DNS lainnya. Kami tidak mengharuskan Anda menggunakan Route 53 sebagai penyedia layanan DNS untuk domain yang terdaftar dengan Route 53.)
Proses tersebut bergantung pada apakah Anda saat ini menggunakan domain tersebut:
+ Jika domain sedang mendapatkan lalu lintas—misalnya, jika pengguna Anda menggunakan nama domain untuk menelusuri situs web atau mengakses aplikasi web—lihat [Membuat Route 53 sebagai layanan DNS untuk domain yang sedang digunakan](migrate-dns-domain-in-use.md).
+ Jika domain tidak mendapatkan lalu lintas (atau mendapat lalu lintas yang sangat sedikit), lihat [Membuat Route 53 menjadi layanan DNS untuk domain yang tidak aktif](migrate-dns-domain-inactive.md).
Untuk kedua opsi tersebut, domain Anda akan tetap tersedia selama seluruh proses migrasi. Namun, jika ada masalah, opsi pertama memungkinkan Anda mengembalikan migrasi dengan cepat. Dengan opsi kedua, domain Anda mungkin tidak tersedia selama beberapa hari.
Jika Anda ingin terhubung dengan seorang ahli di AWS, kunjungi [dukungan Penjualan](https://aws.amazon.com/contact-us/sales-support/?pg=ln&sec=hs).
# Membuat Route 53 sebagai layanan DNS untuk domain yang sedang digunakan
Jika Anda ingin memigrasi layanan DNS ke Amazon Route 53 untuk domain yang sedang mendapatkan lalu lintas—misalnya, jika pengguna Anda menggunakan nama domain untuk menelusuri situs web atau mengakses aplikasi web—lakukan prosedur di bagian ini.
**Topics**
+ [Langkah 1: Dapatkan konfigurasi DNS Anda saat ini dari penyedia layanan DNS saat ini (opsional tetapi direkomendasikan)](#migrate-dns-get-zone-file)
+ [Langkah 2: Membuat zona yang di-hosting](#migrate-dns-create-hosted-zone)
+ [Langkah 3: Membuat catatan](#migrate-dns-create-records)
+ [Langkah 4: Menurunkan pengaturan TTL](#migrate-dns-lower-ttl)
+ [Langkah 5: (Jika Anda telah mengonfigurasi DNSSEC) Menghapus catatan DS dari zona induk](#migrate-remove-ds)
+ [Langkah 6: Menunggu TTL lama kedaluwarsa](#migrate-dns-wait-for-ttl)
+ [Langkah 7: Memperbarui catatan NS untuk menggunakan server nama Route 53](#migrate-dns-change-name-servers-with-provider)
+ [Langkah 8: Memantau lalu lintas untuk domain](#migrate-dns-monitor-traffic)
+ [Langkah 9: Mengembalikan TTL untuk catatan NS ke nilai yang lebih tinggi](#migrate-dns-change-ttl-back)
+ [Langkah 10: Mentransfer pendaftaran domain ke Amazon Route 53](#migrate-dns-transfer-domain-registration)
+ [Langkah 11: Mengktifkan kembali penandatanganan DNSSEC (jika diperlukan)](#migrate-dns-re-enable-dnssec)
## Langkah 1: Dapatkan konfigurasi DNS Anda saat ini dari penyedia layanan DNS saat ini (opsional tetapi direkomendasikan)
Ketika memigrasi layanan DNS dari penyedia lain ke Route 53, Anda mereproduksi konfigurasi DNS Anda saat ini di Route 53. Di Route 53, Anda membuat zona yang di-hosting dengan nama yang sama seperti domain, dan Anda membuat catatan di zona yang di-hosting. Setiap catatan menunjukkan cara Anda ingin merutekan lalu lintas untuk nama domain atau nama subdomain tertentu. Misalnya, ketika seseorang memasukkan nama domain Anda di browser web, apakah Anda ingin lalu lintas diarahkan ke server web di pusat data Anda, ke instans Amazon EC2, ke CloudFront distribusi, atau ke lokasi lain?
Proses yang Anda gunakan tergantung pada kompleksitas konfigurasi DNS Anda saat ini:
+ **Jika konfigurasi DNS Anda saat ini sederhana** – Jika Anda merutekan lalu lintas internet hanya untuk beberapa subdomain ke sejumlah kecil sumber daya, seperti server web atau bucket Amazon S3, Anda dapat membuat beberapa catatan secara manual di konsol Route 53.
+ **Jika konfigurasi DNS Anda saat ini lebih kompleks, dan Anda hanya ingin mereproduksi konfigurasi saat ini** – Anda dapat menyederhanakan migrasi jika bisa mendapatkan file zona dari penyedia layanan DNS saat ini, dan mengimpor file zona ke Route 53. (Tidak semua penyedia layanan DNS menawarkan file zona.) Ketika Anda mengimpor file zona, Route 53 secara otomatis mereproduksi konfigurasi yang ada dengan membuat catatan yang sesuai di zona yang di-hosting.
Coba tanyakan ke dukungan pelanggan penyedia layanan DNS Anda saat ini tentang cara mendapatkan *file zona* atau *daftar catatan*. Untuk informasi tentang format file zona yang diperlukan, lihat [Membuat catatan dengan mengimpor file zona](resource-record-sets-creating-import.md).
+ **Jika konfigurasi DNS Anda saat ini lebih kompleks, dan Anda tertarik dengan fitur perutean Route 53** – Tinjau dokumentasi berikut untuk melihat apakah Anda ingin menggunakan fitur Route 53 yang tidak tersedia dari penyedia layanan DNS lainnya. Jika iya, Anda dapat membuat catatan secara manual, atau Anda dapat mengimpor file zona lalu membuat atau memperbarui catatan nanti:
+ [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md)menjelaskan keuntungan dari catatan alias Route 53, yang merutekan lalu lintas ke beberapa AWS sumber daya, seperti CloudFront distribusi dan bucket Amazon S3, tanpa biaya.
+ [Memilih kebijakan perutean](routing-policy.md) menjelaskan opsi perutean Route 53, misalnya, perutean berdasarkan lokasi pengguna, perutean berdasarkan latensi antara pengguna dan sumber daya, perutean berdasarkan apakah sumber daya Anda sehat, dan perutean ke sumber daya berdasarkan bobot yang Anda tentukan.
**catatan**
Anda juga dapat mengimpor file zona dan mengubah konfigurasinya nanti untuk memanfaatkan catatan alias dan kebijakan perutean yang kompleks.
Jika Anda tidak bisa mendapatkan file zona atau jika Anda ingin membuat catatan secara manual di Route 53, catatan yang mungkin akan Anda migrasi meliputi:
+ **Catatan (Alamat)** — mengaitkan nama domain atau nama subdomain dengan IPv4 alamat (misalnya, 192.0.2.3) dari sumber daya yang sesuai
+ **Catatan AAAA (Alamat)** — kaitkan nama domain atau nama subdomain dengan IPv6 alamat (misalnya, 2001:0 db 8:85 a 3:0000:0000:abcd: 0001:2345) dari sumber daya yang sesuai
+ **Catatan server email (MX)** – merutekan lalu lintas ke server email
+ **Catatan CNAME** – mengubah rute lalu lintas untuk satu nama domain (example.net) ke nama domain lain (example.com)
+ **Catatan untuk jenis catatan DNS lain yang didukung** – Untuk daftar jeinis catatan yang didukung, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
## Langkah 2: Membuat zona yang di-hosting
Untuk memberi tahu Amazon Route 53 bagaimana Anda ingin merutekan lalu lintas untuk domain Anda, Anda membuat zona yang dihosting yang memiliki nama yang sama dengan domain Anda, lalu Anda membuat catatan di zona yang dihosting.
**penting**
Anda dapat membuat zona yang di-hosting hanya untuk domain yang izin administrasinya Anda miliki. Biasanya, ini berarti Anda memiliki domain, tetapi Anda mungkin mengembangkan aplikasi untuk pendaftar domain.
Ketika Anda membuat zona yang di-hosting, Route 53 secara otomatis membuat catatan server nama (NS) dan catatan start of authority (SOA) untuk zona. Catatan NS mengidentifikasi empat server nama yang dikaitkan Route 53 dengan zona yang di-hosting. Untuk membuat Route 53 menjadi layanan DNS bagi domain Anda, perbarui pendaftaran domain untuk menggunakan keempat server nama tersebut.
**penting**
Jangan buat server nama (NS) tambahan atau catatan start of authority (SOA), serta jangan hapus catatan NS dan SOA yang sudah ada.
**Cara membuat zona yang di-hosting**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Jika Anda baru mengenal Route 53, pilih **Memulai** di bawah **Manajemen DNS**, lalu pilih **Buat zona yang di-hosting**.
Jika Anda sudah menggunakan Route 53, pilih **Zona yang di-hosting** pada panel navigasi, lalu pilih **Buat zona yang di-hosting**.
1. Pada panel **Buat zona yang di-hosting**, masukkan nama domain dan, secara opsional, komentar. Untuk informasi lebih lanjut tentang pengaturan, pilih untuk membuka panel bantuan di sisi kanan.
Untuk informasi tentang cara menentukan karakter selain a-z, 0-9, dan - (tanda hubung) serta cara menentukan nama domain internasional, lihat [Format nama domain DNS](DomainNameFormat.md).
1. Untuk **Jenis**, terima nilai default **Zona yang di-hosting publik**.
1. Pilih **Buat zona yang di-hosting**.
## Langkah 3: Membuat catatan
Setelah membuat zona yang di-hosting, Anda membuat catatan di zona yang di-hosting yang menentukan lokasi tujuan Anda ingin merutekan lalu lintas untuk domain (example.com) atau subdomain (www.example.com). Misalnya, jika ingin merutekan lalu lintas untuk example.com dan www.example.com ke server web pada instans Amazon EC2, Anda membuat dua catatan, satu catatan bernama example.com dan catatan lain bernama www.example.com. Dalam setiap catatan, Anda menentukan alamat IP untuk instans EC2.
Anda dapat membuat catatan dengan berbagai cara:
**Mengimpor file zona**
Ini adalah metode termudah jika Anda mendapatkan file zona dari layanan DNS saat ini di [Langkah 1: Dapatkan konfigurasi DNS Anda saat ini dari penyedia layanan DNS saat ini (opsional tetapi direkomendasikan)](#migrate-dns-get-zone-file). Amazon Route 53 tidak dapat memprediksi kapan catatan alias harus dibuat atau menggunakan jenis perutean khusus seperti tertimbang atau failover. Sebagai hasilnya, jika Anda mengimpor file zona, Route 53 membuat catatan DNS standar menggunakan kebijakan perutean sederhana.
Untuk informasi selengkapnya, lihat [Membuat catatan dengan mengimpor file zona](resource-record-sets-creating-import.md).
**Membuat catatan secara individual di konsol**
Jika Anda tidak mendapatkan file zona dan hanya ingin membuat beberapa catatan dengan kebijakan perutean Sederhana untuk memulai, Anda dapat membuat catatan di konsol Route 53. Anda dapat membuat catatan alias dan non-alias.
Untuk informasi selengkapnya, lihat topik berikut:
+ [Memilih kebijakan perutean](routing-policy.md)
+ [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md)
+ [Membuat catatan dengan menggunakan konsol Amazon Route 53](resource-record-sets-creating.md)
**Membuat catatan secara terprogram**
Anda dapat membuat catatan dengan menggunakan salah satu AWS SDKs, AWS CLI, atau AWS Tools for Windows PowerShell. Untuk informasi selengkapnya, lihat [Dokumentasi AWS](https://docs.aws.amazon.com/).
Jika Anda menggunakan bahasa pemrograman yang AWS tidak menyediakan SDK, Anda juga dapat menggunakan Route 53 API. Untuk informasi lebih lanjut, lihat [Referensi API Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/).
## Langkah 4: Menurunkan pengaturan TTL
Pengaturan TTL (waktu untuk tayang) bagi catatan menentukan durasi penyelesai DNS untuk meng-cache catatan dan menggunakan informasi yang di-cache. Ketika TTL berakhir, penyelesai mengirimkan kueri lain ke penyedia layanan DNS untuk domain guna mendapatkan informasi terbaru.
Pengaturan TTL khas untuk catatan NS adalah 172800 detik, atau dua hari. Catatan NS mencantumkan server nama yang dapat digunakan Sistem Nama Domain (DNS) untuk mendapatkan informasi tentang cara merutekan lalu lintas domain Anda. Menurunkan TTL untuk catatan NS, baik dengan penyedia layanan DNS Anda saat ini maupun dengan Amazon Route 53, mengurangi waktu henti untuk domain Anda jika Anda menemukan masalah saat Anda memigrasikan DNS ke Route 53. Jika Anda tidak menurunkan TTL, domain mungkin tidak tersedia di internet hingga dua hari jika terjadi kesalahan.
**catatan**
Beberapa resolver penuh dapat menyimpan TTL dari catatan NS dari server otoritatif induk, oleh karena itu TTL catatan NS yang terdaftar di server DNS otoritatif induk juga harus dikurangi.
Kami merekomendasikan Anda mengubah TTL pada catatan NS berikut:
+ Pada catatan NS di zona yang di-hosting untuk penyedia layanan DNS saat ini. (Penyedia Anda saat ini mungkin menggunakan terminologi yang berbeda.)
+ Pada catatan NS di zona yang di-hosting yang Anda buat di [Langkah 2: Membuat zona yang di-hosting](#migrate-dns-create-hosted-zone).
**Cara menurunkan pengaturan TTL pada catatan NS dengan penyedia layanan DNS saat ini**
+ Gunakan metode yang disediakan oleh penyedia layanan DNS untuk domain saat ini guna mengubah TTL bagi catatan NS di zona yang di-hosting untuk domain Anda.
**Cara menurunkan pengaturan TTL pada catatan NS di zona yang di-hosting Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pilih **Zona yang di-hosting** di panel navigasi.
1. Pilih nama zona yang di-hosting.
1. Pilih catatan NS, dan pilih **Edit**.
1. Mengubah nilai **TTL (Detik)**. Kami rekomendasikan Anda menentukan nilai antara 60 detik hingga 900 detik (15 menit).
1. Pilih **Simpan perubahan**.
## Langkah 5: (Jika Anda telah mengonfigurasi DNSSEC) Menghapus catatan DS dari zona induk
Jika Anda telah mengonfigurasi DNSSEC untuk domain, hapus catatan Delegation Signer (DS) dari zona induk sebelum memigrasi domain ke Route 53.
Jika zona induk di-host melalui Route 53 atau registrar lain, hubungi mereka untuk menghapus catatan DS.
Karena saat ini tidak mungkin untuk mengaktifkan penandatanganan DNSSEC di dua penyedia, Anda harus menghapus DS apa pun atau DNSKEYs menonaktifkan DNSSEC. Hal ini memberi sinyal sementara ke penyelesai DNS untuk menonaktifkan validasi DNSSEC. Di [Langkah 11](#migrate-dns-re-enable-dnssec), Anda dapat mengaktifkan kembali validasi DNSSEC, jika ingin, setelah transisi ke Route 53 selesai.
Untuk informasi selengkapnya, lihat [Menghapus kunci publik untuk domain](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys).
## Langkah 6: Menunggu TTL lama kedaluwarsa
Jika domain Anda sedang digunakan—misalnya, jika pengguna menggunakan nama domain untuk menelusuri situs web atau mengakses aplikasi web—penyelesai DNS telah meng-cache nama server nama yang disediakan oleh penyedia layanan DNS Anda saat ini. Penyelesai DNS yang meng-cache informasi tersebut beberapa menit lalu akan menyimpannya selama hampir dua hari.
Untuk memastikan bahwa semua migrasi layanan DNS ke Route 53 terjadi di satu waktu, tunggu selama dua hari setelah Anda menurunkan TTL. Setelah TTL dua hari kedaluwarsa dan penyelesai meminta server nama untuk domain Anda, penyelesai akan mendapatkan server nama saat ini dan juga akan mendapatkan TTL baru yang Anda tentukan di [Langkah 4: Menurunkan pengaturan TTL](#migrate-dns-lower-ttl).
## Langkah 7: Memperbarui catatan NS untuk menggunakan server nama Route 53
Untuk mulai menggunakan Amazon Route 53 sebagai layanan DNS untuk domain, gunakan metode yang disediakan oleh registrar, atau zona induk, untuk menggantikan server nama saat ini dalam catatan NS dengan server nama Route 53.
**catatan**
Ketika memperbarui catatan NS dengan penyedia layanan DNS saat ini untuk menggunakan server nama Route 53, Anda memperbarui konfigurasi DNS untuk domain. (Hal ini sebanding dengan memperbarui catatan NS di zona yang di-hosting Route 53 untuk domain kecuali Anda memperbarui pengaturan dengan layanan DNS tempat asal migrasi.)
**Cara memperbarui catatan NS di registrar, atau zona induk, untuk menggunakan server nama Route 53**
1. Di konsol Route 53, dapatkan server nama untuk zona yang di-hosting:
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pada panel navigasi, pilih **Zona yang di-hosting**.
1. Pada halaman **Zona yang di-hosting**, pilih nama zona yang di-hosting yang ada.
1. Catat empat nama yang tercantum untuk **Server nama** di bagian **Detail zona yang di-hosting**.
1. Gunakan metode yang disediakan oleh penyedia layanan DNS untuk domain saat ini guna memperbarui catatan NS bagi zona yang di-hosting. Jika domain terdaftar dengan Route 53, lihat [Menambahkan atau mengubah server nama dan merekatkan catatan untuk domain](domain-name-servers-glue-records.md). Proses ini tergantung pada apakah layanan DNS saat ini mengizinkan Anda menghapus server nama:
**Jika Anda dapat menghapus server nama**
+ Catat nama server nama saat ini dalam catatan NS untuk zona yang di-hosting. Jika Anda perlu kembali ke konfigurasi DNS saat ini, berikut adalah server yang akan Anda tentukan.
+ Hapus server nama saat ini dari catatan NS.
+ Perbarui catatan NS dengan nama keempat server nama Route 53 yang Anda dapatkan di langkah 1 dari prosedur ini.
**catatan**
Setelah selesai, satu-satunya server nama dalam catatan NS adalah keempat server nama Route 53 tersebut.
**Jika Anda tidak dapat menghapus server nama**
+ Pilih opsi untuk menggunakan server nama kustom.
+ Tambahkan keempat server nama Route 53 yang Anda dapatkan di langkah 1 prosedur ini.
## Langkah 8: Memantau lalu lintas untuk domain
Memantau lalu lintas untuk domain, termasuk lalu lintas situs web atau aplikasi, dan email:
+ **Jika lalu lintas melambat atau berhenti** – Gunakan metode yang disediakan oleh layanan DNS sebelumnya guna mengembalikan server nama untuk domain ke server nama sebelumnya. Ini adalah server nama yang Anda catat di langkah 7 pada [Cara memperbarui catatan NS di registrar, atau zona induk, untuk menggunakan server nama Route 53](#migrate-dns-change-name-servers-with-provider-procedure). Kemudian tentukan apa yang salah.
+ **Jika lalu lintas tidak terpengaruh** – Lanjutkan ke [Langkah 9: Mengembalikan TTL untuk catatan NS ke nilai yang lebih tinggi](#migrate-dns-change-ttl-back).
## Langkah 9: Mengembalikan TTL untuk catatan NS ke nilai yang lebih tinggi
Di zona yang di-hosting untuk domain Amazon Route 53, ubah TTL untuk catatan NS menjadi nilai yang lebih khas, misalnya 172800 detik (dua hari). Hal ini meningkatkan latensi untuk pengguna Anda karena mereka tidak harus sering menunggu penyelesai DNS mengirim kueri bagi server nama untuk domain Anda.
**Cara mengubah TTL untuk catatan NS di zona yang di-hosting Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pilih **Zona yang di-hosting** di panel navigasi.
1. Pilih nama zona yang di-hosting.
1. Dalam daftar catatan untuk zona yang di-hosting, pilih catatan NS.
1. Pilih **Edit**.
1. Ubah **TTL (detik)** menjadi jumlah detik yang Anda inginkan bagi penyelesai DNS meng-cache nama server nama untuk domain Anda. Kami merekomendasikan nilai 172800 detik.
1. Pilih **Simpan perubahan**.
## Langkah 10: Mentransfer pendaftaran domain ke Amazon Route 53
Sekarang setelah Anda mentransfer layanan DNS untuk domain ke Amazon Route 53, Anda dapat mentransfer pendaftaran domain ke Route 53 secara opsional. Untuk informasi selengkapnya, lihat [Mentransfer pendaftaran untuk domain ke Amazon Route 53](domain-transfer-to-route-53.md).
## Langkah 11: Mengktifkan kembali penandatanganan DNSSEC (jika diperlukan)
Setelah mentransfer layanan DNS untuk domain ke Amazon Route 53, Anda dapat mengaktifkan kembali penandatanganan DNSSEC.
Ada dua langkah untuk mengaktifkan penandatangan DNSSEC:
+ Langkah 1: Aktifkan penandatanganan DNSSEC untuk Route 53, dan minta Route 53 membuat kunci penandatanganan kunci (KSK) berdasarkan kunci yang dikelola pelanggan di AWS Key Management Service ().AWS KMS
+ Langkah 2: Membuat rantai kepercayaan untuk zona yang di-hosting dengan menambahkan catatan Delegation Signer (DS) ke zona induk, sehingga repons DNS dapat diautentikasi dengan tanda tangan kriptografi tepercaya.
Untuk petunjuk, lihat [Mengaktifkan penandatanganan DNSSEC dan membuat rantai kepercayaan](dns-configuring-dnssec-enable-signing.md).
# Membuat Route 53 menjadi layanan DNS untuk domain yang tidak aktif
Jika Anda ingin memigrasi layanan DNS ke Amazon Route 53 untuk domain yang tidak mendapatkan lalu lintas (atau mendapatkan sangat sedikit lalu lintas), lakukan prosedur di bagian ini.
**Topics**
+ [Langkah 1: Dapatkan konfigurasi DNS Anda saat ini dari penyedia layanan DNS saat ini (domain yang tidak aktif)](#migrate-dns-get-zone-file-domain-inactive)
+ [Langkah 2: Membuat zona yang di-hosting (domain tidak aktif)](#migrate-dns-create-hosted-zone-domain-inactive)
+ [Langkah 3: Membuat catatan (domain yang tidak aktif)](#migrate-dns-create-records-domain-inactive)
+ [Langkah 4: Memperbarui pendaftaran domain untuk menggunakan server nama Amazon Route 53 (domain yang tidak aktif)](#migrate-dns-update-domain-inactive)
## Langkah 1: Dapatkan konfigurasi DNS Anda saat ini dari penyedia layanan DNS saat ini (domain yang tidak aktif)
Ketika memigrasi layanan DNS dari penyedia lain ke Route 53, Anda mereproduksi konfigurasi DNS Anda saat ini di Route 53. Di Route 53, Anda membuat zona yang di-hosting dengan nama yang sama seperti domain, dan Anda membuat catatan di zona yang di-hosting. Setiap catatan menunjukkan cara Anda ingin merutekan lalu lintas untuk nama domain atau nama subdomain tertentu. Misalnya, ketika seseorang memasukkan nama domain Anda di browser web, apakah Anda ingin lalu lintas diarahkan ke server web di pusat data Anda, ke instans Amazon EC2, ke CloudFront distribusi, atau ke lokasi lain?
Proses yang Anda gunakan tergantung pada kompleksitas konfigurasi DNS Anda saat ini:
+ **Jika konfigurasi DNS Anda saat ini sederhana** – Jika Anda merutekan lalu lintas internet hanya untuk beberapa subdomain ke sejumlah kecil sumber daya, seperti server web atau bucket Amazon S3, Anda dapat membuat beberapa catatan secara manual di konsol Route 53.
+ **Jika konfigurasi DNS Anda saat ini lebih kompleks, dan Anda hanya ingin mereproduksi konfigurasi saat ini** – Anda dapat menyederhanakan migrasi jika bisa mendapatkan file zona dari penyedia layanan DNS saat ini, dan mengimpor file zona ke Route 53. (Tidak semua penyedia layanan DNS menawarkan file zona.) Ketika Anda mengimpor file zona, Route 53 secara otomatis mereproduksi konfigurasi yang ada dengan membuat catatan yang sesuai di zona yang di-hosting.
Coba tanyakan ke dukungan pelanggan penyedia layanan DNS Anda saat ini tentang cara mendapatkan *file zona* atau *daftar catatan*. Untuk informasi tentang format file zona yang diperlukan, lihat [Membuat catatan dengan mengimpor file zona](resource-record-sets-creating-import.md).
+ **Jika konfigurasi DNS Anda saat ini lebih kompleks, dan Anda tertarik dengan fitur perutean Route 53** – Tinjau dokumentasi berikut untuk melihat apakah Anda ingin menggunakan fitur Route 53 yang tidak tersedia dari penyedia layanan DNS lainnya. Jika iya, Anda dapat membuat catatan secara manual, atau Anda dapat mengimpor file zona lalu membuat atau memperbarui catatan nanti:
+ [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md)menjelaskan keuntungan dari catatan alias Route 53, yang merutekan lalu lintas ke beberapa AWS sumber daya, seperti CloudFront distribusi dan bucket Amazon S3, tanpa biaya.
+ [Memilih kebijakan perutean](routing-policy.md) menjelaskan opsi perutean Route 53, misalnya, perutean berdasarkan lokasi pengguna, perutean berdasarkan latensi antara pengguna dan sumber daya, perutean berdasarkan apakah sumber daya Anda sehat, dan perutean ke sumber daya berdasarkan bobot yang Anda tentukan.
**catatan**
Anda juga dapat mengimpor file zona dan mengubah konfigurasinya nanti untuk memanfaatkan catatan alias dan kebijakan perutean yang kompleks.
Jika Anda tidak bisa mendapatkan file zona atau jika Anda ingin membuat catatan secara manual di Route 53, catatan yang mungkin akan Anda migrasi meliputi:
+ **Catatan (Alamat)** — mengaitkan nama domain atau nama subdomain dengan IPv4 alamat (misalnya, 192.0.2.3) dari sumber daya yang sesuai
+ **Catatan AAAA (Alamat)** — kaitkan nama domain atau nama subdomain dengan IPv6 alamat (misalnya, 2001:0 db 8:85 a 3:0000:0000:abcd: 0001:2345) dari sumber daya yang sesuai
+ **Catatan server email (MX)** – merutekan lalu lintas ke server email
+ **Catatan CNAME** – mengubah rute lalu lintas untuk satu nama domain (example.net) ke nama domain lain (example.com)
+ **Catatan untuk jenis catatan DNS lain yang didukung** – Untuk daftar jeinis catatan yang didukung, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
## Langkah 2: Membuat zona yang di-hosting (domain tidak aktif)
Untuk memberi tahu Amazon Route 53 bagaimana Anda ingin merutekan lalu lintas untuk domain Anda, Anda membuat zona yang dihosting yang memiliki nama yang sama dengan domain Anda, lalu Anda membuat catatan di zona yang dihosting.
**penting**
Anda dapat membuat zona yang di-hosting hanya untuk domain yang izin administrasinya Anda miliki. Biasanya, ini berarti Anda memiliki domain, tetapi Anda mungkin mengembangkan aplikasi untuk pendaftar domain.
Ketika Anda membuat zona yang di-hosting, Route 53 secara otomatis membuat catatan server nama (NS) dan catatan start of authority (SOA) untuk zona. Catatan NS mengidentifikasi empat server nama yang dikaitkan Route 53 dengan zona yang di-hosting. Untuk membuat Route 53 menjadi layanan DNS bagi domain Anda, perbarui pendaftaran domain untuk menggunakan keempat server nama tersebut.
**penting**
Jangan buat server nama (NS) tambahan atau catatan start of authority (SOA), serta jangan hapus catatan NS dan SOA yang sudah ada.
**Cara membuat zona yang di-hosting**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Jika Anda baru mengenal Route 53, pilih **Memulai**.
Jika Anda sudah menggunakan Route 53, pilih **Zona yang di-hosting** pada panel navigasi.
1. Pilih **Buat zona yang di-hosting**.
1. Pada panel **Buat zona yang di-hosting**, masukkan nama domain dan, secara opsional, komentar. Untuk informasi lebih lanjut tentang pengaturan, posisikan penunjuk mouse di atas labelnya untuk melihat kiat alat.
Untuk informasi tentang cara menentukan karakter selain a-z, 0-9, dan - (tanda hubung) serta cara menentukan nama domain internasional, lihat [Format nama domain DNS](DomainNameFormat.md).
1. Untuk **Jenis catatan**, terima nilai default **zona yang di-hosting secara publik**.
1. Pilih **Buat zona yang di-hosting**.
## Langkah 3: Membuat catatan (domain yang tidak aktif)
Setelah membuat zona yang di-hosting, Anda membuat catatan di zona yang di-hosting yang menentukan lokasi tujuan Anda ingin merutekan lalu lintas untuk domain (example.com) atau subdomain (www.example.com). Misalnya, jika ingin merutekan lalu lintas untuk example.com dan www.example.com ke server web pada instans Amazon EC2, Anda membuat dua catatan, satu catatan bernama example.com dan catatan lain bernama www.example.com. Dalam setiap catatan, Anda menentukan alamat IP untuk instans EC2.
Anda dapat membuat catatan dengan berbagai cara:
**Mengimpor file zona**
Ini adalah metode termudah jika Anda mendapatkan file zona dari layanan DNS saat ini di [Langkah 1: Dapatkan konfigurasi DNS Anda saat ini dari penyedia layanan DNS saat ini (domain yang tidak aktif)](#migrate-dns-get-zone-file-domain-inactive). Amazon Route 53 tidak dapat memprediksi kapan catatan alias harus dibuat atau menggunakan jenis perutean khusus seperti tertimbang atau failover. Sebagai hasilnya, jika Anda mengimpor file zona, Route 53 membuat catatan DNS standar menggunakan kebijakan perutean sederhana.
Untuk informasi selengkapnya, lihat [Membuat catatan dengan mengimpor file zona](resource-record-sets-creating-import.md).
**Membuat catatan secara individual di konsol**
Jika Anda tidak mendapatkan file zona dan hanya ingin membuat beberapa catatan dengan kebijakan perutean Sederhana untuk memulai, Anda dapat membuat catatan di konsol Route 53. Anda dapat membuat catatan alias dan non-alias.
Untuk informasi selengkapnya, lihat topik berikut:
+ [Memilih kebijakan perutean](routing-policy.md)
+ [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md)
+ [Membuat catatan dengan menggunakan konsol Amazon Route 53](resource-record-sets-creating.md)
**Membuat catatan secara terprogram**
Anda dapat membuat catatan dengan menggunakan salah satu AWS SDKs, AWS CLI, atau AWS Tools for Windows PowerShell. Untuk informasi selengkapnya, lihat [Dokumentasi AWS](https://docs.aws.amazon.com/).
Jika Anda menggunakan bahasa pemrograman yang AWS tidak menyediakan SDK, Anda juga dapat menggunakan Route 53 API. Untuk informasi lebih lanjut, lihat [Referensi API Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/).
## Langkah 4: Memperbarui pendaftaran domain untuk menggunakan server nama Amazon Route 53 (domain yang tidak aktif)
Setelah selesai membuat catatan untuk domain, Anda dapat mengubah layanan DNS untuk domain Anda menjadi Amazon Route 53. Lakukan prosedur berikut untuk memperbarui pengaturan dengan registrar domain.
**Cara memperbarui server nama untuk domain**
1. Di konsol Route 53, dapatkan server nama untuk zona yang di-hosting Route 53:
1. Buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pada panel navigasi, pilih **Zona yang di-hosting**.
1. Pada halaman **Zona yang di-hosting**, pilih tombol radio (bukan nama) untuk zona yang di-hosting, lalu pilih **Lihat detail**.
1. Pada halaman detail untuk zona yang di-hosting, pilih **Detail zona yang di-hosting**.
1. Catat empat server yang tercantum untuk **Server nama**.
1. Gunakan metode yang disediakan oleh registrar untuk domain untuk mengubah server nama domain untuk menggunakan empat server nama Route 53 yang Anda dapatkan di langkah 2 dari prosedur ini.
Jika domain terdaftar dengan Route 53, lihat [Menambahkan atau mengubah server nama dan merekatkan catatan untuk domain](domain-name-servers-glue-records.md).
# Mengonfigurasi perutean DNS untuk domain baru
**Domain baru yang Anda beli dari Route 53**
Saat Anda mendaftarkan domain dengan Route 53, secara otomatis kami menjadikan Route 53 sebagai layanan DNS untuk domain tersebut. Route 53 menciptakan zona yang di-hosting dengan nama yang sama seperti domain, menetapkan empat server nama untuk zona yang di-hosting, dan memperbarui domain untuk menggunakan server nama tersebut.
**Domain baru yang Anda beli dari registrar lain**
Ketika Anda membeli domain dari registrar lain, misalnya, karena domain tingkat atas (TLD) tidak ditawarkan oleh Route 53, Anda memiliki dua opsi:
+ **Gunakan Route 53 hanya untuk hosting DNS:** Simpan registrar Anda saat ini tetapi delegasikan manajemen DNS ke Route 53. Ikuti prosedur di bawah ini untuk membuat zona yang dihosting dan memperbarui server nama registrar Anda.
+ **Transfer pendaftaran domain ke Route 53:** Jadikan Route 53 sebagai registrar dan layanan DNS Anda. Lihat [Daftar periksa pra-transfer untuk transfer domain](domain-transfer-checklist.md) prasyarat dan [Mentransfer pendaftaran untuk domain ke Amazon Route 53](domain-transfer-to-route-53.md) untuk proses transfer.
Untuk informasi selengkapnya tentang TLDs didukung oleh Route 53, lihat[Domain yang dapat Anda daftarkan dengan Amazon Route 53](registrar-tld-list.md).
Ikuti petunjuk ini untuk membuat zona yang dihosting publik dan kemudian gunakan server nama yang dibuat dengan registrar:
**Untuk membuat zona yang dihosting untuk domain non-Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Di panel navigasi, pilih **Zona yang di-hosting**, lalu pilih **Buat zona yang di-hosting**.
1. Untuk **Nama**, masukkan nama domain yang ingin Anda buat zona yang dihosting, seperti deskripsi opsional`example.com`, pilih Zona yang **dihosting publik, lalu Buat zona** **yang dihosting**.
1. Setelah Anda membuat zona yang dihosting, perhatikan empat catatan server nama (NS) yang dibuat. Masing-masing akan dimulai dengan “ns-”.
Di registrar domain Anda, masukkan server nama dari atas untuk mendelegasikan manajemen domain ke zona host Route 53 Anda.
**Rute lalu lintas DNS**
Untuk menentukan bagaimana Anda ingin Route 53 untuk merutekan lalu lintas internet untuk domain, Anda membuat catatan di zona yang dihosting. Misalnya, jika Anda ingin merutekan permintaan example.com ke server web yang berjalan di EC2 instance Amazon, Anda membuat catatan di zona yang dihosting example.com, dan Anda menentukan alamat IP Elastis untuk instance tersebut. EC2 Untuk informasi selengkapnya, lihat topik berikut:
+ Untuk informasi tentang cara membuat catatan di zona yang di-hosting, lihat [Bekerja dengan catatan](rrsets-working-with.md).
+ Untuk informasi tentang cara merutekan lalu lintas ke AWS sumber daya yang dipilih, lihat[Merutekan lalu lintas internet ke sumber daya Anda AWS](routing-to-aws-resources.md).
+ Untuk informasi selengkapnya tentang cara kerja DNS, lihat [Cara lalu lintas internet dirutekan ke situs web atau aplikasi web Anda](welcome-dns-service.md).
+ Untuk memeriksa DNS repose, lihat. [Memeriksa respons DNS dari Route 53](dns-test.md)
# Merutekan lalu lintas ke sumber daya
Ketika pengguna meminta situs web atau aplikasi web Anda, misalnya, dengan memasukkan nama domain Anda di browser web, Amazon Route 53 membantu mengarahkan pengguna ke sumber daya Anda, seperti bucket Amazon S3 atau server web di pusat data Anda. Untuk mengonfigurasi Route 53 untuk merutekan lalu lintas ke sumber daya Anda, Anda melakukan hal berikut:
1. Membuat zona yang di-hosting. Anda dapat membuat zona yang di-hosting secara publik atau zona yang di-hosting secara privat:
**Zona yang di-hosting secara publik**
Buat zona yang di-hosting secara publik jika Anda ingin merutekan lalu lintas internet ke sumber daya, misalnya, agar pelanggan Anda dapat melihat situs web perusahaan yang Anda host di instans EC2. Untuk informasi selengkapnya, lihat [Bekerja dengan zona yang di-hosting publik](AboutHZWorkingWith.md).
**Zona yang di-hosting secara privat**
Buat zona yang di-hosting secara privat jika Anda ingin merutekan lalu lintas di dalam Amazon VPC. Untuk informasi selengkapnya, lihat [Bekerja dengan zona yang di-hosting privat](hosted-zones-private.md).
1. Membuat catatan di zona yang di-hosting. Catatan menentukan tujuan perutean lalu lintas untuk setiap nama domain atau nama subdomain. Misalnya, untuk merutekan lalu lintas www.example.com ke server web di pusat data, Anda biasanya membuat catatan www.example.com di zona yang di-hosting example.com.
Untuk informasi selengkapnya, lihat topik berikut:
+ [Bekerja dengan catatan](rrsets-working-with.md)
+ [Merutekan lalu lintas untuk subdomain](dns-routing-traffic-for-subdomains.md)
+ [Merutekan lalu lintas internet ke sumber daya Anda AWS](routing-to-aws-resources.md)
# Merutekan lalu lintas untuk subdomain
Jika ingin merutekan lalu lintas subdomain ke sumber daya, seperti acme.example.com atau zenith.example.com, Anda memiliki dua opsi:
**Membuat catatan di zona yang di-hosting untuk domain**
Biasanya, untuk merutekan lalu lintas subdomain, Anda membuat catatan di zona yang di-hosting yang memiliki nama yang sama seperti domain. Misalnya, untuk merutekan lalu lintas interner acme.example.com ke server web di pusat data, Anda membuat catatan bernama acme.example.com dalam zona yang di-hosting example.com. Untuk informasi selengkapnya, lihat topik [Bekerja dengan catatan](rrsets-working-with.md) dan subtopiknya.
**Membuat zona yang di-hosting untuk subdomain, dan membuat catatan di zona yang di-hosting baru**
Anda juga dapat membuat zona yang di-hosting untuk subdomain. Menggunakan zona yang di-hosting terpisah untuk merutekan lalu lintas internet bagi subdomain terkadang dikenal sebagai "mendelegasikan tanggung jawab untuk subdomain ke zona yang di-hosting" atau "mendelegasikan subdomain ke server nama lain" atau beberapa kombinasi istilah yang serupa. Berikut adalah gambaran umum cara kerjanya:
1. Anda membuat zona yang di-hosting dengan nama yang sama seperti subdomain yang lalu lintasnya ingin Anda rutekan, seperti acme.example.com.
1. Anda membuat catatan di zona yang di-hosting baru yang menentukan cara Anda ingin merutekan lalu lintas untuk subdomain (acme.example.com) dan subdomain-nya, seperti backend.acme.example.com.
1. Anda mendapatkan server nama yang ditetapkan Route 53 ke zona yang di-hosting baru ketika Anda membuatnya.
1. Anda membuat catatan NS baru di zona yang dihosting untuk domain (example.com). Nama catatan NS harus nama subdomain (acme.example.com), dan Anda menentukan empat server nama yang Anda dapatkan di langkah 3 sebagai nilai catatan.
Ketika menggunakan zona yang di-hosting terpisah untuk merutekan lalu lintas subdomain, Anda dapat menggunakan izin IAM untuk membatasi akses ke zona yang di-hosting bagi subdomain. Jika Anda memiliki beberapa subdomain yang dikelola oleh grup yang berbeda, membuat zona yang di-hosting untuk setiap subdomain secara signifikan dapat mengurangi jumlah orang yang harus memiliki akses ke catatan dalam zona yang di-hosting untuk domain.
Untuk mengimplementasikan proses delegasi ini, Anda memerlukan izin IAM berikut. Untuk informasi selengkapnya tentang kebijakan IAM Route 53, lihat[Identity and access management di Amazon Route 53](security-iam.md):
**Akun induk (memiliki example.com)**
Pengguna atau peran memerlukan izin untuk mengubah catatan di zona host domain induk:
**Akun anak (membuat acme.example.com)**
Pengguna atau peran memerlukan izin untuk membuat dan mengelola zona host subdomain:
Menggunakan zona yang di-hosting terpisah untuk subdomain juga memungkinkan Anda menggunakan layanan DNS yang berbeda bagi domain dan subdomain. Untuk informasi selengkapnya, lihat [Menggunakan Amazon Route 53 sebagai layanan DNS untuk subdomain tanpa memigrasi domain induk](creating-migrating.md).
Ada dampak kecil pada performa untuk konfigurasi ini bagi kueri DNS pertama dari setiap penyelesai DNS. Penyelesai harus mendapatkan informasi dari zona yang di-hosting bagi domain root lalu mendapatkan informasi dari zona yang di-hosting untuk subdomain. Setelah kueri DNS pertama untuk subdomain, penyelesai meng-cache informasi dan tidak perlu mendapatkannya lagi hingga TTL berakhir dan klien lain meminta subdomain dari penyelesai tersebut. Untuk informasi selengkapnya, lihat [TTL (detik)](resource-record-sets-values-basic.md#rrsets-values-basic-ttl) di bagian [Nilai yang Anda tentukan saat membuat atau mengedit catatan Amazon Route 53](resource-record-sets-values.md).
**Topics**
+ [Membuat zona yang di-hosting lainnya untuk merutekan lalu lintas bagi subdomain](#dns-routing-traffic-for-subdomains-new-hosted-zone)
+ [Merutekan lalu lintas untuk tingkat subdomain tambahan](#dns-routing-traffic-for-sub-subdomains)
## Membuat zona yang di-hosting lainnya untuk merutekan lalu lintas bagi subdomain
Cara merutekan lalu lintas untuk subdomain adalah membuat zona yang di-hosting untuk subdomain, lalu membuat catatan untuk subdomain di zona yang di-hosting baru. (Opsi yang lebih umum adalah membuat catatan untuk subdomain di zona yang di-hosting untuk domain.)
**catatan**
Prosedur ini menunjukkan cara mendelegasikan subdomain ke Route 53. Anda juga dapat mendelegasikan subdomain ke layanan DNS lain dengan membuat catatan NS yang mengarah ke server nama layanan tersebut.
Berikut adalah gambaran umum prosesnya:
1. Membuat zona yang di-hosting untuk subdomain. Untuk informasi selengkapnya, lihat [Membuat zona yang di-hosting baru untuk subdomain](#dns-routing-traffic-for-subdomains-creating-hosted-zone).
1. Menambahkan catatan ke zona yang di-hosting untuk subdomain. Jika zona yang di-hosting untuk domain berisi catatan yang merupakan bagian dari zona yang di-hosting untuk subdomain, duplikatkan catatan tersebut di zona yang di-hosting untuk subdomain. Untuk informasi selengkapnya, lihat [Membuat catatan di zona yang di-hosting untuk subdomain](#dns-routing-traffic-for-subdomains-creating-records)
1. Membuat catatan NS untuk subdomain di zona yang di-hosting untuk domain, yang mendelegasikan tanggung jawab untuk subdomain ke server nama di zona yang di-hosting baru. Jika zona yang di-hosting untuk domain berisi catatan yang merupakan bagian dari zona yang di-hosting untuk subdomain, hapus catatan tersebut dari zona yang di-hosting untuk subdomain. (Anda membuat salinan di zona yang di-hosting untuk subdomain di langkah 2.) Untuk informasi selengkapnya, lihat [Memperbarui zona yang di-hosting untuk domain](#dns-routing-traffic-for-subdomains-delegating-responsibility).
### Membuat zona yang di-hosting baru untuk subdomain
Untuk membuat zona yang di-hosting bagi subdomain menggunakan konsol Route 53, lakukan prosedur berikut.
**Cara membuat zona yang di-hosting untuk subdomain (konsol)**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Jika Anda baru mengenal Route 53, pilih **Memulai**.
Jika Anda sudah menggunakan Route 53, pilih **Zona yang di-hosting** pada panel navigasi.
1. Pilih **Buat zona yang di-hosting**.
1. Di panel kanan, masukkan nama subdomain, seperti acme.example.com. Secara opsional Anda juga dapat memasukkan komentar.
Untuk informasi tentang cara menentukan karakter selain a-z, 0-9, dan - (tanda hubung) serta cara menentukan nama domain internasional, lihat [Format nama domain DNS](DomainNameFormat.md).
1. Untuk **Jenis**, terima nilai default **Zona yang di-hosting publik**.
1. Di bagian bawah panel kanan, pilih **Buat zona yang di-hosting**.
### Membuat catatan di zona yang di-hosting untuk subdomain
Untuk menentukan bagaimana Anda ingin Route 53 untuk merutekan lalu lintas untuk subdomain (acme.example.com) dan subdomainnya (backend.acme.example.com), Anda membuat catatan di zona yang dihosting untuk subdomain.
Perhatikan penjelasan berikut tentang membuat catatan di zona yang di-hosting untuk subdomain:
+ Jangan buat server nama (NS) tambahan atau catatan start of authority (SOA) di zona yang di-hosting untuk subdomain, serta jangan hapus catatan NS dan SOA yang sudah ada.
+ Buat semua catatan untuk subdomain di dalam zona yang di-hosting untuk subdomain. Misalnya, jika Anda memiliki zona yang di-hosting untuk example.com dan domain acme.example.com, buat semua catatan untuk subdomain acme.example.com di zona yang di-hosting acme.example.com. Ini termasuk catatan seperti backend.acme.example.com dan beta.backend.acme.example.com.
+ Jika zona yang di-hosting untuk domain (example.com) telah berisi catatan yang merupakan bagian dari zona yang di-hosting untuk subdomain (acme.example.com), duplikatkan catatan tersebut di zona yang di-hosting untuk subdomain. Pada langkah terakhir dari proses, Anda menghapus data duplikat dari zona yang di-hosting untuk domain.
**penting**
Jika Anda memiliki beberapa catatan untuk subdomain di zona yang di-hosting domain dan zona yang di-hosting untuk subdomain, perilaku DNS akan menjadi tidak konsisten. Perilaku akan tergantung pada server nama penyelesai DNS yang telah di-cache, server nama untuk zona yang di-hosting domain (example.com) atau server nama untuk zona yang di-hosting subdomain (acme.example.com). Dalam beberapa kasus, Route 53 akan mengembalikan NXDOMAIN (tidak ada domain) ketika catatan ada, tetapi tidak di zona yang di-hosting yang menjadi tujuan kueri yang dikirimkan oleh penyelesai DNS.
Untuk informasi selengkapnya, lihat [Bekerja dengan catatan](rrsets-working-with.md).
### Memperbarui zona yang di-hosting untuk domain
Saat Anda membuat zona yang di-hosting, Route 53 secara otomatis menetapkan empat server nama ke zona. Catatan NS untuk zona yang di-hosting mengidentifikasi server nama yang merespons kueri DNS bagi domain atau subdomain. Untuk mulai menggunakan catatan di zona yang di-hosting bagi subdomain guna merutekan lalu lintas internet, Anda membuat catatan NS baru di zona yang di-hosting untuk domain (example.com), dan memberinya nama subdomain (acme.example.com). Untuk nilai catatan NS, Anda menentukan nama untuk server nama dari zona yang di-hosting bagi subdomain.
Inilah yang terjadi jika Route 53 menerima kueri DNS dari penyelesai DNS untuk subdomain acme.example.com atau salah satu subdomainnya:
1. Route 53 terlihat di zona yang di-hosting untuk domain (example.com) dan menemukan catatan NS untuk subdomain (acme.example.com).
1. Route 53 mendapatkan server nama dari catatan NS acme.example.com di zona yang di-hosting untuk domain, example.com, dan mengembalikan server nama ke penyelesai DNS.
1. Penyelesai mengirimkan ulang kueri untuk acme.example.com ke server nama untuk zona yang di-hosting acme.example.com.
1. Route 53 merespons kueri menggunakan catatan dalam zona yang di-hosting acme.example.com.
Untuk mengonfigurasi Route 53 untuk merutekan lalu lintas untuk subdomain menggunakan zona yang dihosting untuk subdomain dan untuk menghapus catatan duplikat apa pun dari zona yang dihosting untuk domain, lakukan prosedur berikut:
**Untuk mengonfigurasi Route 53 agar menggunakan zona yang di-hosting bagi subdomain (konsol)**
1. Di konsol Route 53, dapatkan server nama untuk zona yang di-hosting bagi subdomain:
1. Pada panel navigasi, pilih **Zona yang di-hosting**.
1. Pada halaman **Zona yang di-hosting**, pilih nama zona yang di-hosting untuk subdomain.
1. Pada panel kanan, salin nama dari empat server yang terdaftar untuk **Server nama** di bagian **Detail zona yang di-hosting**.
1. Pilih nama zona yang di-hosting untuk domain (example.com), bukan untuk subdomain.
1. Pilih **Buat catatan**.
1. Pilih **Perutean sederhana**, dan pilih **Selanjutnya**.
1. Pilih **Tentukan catatan sederhana**.
1. Tentukan nilai-nilai berikut ini:
**Nama**
Masukkan nama subdomain (misalnya,`acme.example.com`). Ini harus sama persis dengan nama zona host subdomain yang Anda buat.
**Nilai/Rutekan lalu lintas ke**
Pilih **alamat IP atau nilai lain tergantung pada jenis catatan**, dan tempel nama-nama server nama yang Anda salin di langkah 1.
**Jenis catatan**
Pilih **NS – Server nama untuk zona yang di-hosting**.
**TTL (Detik)**
Ubah ke nilai yang lebih umum untuk catatan NS, seperti 172800 detik.
1. Pilih **Tentukan catatan sederhana**, dan pilih **Buat catatan**.
1. Jika zona yang di-hosting untuk domain berisi catatan yang Anda buat ulang di zona yang di-hosting untuk subdomain, hapus catatan tersebut dari zona yang di-hosting untuk subdomain. Untuk informasi selengkapnya, lihat [Menghapus catatan](resource-record-sets-deleting.md).
Setelah Anda selesai, semua catatan untuk subdomain seharusnya berada di dalam zona yang di-hosting untuk subdomain.
## Merutekan lalu lintas untuk tingkat subdomain tambahan
Anda merutekan lalu lintas ke subdomain dari subdomain, seperti backend.acme.example.com, dengan cara yang sama seperti merutekan lalu lintas ke subdomain, seperti acme.example.com. Baik Anda membuat catatan di zona yang di-hosting untuk domain, atau membuat zona yang di-hosting untuk subdomain tingkat yang lebih rendah, lalu membuat catatan di zona yang di-hosting baru.
Jika Anda memilih untuk membuat zona yang di-hosting terpisah untuk subdomain tingkat yang lebih rendah, buat catatan NS untuk subdomain tingkat yang lebih rendah di zona yang di-hosting untuk subdomain yang satu tingkat lebih dekat dengan nama domain. Tindakan ini membantu memastikan bahwa lalu lintas dirutekan dengan benar ke sumber daya Anda. Sebagai contoh, Anda ingin merutekan lalu lintas untuk subdomain berikut:
+ subdomain1.example.com
+ subdomain2.subdomain1.example.com
Untuk menggunakan zona yang di-hosting lainnya guna merutekan lalu lintas bagi subdomain2.subdomain1.example.com, lakukan hal berikut:
1. Membuat zona yang di-hosting bernama subdomain2.subdomain1.example.com.
1. Membuat catatan di zona yang di-hosting subdomain2.subdomain1.example.com. Untuk informasi selengkapnya, lihat [Membuat catatan di zona yang di-hosting untuk subdomain](#dns-routing-traffic-for-subdomains-creating-records).
1. Salin nama server nama untuk zona yang di-hosting subdomain2.subdomain1.example.com.
1. Di zona yang di-hosting subdomain1.example.com, buat catatan NS bernama subdomain2.subdomain1.example.com, dan tempel nama server nama untuk zona yang di-hosting subdomain2.subdomain1.example.com.
Selain itu, hapus data duplikat dari subdomain1.example.com. Untuk informasi selengkapnya, lihat [Memperbarui zona yang di-hosting untuk domain](#dns-routing-traffic-for-subdomains-delegating-responsibility).
Setelah Anda membuat catatan NS ini, Route 53 mulai menggunakan zona host subdomain2.subdomain1.example.com untuk merutekan lalu lintas subdomain2.subdomain1.example.com subdomain.
# Bekerja dengan zona yang di-hosting
Zona yang di-hosting adalah kontainer untuk catatan, dan catatan berisi informasi tentang cara merutekan lalu lintas untuk domain tertentu, seperti example.com, dan subdomainnya (acme.example.com, zenith.example.com). Zona yang di-hosting dan domain yang sesuai memiliki nama yang sama. Ada dua tipe zona yang di-hosting:
+ *Zona yang di-hosting publik* berisi catatan yang menentukan bagaimana Anda ingin merutekan lalu lintas di internet. Untuk informasi selengkapnya, lihat [Bekerja dengan zona yang di-hosting publik](AboutHZWorkingWith.md).
+ *Zona yang di-hosting publik* berisi catatan yang menentukan bagaimana Anda ingin merutekan lalu lintas di Amazon VPC. Untuk informasi selengkapnya, lihat [Bekerja dengan zona yang di-hosting privat](hosted-zones-private.md).
# Bekerja dengan zona yang di-hosting publik
Zona yang di-hosting publik adalah kontainer yang berisi informasi tentang cara merutekan lalu lintas di internet untuk domain tertentu, seperti example.com, dan subdomainnya (acme.example.com, zenith.example.com). Anda mendapatkan zona yang di-hosting publik dengan salah satu dari dua cara berikut:
+ Ketika Anda mendaftarkan domain dengan Amazon Route 53, kami membuat zona yang di-hosting secara otomatis untuk Anda.
+ Ketika mentransfer layanan DNS untuk domain yang ada ke Route 53, Anda memulai dengan membuat zona yang di-hosting untuk domain. Untuk informasi selengkapnya, lihat [Membuat Amazon Route 53 menjadi layanan DNS untuk domain yang adaMembuat Route 53 menjadi layanan DNS untuk domain yang ada](MigratingDNS.md).
Di kedua kasus, kemudian Anda membuat catatan di zona yang di-hosting untuk menentukan cara merutekan lalu lintas bagi domain dan subdomain. Misalnya, Anda dapat membuat catatan untuk merutekan lalu lintas www.example.com ke CloudFront distribusi atau ke server web di pusat data Anda. Untuk informasi lebih lanjut tentang catatan, lihat [Bekerja dengan catatan](rrsets-working-with.md).
Topik ini menjelaskan cara menggunakan konsol Amazon Route 53 untuk membuat, mencantumkan, dan menghapus zona yang di-hosting publik.
**catatan**
Anda juga dapat menggunakan zona host *pribadi* Route 53 untuk merutekan lalu lintas dalam satu atau lebih VPCs yang Anda buat dengan layanan Amazon VPC. Untuk informasi selengkapnya, lihat [Bekerja dengan zona yang di-hosting privat](hosted-zones-private.md).
**Topics**
+ [Pertimbangan saat bekerja dengan zona yang di-hosting publik](hosted-zone-public-considerations.md)
+ [Membuat zona yang di-hosting publik](CreatingHostedZone.md)
+ [Mendapatkan server nama untuk zona yang di-hosting publik](GetInfoAboutHostedZone.md)
+ [Mencantumkan zona yang di-hosting publik](ListInfoOnHostedZone.md)
+ [Melihat metrik kueri DNS untuk zona yang di-hosting publik](hosted-zone-public-viewing-query-metrics.md)
+ [Menghapus zona yang di-hosting publik](DeleteHostedZone.md)
+ [Memeriksa respons DNS dari Route 53](dns-test.md)
+ [Mengonfigurasi server nama label putih](white-label-name-servers.md)
+ [Catatan NS dan SOA yang dibuat Amazon Route 53 untuk zona yang di-hosting publik](SOA-NSrecords.md)
+ [Mengaktifkan pemulihan yang dipercepat untuk mengelola catatan DNS publik](accelerated-recovery.md)
# Pertimbangan saat bekerja dengan zona yang di-hosting publik
Perhatikan pertimbangan berikut saat bekerja dengan zona yang di-hosting publik:
**Catatan NS dan SOA**
Ketika Anda membuat zona yang di-hosting, Amazon Route 53 secara otomatis membuat catatan server nama (NS) dan catatan start of authority (SOA) untuk zona. Catatan NS mengidentifikasi empat server nama yang Anda berikan ke registrar atau layanan DNS sehingga kueri DNS dirutekan ke server nama Route 53. Untuk informasi lebih lanjut tentang catatan NS dan SOA, lihat [Catatan NS dan SOA yang dibuat Amazon Route 53 untuk zona yang di-hosting publik](SOA-NSrecords.md).
**Beberapa zona yang di-hosting dengan nama yang sama**
Anda dapat membuat lebih dari satu zona yang di-hosting dengan nama yang sama dan menambahkan catatan yang berbeda ke setiap zona yang di-hosting. Route 53 menetapkan empat server nama untuk setiap zona yang di-hosting, dan server nama berbeda untuk setiap zona. Saat Anda memperbarui catatan server nama registrar, perhatikan untuk menggunakan server nama Route 53 untuk zona yang di-hosting yang benar—zona yang berisi catatan yang akan digunakan Route 53 saat merespons kueri untuk domain Anda. Route 53 tidak pernah mengembalikan nilai untuk catatan di zona yang di-hosting lain dengan nama yang sama.
**Set delegasi yang dapat digunakan kembali**
Secara default, Route 53 menetapkan satu set empat nama server yang unik (dikenal secara kolektif sebagai set delegasi) untuk setiap zona yang di-hosting yang Anda buat. Jika ingin membuat sejumlah besar zona yang di-hosting, Anda dapat membuat set delegasi yang dapat digunakan kembali secara terprogram. (Set delegasi yang dapat digunakan kembali tidak tersedia di konsol Route 53.) Kemudian Anda dapat membuat zona yang di-hosting secara terprogram dan menetapkan set delegasi yang dapat digunakan kembali yang sama—empat server nama yang sama—ke setiap zona yang di-hosting.
Set delegasi yang dapat digunakan kembali menyederhanakan migrasi layanan DNS ke Route 53 karena Anda dapat menginstruksikan registrar nama domain untuk menggunakan empat server nama yang sama untuk semua domain yang ingin diggunakan Route 53 sebagai layanan DNS. Untuk informasi selengkapnya, lihat [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)di *Referensi API Amazon Route 53*.
# Membuat zona yang di-hosting publik
Zona yang di-hosting publik adalah kontainer yang berisi informasi tentang cara merutekan lalu lintas di internet untuk domain tertentu, seperti example.com, dan subdomainnya (acme.example.com, zenith.example.com). Setelah membuat catatan di zona yang di-hosting, buat catatan yang menentukan cara merutekan lalu lintas untuk domain dan subdomain.
**Pembatasan**
Perhatikan batasan berikut untuk membuat zona yang dihosting dengan Route 53.
Anda dapat membuat zona yang di-hosting hanya untuk domain yang izin administrasinya Anda miliki. Biasanya, ini berarti Anda memiliki domain, tetapi Anda mungkin mengembangkan aplikasi untuk pendaftar domain.
Anda dapat membuat zona yang dihosting hanya untuk domain dan subdomain. Route 53 tidak mendukung hosting domain tingkat atas (TLD) seperti. `.com`
**Cara membuat zona yang di-hosting publik menggunakan konsol Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Jika Anda baru mengenal Route 53, pilih **Memulai** di bawah **Manajemen DNS**.
Jika Anda sudah menggunakan Route 53, pilih **Zona yang di-hosting** pada panel navigasi.
1. Pilih **Buat Zona yang di-hosting**.
1. Di panel **Buat Zona yang Di-hosting**, masukkan nama domain yang lalu lintasnya ingin Anda rutekan. Secara opsional Anda juga dapat memasukkan komentar.
Untuk informasi tentang cara menentukan karakter selain a-z, 0-9, dan - (tanda hubung) serta cara menentukan nama domain internasional, lihat [Format nama domain DNS](DomainNameFormat.md).
1. Untuk **Jenis**, terima nilai default **Zona yang Di-hosting Publik**.
1. Pilih **Buat**.
1. Membuat catatan yang menentukan cara merutekan lalu lintas untuk domain dan subdomain. Untuk informasi selengkapnya, lihat [Bekerja dengan catatan](rrsets-working-with.md).
1. Untuk menggunakan catatan di zona yang di-hosting baru untuk merutekan lalu lintas domain Anda, lihat topik yang berlaku:
+ Jika Anda membuat Route 53 sebagai layanan DNS untuk domain yang terdaftar dengan registrar domain lain, lihat [Membuat Amazon Route 53 menjadi layanan DNS untuk domain yang adaMembuat Route 53 menjadi layanan DNS untuk domain yang ada](MigratingDNS.md).
+ Jika domain terdaftar dengan Route 53, lihat [Menambahkan atau mengubah server nama dan merekatkan catatan untuk domain](domain-name-servers-glue-records.md).
# Mendapatkan server nama untuk zona yang di-hosting publik
Anda mendapatkan server nama untuk zona yang di-hosting publik jika ingin mengubah layanan DNS untuk pendaftaran domain. Untuk informasi tentang cara mengubah layanan DNS, lihat [Membuat Amazon Route 53 menjadi layanan DNS untuk domain yang adaMembuat Route 53 menjadi layanan DNS untuk domain yang ada](MigratingDNS.md).
**catatan**
Beberapa registrar hanya mengizinkan Anda menentukan server nama menggunakan alamat IP; mereka tidak mengizinkan Anda menentukan nama domain yang memenuhi syarat. Jika registrar memerlukan penggunaan alamat IP, Anda bisa mendapatkan alamat IP untuk server nama menggunakan utilitas penggalian (untuk Mac, Unix, atau Linux) atau utilitas nslookup (untuk Windows). Kami jarang mengubah alamat IP server nama; jika kami perlu mengubah alamat IP, kami akan memberitahu Anda terlebih dahulu.
**Cara mendapatkan server nama untuk zona yang di-hosting menggunakan konsol Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Dalam panel navigasi, klik **Zona yang di-hosting**.
1. Pada halaman **Zona yang di-hosting**, pilih tombol radio (bukan nama) untuk zona yang di-hosting, lalu pilih **Lihat detail**.
1. Pada halaman detail untuk zona yang di-hosting, pilih **Detail zona yang di-hosting**.
1. Catat empat server yang tercantum untuk **Server nama**.
# Mencantumkan zona yang di-hosting publik
Anda dapat menggunakan konsol Amazon Route 53 untuk mencantumkan semua zona yang dihosting yang Anda buat dengan AWS akun saat ini. Untuk informasi tentang cara mencantumkan zona yang dihosting menggunakan API Route 53, lihat [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)di *Referensi API Amazon Route 53*.
**Untuk membuat daftar zona yang dihosting publik yang terkait dengan AWS akun menggunakan konsol Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pada panel navigasi, pilih **Zona yang di-hosting**. Halaman ini menampilkan daftar zona yang dihosting yang terkait dengan AWS akun yang saat ini Anda masuki.
1. Untuk memfilter zona yang di-hosting, gunakan bilah pencarian yang terletak di bagian atas tabel.
Perilaku pencarian tergantung pada apakah zona yang di-hosting berisi hingga 2.000 catatan atau lebih dari 2.000 catatan:
**Hingga 2.000 zona yang dihosting**
+ Untuk menampilkan catatan yang memiliki nilai tertentu, klik bilah pencarian, pilih properti di daftar dropdown, dan masukkan nilai. Anda juga dapat memasukkan nilai secara langsung di bilah pencarian dan tekan Enter. Misalnya, untuk menampilkan zona yang di-hosting dengan nama yang dimulai dengan **abc**, masukkan nilai tersebut di bilah pencarian dan tekan Enter.
+ Untuk hanya menampilkan zona yang di-hosting dengan jenis zona yang di-hosting yang sama, pilih jenis dalam daftar dropdown, dan masukkan jenis.
**Lebih dari 2.000 zona yang dihosting**
+ Anda dapat mencari properti berdasarkan nama domain yang tepat, semua properti, dan jenis.
+ Cari menggunakan nama domain yang tepat untuk hasil pencarian yang lebih cepat.
# Melihat metrik kueri DNS untuk zona yang di-hosting publik
Anda dapat melihat jumlah total kueri DNS yang direspons Route 53 untuk zona yang di-hosting publik tertentu atau kombinasi zona yang di-hosting publik. Metrik muncul CloudWatch, yang memungkinkan Anda melihat grafik, memilih periode waktu yang ingin Anda lihat, dan menyesuaikan metrik dengan berbagai cara lain. Anda juga dapat membuat alarm dan mengonfigurasi notifikasi, sehingga Anda diberi tahu jika jumlah kueri DNS dalam jangka waktu tertentu berada di atas atau di bawah tingkat yang ditentukan.
**catatan**
Route 53 secara otomatis mengirimkan jumlah kueri DNS CloudWatch untuk semua zona yang dihosting publik, jadi Anda tidak perlu mengonfigurasi apa pun sebelum dapat melihat metrik kueri. Tidak ada biaya untuk metrik kueri DNS.
**Manakah kueri DNS yang dihitung?**
Metrik hanya berisi kueri yang diteruskan pemecah masalah DNS ke Route 53. Jika pemecah masalah DNS telah meng-cache respons untuk kueri (seperti alamat IP untuk penyeimbang beban bagi example.com), pemecah masalah akan terus mengembalikan respons yang di-cache tanpa meneruskan kueri ke Route 53 hingga TTL untuk catatan yang sesuai kedaluwarsa.
Tergantung pada jumlah kueri DNS yang dikirim untuk nama domain (example.com) atau nama subdomain (www.example.com), penyelesai yang digunakan pengguna, dan TTL untuk catatan, metrik kueri DNS mungkin berisi informasi tentang satu kueri saja dari beberapa ribu permintaan yang dikirimkan ke penyelesai DNS. Untuk informasi selengkapnya tentang cara kerja DNS, lihat [Cara Amazon Route 53 merutekan lalu lintas untuk domain Anda](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
**Kapan metrik kueri untuk zona yang dihosting mulai muncul? CloudWatch**
Setelah Anda membuat zona yang dihosting, ada penundaan hingga beberapa jam sebelum zona yang dihosting dapat muncul CloudWatch. Selain itu, Anda harus mengirimkan kueri DNS untuk catatan di zona yang di-hosting agar ada data untuk ditampilkan.
**Metrik hanya tersedia di US East (N. Virginia)**
Untuk mendapatkan metrik di konsol, Anda harus memilih US East (N. Virginia) untuk Wilayah. Untuk mendapatkan metrik menggunakan AWS CLI, Anda harus membiarkan AWS Wilayah tidak ditentukan, atau `us-east-1` tentukan sebagai Wilayah. Metrik Route 53 tidak tersedia jika Anda memilih Wilayah lain.
**CloudWatch metrik dan dimensi untuk kueri DNS**
Untuk informasi tentang CloudWatch metrik dan dimensi untuk kueri DNS, lihat. [Memantau zona yang dihosting menggunakan Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md) Untuk informasi tentang CloudWatch metrik, lihat [Menggunakan CloudWatch metrik Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) di * CloudWatch Panduan Pengguna Amazon*.
**Mendapatkan data yang lebih detail tentang kueri DNS**
Untuk mendapatkan informasi lebih detail tentang setiap kueri DNS yang direspons Route 53, termasuk nila berikut, Anda dapat menonfigurasi pencatatan kueri:
+ Domain atau subdomain yang diminta
+ Tanggal dan waktu permintaan
+ Tipe catatan DNS (seperti A atau AAAA)
+ Lokasi edge Route 53 yang merespons kueri DNS
+ Kode respons DNS, seperti `NoError` atau `ServFail`
Untuk informasi selengkapnya, lihat [Pencatatan kueri DNS publik](query-logs.md).
**Cara mendapatkan metrik kueri DNS**
Tak lama setelah Anda membuat zona yang dihosting, Amazon Route 53 mulai mengirim metrik dan dimensi sekali dalam satu menit. CloudWatch Anda dapat menggunakan prosedur berikut untuk melihat metrik di CloudWatch konsol atau melihatnya menggunakan AWS Command Line Interface (AWS CLI).
**Topics**
+ [Melihat metrik kueri DNS untuk zona yang dihosting publik di konsol CloudWatch](#hosted-zone-public-viewing-query-metrics-console)
+ [Mendapatkan metrik kueri DNS menggunakan AWS CLI](#hosted-zone-public-viewing-query-metrics-cli)
## Melihat metrik kueri DNS untuk zona yang dihosting publik di konsol CloudWatch
Untuk melihat metrik kueri DNS untuk zona yang dihosting publik di CloudWatch konsol, lakukan prosedur berikut.
**Untuk melihat metrik kueri DNS untuk zona yang dihosting publik di konsol CloudWatch**
1. Masuk ke Konsol Manajemen AWS dan buka CloudWatch konsol di [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Pada panel navigasi, silakan pilih **Metrik**.
1. Pada daftar AWS Wilayah di sudut kanan atas konsol, pilih **US East (Virginia N.)**. Metrik Route 53 tidak tersedia jika Anda memilih AWS Wilayah lain.
1. Pada tab **Semua metrik**, pilih **Route 53**.
1. Pilih **Metrik Zona yang Di-hosting**.
1. Pilih kotak centang untuk satu atau beberapa zona yang dihosting yang memiliki nama metrik **DNSQueries**.
1. Pada tab **Metrik grafis**, ubah nilai yang ada untuk melihat metrik dalam format yang Anda inginkan.
Untuk **Statistik**, pilih **Jumlah** atau **SampleCount**; statistik ini keduanya menampilkan nilai yang sama.
## Mendapatkan metrik kueri DNS menggunakan AWS CLI
Untuk mendapatkan metrik kueri DNS menggunakan AWS CLI, Anda menggunakan perintah. [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) Perhatikan hal-hal berikut:
+ Anda menentukan sebagian besar nilai untuk perintah dalam file JSON terpisah. Untuk informasi selengkapnya, lihat [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html).
+ Perintah mengembalikan satu nilai bagi setiap interval yang Anda tentukan untuk `Period` dalam file JSON.`Period` dalam hitungan detik, jadi jika Anda menentukan jangka waktu lima menit dan menentukan `60` untuk `Period`, Anda mendapatkan nilai lima. Jika Anda menentukan jangka waktu lima menit dan menentukan `300` untuk `Period`, Anda mendapatkan nilai satu.
+ Dalam file JSON, Anda dapat menentukan nilai apapun untuk `Id`.
+ Biarkan AWS Wilayah tidak ditentukan, atau tentukan `us-east-1` sebagai Wilayah. Metrik Route 53 tidak tersedia jika Anda memilih Wilayah lain. Untuk informasi selengkapnya, lihat [Mengonfigurasi AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) di Panduan Pengguna *AWS Command Line Interface .*
Berikut adalah AWS CLI perintah yang Anda gunakan untuk mendapatkan metrik kueri DNS untuk periode waktu lima menit antara 4:01 dan 4:07 pada 1 Mei 2019. Parameter `metric-data-queries` merujuk file JSON sampel yang mengikuti perintah.
```
aws cloudwatch get-metric-data --metric-data-queries file://./metric.json --start-time 2019-05-01T04:01:00Z --end-time 2019-05-01T04:07:00Z
```
Berikut adalah file JSON sampel:
```
[
{
"Id": "my_dns_queries_id",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Route53",
"MetricName": "DNSQueries",
"Dimensions": [
{
"Name": "HostedZoneId",
"Value": "Z1D633PJN98FT9"
}
]
},
"Period": 60,
"Stat": "Sum"
},
"ReturnData": true
}
]
```
Inilah output dari perintah ini. Perhatikan hal-hal berikut:
+ Waktu mulai dan waktu selesai dalam perintah mencakup periode waktu tujuh menit, `2019-05-01T04:01:00Z` hingga `2019-05-01T04:07:00Z`.
+ Hanya ada enam nilai kembali. Tidak ada nilai untuk `2019-05-01T04:05:00Z` karena tidak ada kueri DNS selama menit tersebut.
+ Nilai `Period` yang ditentukan dalam file JSON adalah `60` (detik), sehingga nilai dilaporkan dalam interval satu menit.
```
{
"MetricDataResults": [
{
"Id": "my_dns_queries_id",
"StatusCode": "Complete",
"Label": "DNSQueries",
"Values": [
101.0,
115.0,
103.0,
127.0,
111.0,
120.0
],
"Timestamps": [
"2019-05-01T04:07:00Z",
"2019-05-01T04:06:00Z",
"2019-05-01T04:04:00Z",
"2019-05-01T04:03:00Z",
"2019-05-01T04:02:00Z",
"2019-05-01T04:01:00Z"
]
}
]
}
```
# Menghapus zona yang di-hosting publik
Bagian ini menjelaskan cara menghapus zona yang di-hosting publik menggunakan konsol Amazon Route 53.
Anda dapat menghapus zona yang di-hosting hanya jika tidak ada catatan selain catatan SOA dan NS default. Jika zona yang di-hosting berisi catatan lain, Anda harus menghapusnya sebelum Anda dapat menghapus zona yang di-hosting. Hal ini mencegah Anda agar tidak menghapus zona yang di-hosting yang masih berisi catatan secara tidak sengaja.
**Topics**
+ [Mencegah lalu lintas agar tidak dirutekan ke domain](#delete-public-hosted-zone-stop-routing)
+ [Menghapus zona yang di-hosting publik yang dibuat oleh layanan lain](#delete-public-hosted-zone-created-by-another-service)
+ [Menggunakan konsol Route 53 untuk menghapus zona yang di-hosting publik](#delete-public-hosted-zone-procedure)
## Mencegah lalu lintas agar tidak dirutekan ke domain
Jika ingin tetap melakukan pendaftaran domain namun ingin menghentikan perutean lalu lintas internet ke situs web atau aplikasi web, sebaiknya hapus *catatan* di zona yang di-hosting alih-alih menghapus zona yang di-hosting.
**penting**
Jika zona yang di-hosting dihapus, Anda tidak dapat membatalkan penghapusannya. Anda harus membuat zona yang di-hosting baru dan memperbarui server nama untuk pendaftaran domain, yang dapat membutuhkan hingga 48 jam untuk diterapkan. Selain itu, jika Anda menghapus zona yang di-hosting, seseorang dapat membajak domain dan merutekan lalu lintas ke sumber daya mereka sendiri menggunakan nama domain Anda.
Jika Anda mendelegasikan tanggung jawab untuk subdomain ke zona yang di-hosting dan ingin menghapus zona yang di-hosting anak, Anda juga harus memperbarui zona yang di-hosting induk dengan menghapus catatan NS dengan nama yang sama sebagai zona yang di-hosting anak. Misalnya, jika ingin menghapus zona yang di-hosting acme.example.com, Anda juga harus menghapus catatan NS acme.example.com dalam zona yang di-hosting example.com. Kami merekomendasikan agar Anda menghapus catatan NS terlebih dahulu, dan menunggu durasi TTL pada catatan NS sebelum Anda menghapus zona yang di-hosting anak. Hal ini memastikan agar orang lain tidak dapat membajak zona yang di-hosting anak selama penyelesai DNS masih memiliki server nama untuk zona yang di-hosting anak yang di-cache.
Jika ingin menghindari biaya bulanan zona yang di-hosting, Anda dapat mentransfer layanan DNS untuk domain ke layanan DNS gratis. Ketika mentransfer layanan DNS, Anda harus memperbarui server nama untuk pendaftaran domain. Jika domain terdaftar dengan Route 53, lihat [Menambahkan atau mengubah server nama dan merekatkan catatan untuk domain](domain-name-servers-glue-records.md) untuk informasi tentang cara mengganti server nama Route 53 dengan server nama untuk layanan DNS baru. Jika domain terdaftar dengan registrar lain, gunakan metode yang disediakan oleh registrar untuk memperbarui server nama bagi pendaftaran domain. Untuk informasi lebih lanjut, lakukan pencarian "layanan DNS gratis" di internet.
## Menghapus zona yang di-hosting publik yang dibuat oleh layanan lain
Jika zona yang di-hosting dibuat oleh layanan lain, Anda tidak dapat menghapusnya menggunakan konsol Route 53. Sebagai gantinya, Anda perlu menggunakan proses yang berlaku untuk layanan lainnya:
+ **AWS Cloud Map**— Untuk menghapus zona yang dihosting yang AWS Cloud Map dibuat saat Anda membuat namespace DNS publik, hapus namespace. AWS Cloud Map menghapus zona yang dihosting secara otomatis. Untuk informasi selengkapnya, lihat [Menghapus namespace](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) di *Panduan Developer AWS Cloud Map *.
+ **Penemuan Layanan Amazon Elastic Container Service (Amazon ECS)** – Untuk menghapus zona yang di-hosting publik yang dibuat Amazon ECS ketika Anda membuat layanan menggunakan penemuan layanan, hapus layanan Amazon ECS yang menggunakan namespace, dan hapus namespace. Untuk informasi lebih lanjut, lihat [Menghapus layanan](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) dalam *Panduan Developer Amazon Elastic Container Service*.
## Menggunakan konsol Route 53 untuk menghapus zona yang di-hosting publik
Untuk menggunakan konsol Route 53 guna menghapus zona yang di-hosting publik, lakukan prosedur berikut.
**Cara menghapus zona yang di-hosting publik menggunakan konsol Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Di panel navigasi, pilih **Zona yang dihosting**, dan pilih tautan yang disorot untuk zona yang dihosting yang ingin Anda hapus.
1. Mengonfirmasi bahwa zona yang di-hosting yang ingin Anda hapus hanya berisi catatan NS dan SOA. Jika berisi catatan tambahan, hapuslah. Anda juga harus menonaktifkan penandatanganan DNSSEC:
**catatan**
Jika Anda mencoba menghapus zona yang dihosting tanpa menyelesaikan persyaratan ini, Route 53 akan menampilkan kesalahan:
Jika penandatanganan DNSSEC diaktifkan: Zona host yang ditentukan berisi Kunci Penandatanganan Kunci DNSSEC sehingga tidak dapat dihapus
Jika kumpulan catatan sumber daya lain ada (selain catatan SOA dan NS default): Zona host yang ditentukan berisi kumpulan catatan sumber daya yang tidak diperlukan sehingga tidak dapat dihapus
1. Pada halaman detail zona yang dihosting, dalam daftar **Catatan**, jika daftar catatan menyertakan catatan apa pun yang nilai kolom **Type** adalah sesuatu selain NS atau SOA, pilih baris, dan pilih **Hapus**.
Untuk memilih beberapa catatan berturut-turut, pilih baris pertama, tekan dan tahan tombol **Shift**, dan pilih baris terakhir. Untuk memilih beberapa catatan tidak berturut-turut, pilih baris pertama, tekan dan tahan tombol **Ctrl**, dan pilih baris yang tersisa.
**catatan**
Jika Anda membuat catatan NS untuk subdomain di zona yang di-hosting, hapus juga catatan tersebut.
1. Kembali ke halaman **Zona yang dihosting**, dan pilih baris untuk zona yang dihosting yang ingin Anda hapus.
1. Pilih **Hapus**.
1. Ketik kunci konfirmasi dan pilih **Hapus**.
1. Jika Anda ingin membuat domain tidak tersedia di internet, kami sarankan Anda mentransfer layanan DNS ke layanan DNS gratis lalu hapus zona yang di-hosting Route 53. Hal ini mencegah kueri DNS agar tidak salah dirutekan di masa mendatang.
Jika domain terdaftar dengan Route 53, lihat [Menambahkan atau mengubah server nama dan merekatkan catatan untuk domain](domain-name-servers-glue-records.md) untuk informasi tentang cara mengganti server nama Route 53 dengan server nama untuk layanan DNS baru. Jika domain yang terdaftar dengan registrar lain, gunakan metode yang disediakan oleh registrar untuk mengubah server nama domain.
**catatan**
Jika menghapus zona yang di-hosting untuk subdomain (acme.example.com), Anda tidak perlu mengubah server nama untuk domain tersebut (example.com).
# Memeriksa respons DNS dari Route 53
Jika membuat zona yang di-hosting Amazon Route 53 untuk domain, Anda dapat menggunakan alat pemeriksa DNS di konsol untuk melihat cara Route 53 merespons kueri DNS jika Anda mengonfigurasi domain untuk menggunakan Route 53 sebagai layanan DNS. Untuk catatan geolokasi, geoproximity, dan latensi, Anda juga dapat mensimulasikan kueri dari alamat IP and/or klien DNS resolver tertentu untuk mengetahui respons apa yang akan dikembalikan Route 53.
**penting**
Alat tidak mengirimkan kueri ke Domain Name System, alat hanya merespons berdasarkan pengaturan dalam catatan di zona yang di-hosting. Alat mengembalikan informasi yang sama terlepas dari apakah zona yang di-hosting saat ini sedang digunakan untuk merutekan lalu lintas untuk domain.
Alat pemeriksa DNS hanya berfungsi untuk zona yang di-hosting publik.
**catatan**
Alat pemeriksaan DNS mengembalikan informasi yang mirip dengan apa yang Anda harapkan dari bagian jawaban `dig` perintah. Oleh karena itu, jika Anda menanyakan server nama subdomain yang mengarah ke server nama induk, itu tidak akan dikembalikan.
**Topics**
+ [Menggunakan alat pemeriksa untuk melihat cara Amazon Route 53 merespons kueri DNS](#dns-test-how-route-53-responds)
+ [Menggunakan alat pemeriksa untuk mensimulasikan kueri dari alamat IP tertentu (hanya catatan geolokasi dan latensi)](#dns-test-simulate-requests)
## Menggunakan alat pemeriksa untuk melihat cara Amazon Route 53 merespons kueri DNS
Anda dapat menggunakan alat untuk melihat respons yang dikembalikan Amazon Route 53 dalam menanggapi kueri DNS untuk catatan.
**Cara menggunakan alat pemeriksa untuk melihat cara Amazon Route 53 merespons kueri DNS**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pada panel navigasi, pilih **Zona yang Di-hosting**.
1. Pada halaman **Zona yang Di-hosting**, pilih nama zona yang di-hosting. Konsol menampilkan daftar catatan untuk zona yang di-hosting tersebut.
1. Untuk langsung membuka halaman **Periksa respons dari Route 53**, pilih **Catatan pengujian**.
1. Tentukan nilai-nilai berikut ini:
+ Nama catatan, tidak termasuk nama zona yang di-hosting. Sebagai contoh, untuk memeriksa **www.example.com**, masukkan **www**. Untuk memeriksa **example.com**, kosongkan bidang **Nama catatan**.
+ Jenis catatan yang ingin Anda periksa, seperti **A** atau **CNAME**.
1. Pilih **Dapatkan Respons**.
1. Bagian **Respons yang dikembalikan oleh Route 53** mencakup nilai-nilai berikut:
**Kode respons DNS**
Kode yang menunjukkan apakah kueri tersebut valid atau tidak. Kode respons yang paling umum adalah **NOERROR**, yang berarti bahwa kueri tersebut valid. Jika respons tidak valid, Route 53 mengembalikan kode respons yang menjelaskan alasannya. Untuk daftar kode respons yang mungkin muncul, lihat [DNS RCODE](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) di situs web IANA.
**Protokol**
Protokol yang digunakan Amazon Route 53 untuk merespons kueri, baik **UDP** atau **TCP**.
**Respons yang dikembalikan oleh Route 53**
Nilai yang akan dikembalikan Route 53 ke aplikasi web. Nilainya adalah salah satu dari berikut ini:
+ Untuk catatan non-alias, respons berisi nilai atau nilai-nilai dalam catatan.
+ Untuk beberapa catatan dengan nama dan jenis yang sama, yang mencakup tertimbang, latensi, geolokasi, dan failover, respons berisi nilai dari catatan yang sesuai, berdasarkan permintaan.
+ Untuk catatan alias yang merujuk ke AWS sumber daya selain catatan lain, respons berisi alamat IP atau nama domain untuk AWS sumber daya, tergantung pada jenis sumber daya.
+ Untuk catatan alias yang merujuk ke catatan lain, respons berisi nilai atau nilai-nilai dari catatan yang dirujuk.
## Menggunakan alat pemeriksa untuk mensimulasikan kueri dari alamat IP tertentu (hanya catatan geolokasi dan latensi)
Jika telah membuat catatan latensi atau geolokasi, Anda dapat menggunakan alat pemeriksa untuk mensimulasikan kueri dari alamat IP untuk penyelesai DNS dan klien.
**Untuk menggunakan alat pemeriksa guna mensimulasikan kueri dari alamat IP yang ditentukan**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pada panel navigasi, pilih **Zona yang Di-hosting**.
1. Pada halaman **Zona yang Di-hosting**, pilih nama zona yang di-hosting. Konsol menampilkan daftar catatan untuk zona yang di-hosting tersebut.
1. Untuk langsung membuka halaman **Periksa respons dari Route 53**, pilih **Set catatan pengujian**.
Untuk membuka halaman **Periksa respons dari Route 53** untuk catatan tertentu, pilih kotak centang untuk catatan tersebut dan pilih **Set catatan pengujian**.
1. Jika Anda memilih **Set catatan pengujian** tanpa memilih catatan terlebih dahulu, tebtukan nilai-nilai berikut:
+ Nama catatan, tidak termasuk nama zona yang di-hosting. Sebagai contoh, untuk memeriksa **www.example.com**, masukkan **www**. Untuk memeriksa **example.com**, kosongkan bidang **Nama catatan**.
+ Jenis catatan yang ingin Anda periksa, seperti **A** atau **CNAME**.
1. Tentukan nilai-nilai yang berlaku:
**Alamat IP penyelesai**
Tentukan IPv6 alamat IPv4 atau untuk mensimulasikan lokasi resolver DNS yang digunakan klien untuk membuat permintaan. Hal ini berguna untuk menguji catatan latensi dan geolokasi. Jika Anda menghilangkan nilai ini, alat ini menggunakan alamat IP dari penyelesai DNS di Wilayah AWS AS Timur (Virginia N.) (us-east-1).
**EDNS0 IP subnet klien**
Jika resolver mendukung EDNS0, masukkan IP subnet klien untuk alamat IP di lokasi geografis yang berlaku, misalnya, **192.0.2.0** atau **2001:db** 8:85 a3: :8a2e: 370:7334.
**Subnet mask**
Jika Anda menentukan alamat IP untuk **IP subnet EDNS0 klien**, Anda dapat secara opsional menentukan jumlah bit alamat IP yang Anda inginkan alat pemeriksaan untuk disertakan dalam kueri DNS. **Misalnya, jika Anda menentukan **192.0.2.44** untuk **IP subnet EDNS0 klien dan **24** untuk Subnet** **mask**, alat pemeriksaan akan mensimulasikan kueri dari 192.0.2.0/24.** Nilai default adalah 24 bit untuk IPv4 alamat dan 64 bit untuk IPv6 alamat.
1. Pilih **Dapatkan Respons**.
1. Bagian **Respons yang dikembalikan oleh Route 53** mencakup nilai-nilai berikut:
**Kueri DNS dikirimkan ke Route 53**
Kueri, dalam [Format BIND](https://en.wikipedia.org/wiki/Zone_file), yang dikirimkan alat pemeriksa ke Route 53. Ini adalah format yang sama seperti yang digunakan aplikasi web untuk mengirim kueri. Tiga nilai biasanya berupa nama catatan, **IN** (untuk internet), dan jenis catatan.
**Kode respons DNS**
Kode yang menunjukkan apakah kueri tersebut valid atau tidak. Kode respons yang paling umum adalah **NOERROR**, yang berarti bahwa kueri tersebut valid. Jika respons tidak valid, Route 53 mengembalikan kode respons yang menjelaskan alasannya. Untuk daftar kode respons yang mungkin muncul, lihat [DNS RCODE](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) di situs web IANA.
**Protokol**
Protokol yang digunakan Amazon Route 53 untuk merespons kueri, baik **UDP** atau **TCP**.
**Respons yang dikembalikan oleh Route 53**
Nilai yang akan dikembalikan Route 53 ke aplikasi web. Nilainya adalah salah satu dari berikut ini:
+ Untuk catatan non-alias, respons berisi nilai atau nilai-nilai dalam catatan.
+ Untuk beberapa catatan dengan nama dan jenis yang sama, yang mencakup tertimbang, latensi, geolokasi, dan failover, respons berisi nilai dari catatan yang sesuai, berdasarkan permintaan.
+ Untuk catatan alias yang merujuk ke AWS sumber daya selain catatan lain, respons berisi alamat IP atau nama domain untuk AWS sumber daya, tergantung pada jenis sumber daya.
+ Untuk catatan alias yang merujuk ke catatan lain, respons berisi nilai atau nilai-nilai dari catatan yang dirujuk.
# Mengonfigurasi server nama label putih
Setiap zona yang di-hosting Amazon Route 53 dikaitkan dengan empat server nama, dikenal secara kolektif sebagai set delegasi. Secara default, server nama memiliki nama seperti ns-2048.awsdns-64.com. Jika Anda ingin nama domain server agar sama dengan nama domain zona yang di-hosting, misalnya ns1.example.com, Anda dapat mengonfigurasi server nama label putih, juga dikenal sebagai server nama vanity atau server nama privat.
Langkah-langkah berikut menjelaskan cara mengonfigurasi satu set server nama label putih sejumlah empat buah yang dapat Anda gunakan kembali untuk beberapa domain. Misalnya, anggap Anda memiliki domain example.com, example.org, dan example.net. Dengan langkah-langkah ini, Anda dapat mengonfigurasi server nama label putih untuk example.com lalu menggunakannya kembali untuk example.org dan example.net.
**Topics**
+ [Langkah 1: Membuat set delegasi Route 53 yang dapat digunakan kembali](#white-label-name-servers-create-reusable-delegation-set)
+ [Langkah 2: Membuat atau membuat ulang zona yang di-hosting Amazon Route 53, dan mengubah TTL untuk catatan NS dan SOA](#white-label-name-servers-create-hosted-zones)
+ [Langkah 3: Membuat ulang catatan untuk zona yang di-hosting](#white-label-name-servers-create-resource-record-sets)
+ [Langkah 4: Mendapatkan alamat IP](#white-label-name-servers-get-ip-addresses)
+ [Langkah 5: Membuat catatan untuk server nama label putih](#white-label-name-servers-create-white-label-resource-record-sets)
+ [Langkah 6: Memperbarui catatan NS dan SOA](#white-label-name-servers-update-ns-soa-records)
+ [Langkah 7: Membuat glue record dan mengubah server nama registrar](#white-label-name-servers-create-glue-records)
+ [Langkah 8: Memantau lalu lintas untuk situs web atau aplikasi](#white-label-name-servers-monitor-traffic)
+ [Langkah 9: Ubah TTLs kembali ke nilai aslinya](#white-label-name-servers-change-ttls-back)
+ [Langkah 10: (Opsional) Menghubungi layanan DNS rekursif](#white-label-name-servers-contact-recursive-dns-services)
## Langkah 1: Membuat set delegasi Route 53 yang dapat digunakan kembali
Server nama label putih dikaitkan dengan set delegasi Route 53 yang dapat digunakan kembali. Anda dapat menggunakan server nama label putih untuk zona yang dihosting hanya jika zona yang dihosting dan kumpulan delegasi yang dapat digunakan kembali dibuat oleh akun yang sama. AWS
Untuk membuat kumpulan delegasi yang dapat digunakan kembali, Anda dapat menggunakan API Route 53, AWS CLI, atau salah satunya. AWS SDKs Untuk informasi selengkapnya, lihat dokumentasi berikut ini:
+ **Route 53 API** - Lihat [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)di *Referensi API Amazon Route 53*
+ **AWS CLI** *- Lihat [create-reusable-delegation-set](https://docs.aws.amazon.com/cli/latest/reference/route53/create-reusable-delegation-set.html)di Referensi Perintah AWS CLI *
+ **AWS SDKs**Lihat dokumentasi SDK yang berlaku di halaman [AWS Dokumentasi](https://docs.aws.amazon.com/)
## Langkah 2: Membuat atau membuat ulang zona yang di-hosting Amazon Route 53, dan mengubah TTL untuk catatan NS dan SOA
Buat atau buat ulang zona yang di-hosting Amazon Route 53:
+ **Jika saat ini Anda tidak menggunakan Route 53 sebagai layanan DNS untuk domain yang ingin menggunakan server nama label putih** – Membuat zona yang di-hosting dan menentukan set delegasi yang dapat digunakan kembali yang Anda buat di langkah sebelumnya dengan setiap zona yang di-hosting. Untuk informasi selengkapnya, lihat [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)di *Referensi API Amazon Route 53*.
+ **Jika saat ini Anda menggunakan Route 53 sebagai layanan DNS untuk domain yang ingin menggunakan server nama label putih** – Anda harus membuat ulang zona yang di-hosting yang ingin menggunakan server nama laber putih, dan menentukan set delegasi yang dapat digunakan kembali yang Anda buat di langkah sebelumnya dengan setiap zona yang di-hosting.
**penting**
Anda tidak dapat mengubah server nama yang terkait dengan zona yang di-hosting yang sudah ada. Anda dapat mengaitkan set delegasi yang dapat digunakan kembali hanya dengan zona yang di-hosting ketika Anda membuat zona yang di-hosting.
Ketika Anda membuat zona yang di-hosting dan sebelum Anda mencoba mengakses sumber daya untuk domain yang sesuai, ubah nilai TTL berikut untuk setiap zona yang di-hosting:
+ Ubah TTL catatan NS untuk zona yang di-hosting ke 60 detik atau kurang.
+ Ubah TTL minimum catatan SOA untuk zona yang di-hosting ke 60 detik atau kurang. Ini adalah nilai terakhir dalam catatan SOA.
Jika Anda secara tidak sengaja memberikan alamat IP yang salah kepada registrar untuk server nama label putih, situs web Anda akan menjadi tidak tersedia dan tetap tidak tersedia selama TTL setelah Anda memperbaiki masalah. Dengan mengatur TTL yang rendah, Anda mengurangi jumlah waktu saat situs web tidak tersedia.
Untuk informasi selengkapnya tentang membuat zona yang dihosting dan menentukan set delegasi yang dapat digunakan kembali untuk server nama untuk zona yang dihosting, lihat [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)di Referensi API *Amazon Route 53*.
## Langkah 3: Membuat ulang catatan untuk zona yang di-hosting
Buat catatan di zona yang di-hosting yang Anda buat di Langkah 2:
+ **Jika Anda memigrasikan layanan DNS untuk domain Anda ke Amazon Route 53** — Anda mungkin dapat membuat catatan dengan mengimpor informasi tentang catatan yang ada. Untuk informasi selengkapnya, lihat [Membuat catatan dengan mengimpor file zona](resource-record-sets-creating-import.md).
+ **Jika Anda mengganti zona yang di-hosting yang ada sehingga Anda dapat menggunakan server nama label putih** – Di zona yang di-hosting baru, buat ulang catatan yang muncul di zona yang di-hosting saat ini. Route 53 tidak menyediakan metode mengekspor catatan dari zona yang di-hosting, tetapi beberapa vendor pihak ketiga yang menyediakannya. Anda kemudian dapat menggunakan fitur impor Route 53 untuk mengimpor catatan non-alias dengan kebijakan perutean yang sederhana. Tidak ada cara untuk mengekspor dan mengimpor ulang catatan alias atau catatan dengan kebijakan perutean yang tidak sederhana.
Untuk informasi tentang membuat rekaman menggunakan API Route 53, lihat [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)di *Referensi API Amazon Route 53*. Untuk informasi tentang membuat catatan menggunakan konsol Route 53, lihat [Bekerja dengan catatan](rrsets-working-with.md).
## Langkah 4: Mendapatkan alamat IP
Dapatkan IPv4 dan IPv6 alamat server nama dalam set delegasi yang dapat digunakan kembali, dan isi tabel berikut.
****
| Nama server nama di set delegasi yang dapat digunakan kembali (contoh: Ns-2048.awsdns-64.com) | IPv4 dan IPv6 alamat | Nama yang ingin Anda tetapkan ke server nama label putih (contoh: ns1.example.com) |
| --- | --- | --- |
| | IPv4: IPv6: | |
| | IPv4: IPv6: | |
| | IPv4: IPv6: | |
| | IPv4: IPv6: | |
Sebagai contoh, misalkan empat server nama untuk set delegasi yang dapat digunakan kembali adalah:
+ ns-2048.awsdns-64.com
+ ns-2049.awsdns-65.net
+ ns-2050.awsdns-66.org
+ ns-2051.awsdns-67.co.uk
Berikut adalah perintah Linux dan Windows yang akan Anda jalankan guna mendapatkan alamat IP yang pertama dari empat server nama:
**perintah dig untuk Linux**
```
% dig A ns-2048.awsdns-64.com +short
192.0.2.117
```
```
% dig AAAA ns-2048.awsdns-64.com +short
2001:db8:85a3::8a2e:370:7334
```
**perintah nslookup untuk Windows**
```
c:\> nslookup ns-2048.awsdns-64.com
Non-authoritative answer:
Name: ns-2048.awsdns-64.com
Addresses: 2001:db8:85a3::8a2e:370:7334
192.0.2.117
```
## Langkah 5: Membuat catatan untuk server nama label putih
Di zona yang di-hosting dengan nama yang sama (seperti example.com) seperti nama domain server nama label putih (seperti ns1.example.com), buat delapan catatan:
+ Satu catatan A untuk setiap server nama label putih
+ Satu catatan AAAA untuk setiap server nama label putih
**penting**
Jika Anda menggunakan server nama label putih yang sama untuk dua atau lebih zona yang di-hosting, jangan lakukan langkah ini untuk zona yang di-hosting lainnya.
Untuk setiap catatan, tentukan nilai berikut. Lihat tabel yang Anda isi untuk langkah sebelumnya:
**Kebijakan perutean**
Tentukan **Perutean sederhana**.
**Nama catatan**
Nama yang ingin Anda tetapkan ke salah satu server nama label putih, misalnya ns1.example.com. Untuk prefiks (ns1 dalam contoh ini), Anda dapat menggunakan nilai yang valid dalam nama domain.
**Nilai/Rutekan lalu lintas ke**
IPv6 Alamat IPv4 atau salah satu server nama Route 53 di set delegasi yang dapat digunakan kembali.
Jika Anda menentukan alamat IP yang salah ketika membuat catatan untuk server nama label putih, situs web atau aplikasi web akan menjadi tidak tersedia di internet ketika Anda melakukan langkah-langkah berikutnya. Bahkan jika Anda segera memperbaiki alamat IP, situs web atau aplikasi web akan tetap tidak tersedia selama durasi TTL.
**Tipe catatan**
Tentukan **A** saat Anda membuat catatan untuk IPv4 alamat.
Tentukan **AAAA** saat Anda membuat catatan untuk alamat. IPv6
**TTL (detik)**
Nilai ini adalah jumlah waktu yang digunakan penyelesai DNS untuk meng-cache informasi dalam catatan ini sebelum meneruskan kueri DNS lain ke Route 53. Kami sarankan Anda menentukan nilai awal 60 detik atau kurang, sehingga Anda dapat memulihkan dengan cepat jika Anda secara tidak sengaja menentukan nilai yang salah dalam catatan ini.
## Langkah 6: Memperbarui catatan NS dan SOA
Perbarui catatan SOA dan NS di zona yang di-hosting yang ingin menggunakan server nama label putih. Lakukan Langkah 6 hingga Langkah 8 untuk satu zona yang di-hosting dan domain yang sesuai secara bersamaan, lalu ulangi untuk zona yang di-hosting dan domain lainnya.
**penting**
Mulai dengan zona yang di-hosting Amazon Route 53 dengan nama domain yang sama (seperti example.com) seperti server nama label putih (seperti ns1.example.com).
1. Memperbarui catatan SOA dengan mengganti nama server nama Route 53 dengan nama salah satu server nama label putih
**Contoh**
Mengganti nama server nama Route 53:
`ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 60`
dengan nama salah satu server nama label putih Anda:
`ns1.example.com. hostmaster.example.com. 1 7200 900 1209600 60`
**catatan**
Anda mengubah nilai terakhir, waktu untuk tayang (TTL), di [Langkah 2: Membuat atau membuat ulang zona yang di-hosting Amazon Route 53, dan mengubah TTL untuk catatan NS dan SOA](#white-label-name-servers-create-hosted-zones).
Untuk informasi tentang memperbarui catatan menggunakan konsol Route 53, lihat [Mengedit catatan](resource-record-sets-editing.md).
1. Dalam catatan NS, catat nama server nama untuk domain saat ini, sehingga Anda dapat kembali ke server nama ini jika diperlukan.
1. Perbarui catatan NS. Ganti nama server nama Route 53 dengan nama keempat server nama empat label putih Anda, misalnya, `ns1.example.com`, `ns2.example.com`, `ns3.example.com`, dan `ns4.example.com`.
## Langkah 7: Membuat glue record dan mengubah server nama registrar
Gunakan metode yang disediakan oleh registrar untuk membuat glue record dan ubah server nama registrar:
1. Menambahkan glue record:
+ **Jika Anda memperbarui domain dengan nama domain yang sama seperti server nama label putih** – Buat empat glue record dengan nama dan alamat IP yang sesuai dengan nilai yang Anda dapatkan di langkah 4. Sertakan alamat IPv4 dan IPv6 alamat untuk server nama label putih dalam catatan lem yang sesuai, misalnya:
**ns1.example.com** – alamat IP = 192.0.2.117 dan 2001:db8:85a3::8a2e:370:7334
Registrar menggunakan berbagai terminologi untuk glue record. Anda mungkin juga melihat ini disebut sebagai mendaftarkan server nama baru atau yang serupa.
+ **Jika Anda memperbarui domain lain** — Jika Route 53 adalah layanan DNS Anda, Anda harus terlebih dahulu menyelesaikan langkah di bullet sebelumnya dan membuat catatan lem yang cocok dengan nama domain. Kemudian lewati ke langkah 2 dalam prosedur ini.
1. Ubah server nama untuk domain ke nama server nama label putih Anda.
Jika Anda menggunakan Amazon Route 53 sebagai layanan DNS, lihat [Menambahkan atau mengubah server nama dan merekatkan catatan untuk domain](domain-name-servers-glue-records.md).
## Langkah 8: Memantau lalu lintas untuk situs web atau aplikasi
Pantau lalu lintas untuk situs web atau aplikasi dengan glue record yang Anda buat dan ubah server nama di Langkah 7:
+ **Jika lalu lintas berhenti** – Gunakan metode yang disediakan oleh registrar guna mengembalikan server nama untuk domain ke server nama Route 53 sebelumnya. Ini adalah server nama yang Anda catat di langkah 6b. Kemudian tentukan apa yang salah.
+ **Jika lalu lintas tidak terpengaruh** – Ulangi Langkah 6 hingga Langkah 8 untuk zona yang di-hosting yang tersisa dan ingin menggunakan server nama label putih yang sama.
## Langkah 9: Ubah TTLs kembali ke nilai aslinya
Untuk semua zona yang di-hosting yang saat ini menggunakan server nama label putih, ubah nilai berikut:
+ Ubah TTL catatan NS untuk zona yang di-hosting menjadi nilai yang lebih khas bagi catatan NS, misalnya 172.800 detik (dua hari).
+ Ubah TTL minimum catatan SOA untuk zona yang di-hosting menjadi nilai yang lebih khas bagi catatan SOA, misalnya 900 detik. Ini adalah nilai terakhir dalam catatan SOA.
## Langkah 10: (Opsional) Menghubungi layanan DNS rekursif
*Opsional* Jika Anda menggunakan perutean geolokasi Amazon Route 53, hubungi layanan DNS rekursif yang mendukung edns-client-subnet ekstensi EDNS0, dan beri mereka nama server nama label putih Anda. Hal ini memastikan bahwa layanan DNS akan terus merutekan kueri DNS ke lokasi Route 53 yang optimal berdasarkan perkiraan lokasi geografis tempat kueri berasal.
# Catatan NS dan SOA yang dibuat Amazon Route 53 untuk zona yang di-hosting publik
Untuk setiap zona yang di-hosting publik yang Anda buat, Amazon Route 53 secara otomatis membuat catatan server nama (NS) dan catatan start of authority (SOA) untuk zona. Catatan ini tidak perlu sering diubah.
**Topics**
+ [Catatan server nama (NS)](#NSrecords)
+ [Catatan start of authority (SOA)](#SOArecords)
## Catatan server nama (NS)
Amazon Route 53 secara otomatis membuat catatan server nama (NS) yang memiliki nama yang sama seperti zona yang di-hosting. Catatan ini mencantumkan empat server nama yang merupakan server nama otoritatif untuk zona yang di-hosting. Kecuali dalam situasi yang jarang terjadi, kami menyarankan agar Anda tidak menambahkan, mengubah, atau menghapus server nama dalam catatan ini.
Contoh berikut menampilkan format untuk nama server nama Route 53 (ini hanya contoh; jangan menggunakannya saat Anda memperbarui catatan server nama registrar):
+ *ns-2048.awsdns-64.com*
+ *ns-2049.awsdns-65.net*
+ *ns-2050.awsdns-66.org*
+ *ns-2051.awsdns-67.co.uk*
Untuk mendapatkan daftar server nama bagi zona yang di-hosting:
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Dalam panel navigasi, klik **Zona yang di-hosting**.
1. Pada halaman **Zona yang di-hosting**, pilih tombol radio (bukan nama) untuk zona yang di-hosting, lalu pilih **Lihat detail**.
1. Pada halaman detail untuk zona yang di-hosting, pilih **Detail zona yang di-hosting**.
1. Catat empat server yang tercantum untuk **Server nama**.
Untuk informasi tentang memigrasi layanan DNS dari penyedia layanan DNS lain ke Route 53, lihat [Membuat Amazon Route 53 menjadi layanan DNS untuk domain yang adaMembuat Route 53 menjadi layanan DNS untuk domain yang ada](MigratingDNS.md).
## Catatan start of authority (SOA)
Catatan start of authority (SOA) mengidentifikasi informasi DNS dasar tentang domain, misalnya:
```
1. ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 86400
```
Catatan SOA mencakup elemen berikut:
+ Server nama Route 53 yang membuat catatan SOA, misalnya, `ns-2048.awsdns-64.net`.
+ Alamat email administrator. Simbol `@` diganti dengan tanda titik, misalnya, `hostmaster.example.com`. Nilai default adalah alamat email amazon.com yang tidak dipantau.
+ Nomor seri yang secara opsional sapat Anda tambahkan setiap kali Anda memperbarui catatan di zona yang di-hosting. Route 53 tidak menambahkan nomor secara otomatis. (Nomor seri digunakan oleh layanan DNS yang mendukung DNS sekunder.) Dalam contoh ini, nilainya adalah `1`.
+ Waktu penyegaran dalam hitungan detik yang merupakan waktu tunggu server DNS sekunder sebelum mengkueri catatan SOA server DNS primer untuk memeriksa perubahan. Dalam contoh ini, nilainya adalah `7200`.
+ Interval percobaan ulang dalam hitungan detik yang merupakan waktu tunggu server sekunder sebelum mencoba kembali transfer zona yang gagal. Biasanya, waktu percobaan ulang kurang dari waktu penyegaran. Dalam contoh ini, nilainya adalah `900` (15 menit).
+ Waktu dalam hitungan detik yang digunakan server sekunder untuk terus mencoba menyelesaikan transfer zona. Jika waktu ini berakhir sebelum transfer zona berhasil, server sekunder akan berhenti menjawab kueri karena menganggap data terlalu tua untuk dapat diandalkan. Dalam contoh ini, nilainya adalah `1209600` (dua minggu).
+ Waktu untuk tayang (TTL) minimum. Nilai ini membantu menentukan durasi waktu yang harus di-cache penyelesai rekursif terkait respons dari Route 53:
**NXDOMAIN**
Tidak ada catatan dari jenis dengan nama yang ditentukan dalam kueri DNS, seperti example.com. Juga tidak ada catatan yang merupakan anak dari nama yang ditentukan dalam kueri DNS, seperti zenith.example.com.
**NODATA**
Ada setidaknya satu catatan dengan nama yang ditentukan dalam kueri DNS, tetapi tidak satu pun dari catatan memiliki jenis (seperti A) yang ditentukan dalam kueri DNS.
Ketika penyelesai DNS meng-cache respons NXDOMAIN atau NODATA respon, ini disebut sebagai *caching negatif*.
Durasi caching negatif lebih rendah dari nilai-nilai berikut:
+ Nilai ini—TTL minimum dalam catatan SOA. Dalam contoh, nilainya adalah `86400` (satu hari).
+ Nilai TTL untuk catatan SOA. Nilai default adalah 900 detik. Untuk informasi tentang perubahan nilai ini, lihat [Mengedit catatan](resource-record-sets-editing.md).
Ketika Route 53 merespons kueri DNS dengan respons NXDOMAIN atau NODATA (respons negatif), Anda dikenakan tarif untuk kueri standar. (Lihat "Kueri" di [Harga Amazon Route 53](https://aws.amazon.com/route53/pricing/). Jika Anda khawatir tentang biaya respons negatif, opsinya adalah mengubah TTL untuk catatan SOA, TTL minimum dalam catatan SOA (nilai ini), atau keduanya. Perhatikan bahwa meningkatkan ini TTLs, yang berlaku untuk respons negatif untuk seluruh zona yang dihosting, dapat memiliki efek positif dan negatif:
+ Penyelesai DNS di internet meng-cache non-eksistensi catatan untuk jangka waktu yang lebih lama, mengurangi jumlah kueri yang diteruskan ke Route 53. Tindakan ini mengurangi biaya Route 53 untuk kueri DNS.
+ Namun, jika Anda pernah keliru menghapus data yang valid dan kemudian membuat ulang data tersebut, penyelesai DNS akan meng-cache respons negatif (catatan ini tidak ada) untuk jangka waktu yang lebih lama. Ini memperpanjang jumlah waktu bagi pelanggan atau pengguna Anda tidak dapat mencapai sumber daya yang sesuai, seperti server web untuk acme.example.com.
**Untuk menemukan catatan SOA Anda di Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pada panel navigasi, pilih **Zona yang di-hosting**.
1. Pilih nama yang ditautkan dari domain yang ingin Anda lihat catatannya.
1. Pada bagian **Catatan** Anda dapat melihat semua catatan yang terdaftar dan Anda juga dapat memfilter catatan untuk menemukan nilai SOA Anda.
# Mengaktifkan pemulihan yang dipercepat untuk mengelola catatan DNS publik
Route 53 percepatan pemulihan untuk mengelola catatan DNS publik dirancang untuk mencapai 60 menit Recovery Time Objective (RTO) dalam hal tidak tersedianya layanan di Wilayah AS Timur (Virginia N.). Saat diaktifkan di zona yang dihosting publik Route 53, Anda akan dapat melanjutkan perubahan pada catatan DNS di zona yang dihosting publik dalam waktu sekitar 60 menit setelah AWS mendeteksi bahwa operasi di Wilayah AS Timur (Virginia N.) terganggu.
**penting**
Pemulihan yang dipercepat hanya tersedia untuk zona yang dihosting publik. Zona yang dihosting pribadi tidak didukung.
**catatan**
Resolusi kueri DNS dari bidang data Route 53 terus bekerja secara normal selama gangguan layanan Regional. Lihat [Ketahanan di Rute 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/disaster-recovery-resiliency.html) untuk pemahaman tentang bidang data versus operasi pesawat kontrol.
**Topics**
+ [Bagaimana pemulihan yang dipercepat untuk catatan DNS publik bekerja](#accelerated-recovery-how-it-works)
+ [Mengirimkan kembali perubahan DNS setelah failover](#accelerated-recovery-resubmit)
+ [Kegagalan Kembali ke Wilayah AS Timur (Virginia N.)](#accelerated-recovery-failback)
+ [Pertimbangan tambahan](#accelerated-recovery-considerations)
+ [Cara mengaktifkan pemulihan yang dipercepat untuk mengelola catatan DNS publik](#accelerated-recovery-enable)
## Bagaimana pemulihan yang dipercepat untuk catatan DNS publik bekerja
Saat pemulihan yang dipercepat diaktifkan, Route 53 akan menyimpan salinan zona host publik Anda di Wilayah Barat AS (Oregon). Jika layanan di Wilayah AS Timur (Virginia Utara) tidak tersedia untuk waktu yang lama, Route 53 akan mengeksekusi failover dalam waktu 60 menit, secara otomatis mengalihkan operasi pesawat kontrol untuk zona host publik yang diaktifkan pemulihan yang dipercepat ke Wilayah AS Barat (Oregon). Anda kemudian dapat terus membuat perubahan DNS secara terprogram melalui CLI, SDK, dan API. Perhatikan bahwa sekumpulan metode API terbatas akan tersedia selama failover. Lihat bagian “Pertimbangan tambahan” untuk detail selengkapnya. Ketika wilayah pulih, Route 53 akan menjalankan prosedur failback, secara otomatis mengarahkan operasi pesawat kontrol kembali ke Wilayah AS Timur (Virginia N.).
**catatan**
Sebelum terjadi kerusakan pada Wilayah AS Timur (Virginia N.), Anda harus terlebih dahulu mengaktifkan pemulihan yang dipercepat untuk mengelola catatan DNS publik di zona host publik Anda. Ini dapat dilakukan melalui Konsol, CLI, SDK, atau API (lihat bagian berjudul *Cara mengaktifkan pemulihan yang dipercepat untuk mengelola catatan DNS publik* pada halaman di bawah ini). Anda tidak dapat mengaktifkan pemulihan yang dipercepat untuk mengelola catatan DNS publik setelah terjadi failover.
## Mengirimkan kembali perubahan DNS setelah failover
Dalam kondisi normal, perubahan pada zona yang dihosting publik dengan pemulihan yang dipercepat diaktifkan akan diterima oleh Wilayah AS Timur (Virginia N.) dan kemudian akan berhasil direplikasi ke Wilayah Barat AS (Oregon). Namun, ketika gangguan layanan terjadi di Wilayah AS Timur (Virginia N.), beberapa perubahan dapat diterima oleh Wilayah AS Timur (Virginia N.), tetapi mungkin tidak direplikasi ke Wilayah Barat AS (Oregon). Perubahan dalam penerbangan ini disebut sebagai “perubahan terdampar”. Setelah failover selesai, Route 53 merekomendasikan agar Anda mengirimkan ulang perubahan yang terdampar sebelum melanjutkan alur kerja DNS Anda. Anda dapat mencapai ini baik dengan menggunakan API, atau dengan menggunakan AWS CloudFormation, yang dijelaskan di bawah ini.
### Menggunakan API untuk melacak dan mengirimkan perubahan DNS
Jika Anda menggunakan API Route 53, AWS CLI, atau AWS SDKs untuk mengelola catatan DNS, maka Anda harus menggunakan [ChangeResourceRecordSets API dan [GetChange API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) untuk masing-masing mengirimkan dan melacak perubahan DNS.
Saat Anda menggunakan ChangeResourceRecordSets API untuk membuat perubahan DNS, Route 53 menampilkan pengenal (ID) untuk perubahan yang Anda buat (lihat [ChangeInfo](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeInfo.html)detail objek respons perubahan). Anda dapat memberikan ID ini dalam permintaan berikutnya GetChange ke API dan mengamati status perubahan. Perubahan DNS dengan status INSYNC telah direplikasi ke Wilayah AS Barat (Oregon) dan disebarkan ke semua server DNS Route 53. Tidak ada tindakan lebih lanjut yang perlu Anda lakukan pada perubahan ini sebelum atau setelah failover. Namun, selama penurunan nilai ke Wilayah AS Timur (Virginia N.), GetChange dapat kembali PENDING, menunjukkan perubahan Anda mungkin tidak direplikasi ke Wilayah AS Barat (Oregon). Jika itu masalahnya, ketika failover selesai, GetChange akan kembali NoSuchChange, menunjukkan bahwa Route 53 tidak dapat mereplikasi perubahan DNS ini. Oleh karena itu, setelah failover Anda dapat dengan aman mengabaikan perubahan DNS yang terdampar ini dan mengirimkannya kembali sebagai perubahan DNS baru. Anda akan tahu proses failover telah selesai ketika Route 53 memposting pesan ke Dasbor AWS Kesehatan.
### Menggunakan AWS CloudFormation untuk melacak dan mengirimkan perubahan
AWS CloudFormation secara otomatis melacak status replikasi untuk perubahan DNS Anda menggunakan GetChange API, dan hanya menyelesaikan pembaruan setelah perubahan DNS dikonfirmasi sebagai INSYNC. Jika Anda menggunakan CloudFormation untuk mengelola catatan DNS dan Wilayah AS Timur (Virginia N.) menjadi tidak tersedia, maka tindakan yang Anda lakukan tidak CloudFormation akan berhasil diselesaikan selama periode tidak tersedianya. Namun, Anda cukup mencoba lagi tindakan yang sama CloudFormation untuk memungkinkan pengiriman ulang perubahan DNS, setelah proses failover Route 53 selesai.
## Kegagalan Kembali ke Wilayah AS Timur (Virginia N.)
Route 53 akan gagal mengendalikan kembali operasi pesawat untuk zona host publik Anda ke Wilayah AS Timur (Virginia N.) setelah wilayah tersebut pulih. Selama failback, Anda tidak perlu mengirimkan ulang perubahan DNS Anda, karena tidak ada perubahan terdampar yang akan diperkenalkan selama proses ini.
## Pertimbangan tambahan
Ada beberapa pertimbangan tambahan yang harus diperhatikan terkait dengan fitur pemulihan yang dipercepat:
1. Anda tidak akan dapat membuat zona host baru, menghapus zona host yang ada, mengaktifkan penandatanganan DNSSEC, atau menonaktifkan penandatanganan DNSSEC selama failover.
1. AWS PrivateLink koneksi tidak akan berfungsi setelah failover, tetapi akan berfungsi sekali lagi setelah gagal kembali ke Wilayah AS Timur (Virginia N.).
1. [CloudFront Paket flat-rate](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html) tidak didukung saat ini.
1. Zona yang dihosting dengan pemulihan yang dipercepat diaktifkan tidak dapat dihapus. Anda harus menonaktifkan pemulihan yang dipercepat sebelum mencoba menghapus zona yang dihosting.
1. Selama failover, metode API berikut akan terus didukung untuk zona yang dihosting publik dengan pemulihan yang dipercepat diaktifkan. Namun, semua metode API Route 53 lainnya tidak akan berfungsi sampai kegagalan terjadi.
+ `ChangeResourceRecordSets`
+ `GetChange`
+ `GetGeoLocation`
+ `GetHostedZone`
+ `GetHostedZoneCount`
+ `GetHostedZoneLimit`
+ `GetReusableDelegationSet`
+ `GetReusableDelegationSetLimit`
+ `ListGeoLocations`
+ `ListHostedZones`
+ `ListHostedZonesByName`
+ `ListResourceRecordSets`
+ `ListReusableDelegationSets`
## Cara mengaktifkan pemulihan yang dipercepat untuk mengelola catatan DNS publik
Anda dapat mengaktifkan pemulihan yang dipercepat untuk mengelola catatan DNS publik menggunakan konsol Route 53, API, CLI, atau SDK. Waktu yang diperlukan untuk mengaktifkan pemulihan yang dipercepat akan tergantung pada ukuran zona host publik Anda dan faktor lainnya. Anda harus merencanakan proses memungkinkan pemulihan yang dipercepat memakan waktu hingga beberapa jam. Anda dapat memeriksa status proses pemberdayaan di tab Pemulihan yang dipercepat di zona host publik Anda atau melalui `GetHostedZone` API. Saat proses selesai, akan ada periode waktu singkat yang berlangsung hingga beberapa menit di mana perubahan DNS tidak diterima. Setelah selesai, perubahan DNS dapat berjalan seperti biasa.
**Untuk mengaktifkan dan menonaktifkan pemulihan yang dipercepat menggunakan konsol Route 53**
1. Buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pada panel navigasi, pilih **Zona yang di-hosting**.
1. Pilih zona yang dihosting publik yang ingin Anda aktifkan pemulihan yang dipercepat.
1. Di tab **Accelerated Recovery**, pilih **Aktifkan**.
1. Pilih **Simpan perubahan**.
1. Pantau status zona yang dihosting. Status menunjukkan **Mengaktifkan pemulihan yang dipercepat** selama penyiapan dan perubahan ke **Diaktifkan** saat selesai.
Anda dapat menonaktifkan pemulihan yang dipercepat menggunakan langkah-langkah yang sama di atas, tetapi memilih **Nonaktifkan**.
Contoh CLI untuk mengaktifkan
```
aws route53 update-hosted-zone-features --enable-accelerated-recovery --hosted-zone-id Z123456789
```
Contoh CLI untuk menonaktifkan
```
aws route53 update-hosted-zone-features --no-enable-accelerated-recovery --hosted-zone-id Z123456789
```
# Bekerja dengan zona yang di-hosting privat
*Zona yang dihosting pribadi* adalah wadah yang menyimpan informasi tentang bagaimana Anda ingin Amazon Route 53 menanggapi kueri DNS untuk domain dan subdomainnya dalam satu atau lebih VPCs yang Anda buat dengan layanan Amazon VPC. Berikut adalah cara kerja zona yang di-hosting privat:
1. Anda membuat zona host pribadi, seperti example.com, dan menentukan VPC yang ingin Anda kaitkan dengan zona yang dihosting. Setelah Anda membuat zona yang dihosting, Anda dapat mengasosiasikan lebih banyak VPCs dengannya.
1. Anda membuat catatan di zona yang di-hosting yang menentukan cara Route 53 merespons kueri DNS untuk domain serta subdomain dalam dan di antara VPC Anda. Misalnya, Anda memiliki server database yang berjalan pada instans EC2 di VPC yang Anda kaitkan dengan zona host pribadi Anda. Anda membuat catatan A atau AAAA, seperti db.example.com, dan Anda menentukan alamat IP server basis data.
Untuk informasi lebih lanjut tentang catatan, lihat [Bekerja dengan catatan](rrsets-working-with.md). Untuk informasi tentang persyaratan Amazon VPC untuk menggunakan zona yang di-hosting privat, lihat [Menggunakan zona yang di-hosting privat](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones) dalam *Panduan Pengguna Amazon VPC*.
1. Ketika aplikasi mengirim kueri DNS untuk db.example.com, Route 53 mengembalikan alamat IP yang sesuai. Untuk mendapatkan jawaban dari zona host pribadi, Anda juga harus menjalankan instans EC2 di salah satu yang terkait VPCs (atau memiliki titik akhir masuk dari pengaturan hibrida.) Jika Anda mencoba menanyakan zona host pribadi dari luar VPCs atau pengaturan hybrid Anda, kueri akan diselesaikan secara rekursif di internet.
1. Aplikasi ini menggunakan alamat IP yang didapat dari Route 53 untuk membuat koneksi dengan server basis data.
Saat Anda membuat zona host pribadi, server nama berikut akan digunakan:
+ ns-0.awsdns-00.com
+ ns-512.awsdns-00.net
+ ns-1024.awsdns-00.org
+ ns-1536.awsdns-00.co.uk
Server nama ini digunakan karena protokol DNS mengharuskan setiap zona yang dihosting harus memiliki kumpulan catatan NS. Server nama ini dicadangkan dan tidak pernah digunakan oleh zona yang dihosting publik Route 53. Anda hanya dapat menanyakan zona tersebut melalui Resolver VPC di VPC yang telah dikaitkan dengan zona yang dihosting dengan menggunakan titik akhir masuk yang terhubung ke zona host pribadi yang ditentukan. VPCs
Sementara server nama terlihat di internet, VPC Resolver tidak terhubung ke alamat server nama. Selanjutnya, informasi zona yang dihosting pribadi tidak dikembalikan jika Anda langsung menanyakan server nama melalui internet. Sebagai gantinya, VPC Resolver mendeteksi bahwa kueri berada dalam namespace pribadi berdasarkan VPC ke asosiasi zona yang dihosting dan menggunakan konektivitas pribadi langsung untuk menjangkau server DNS pribadi.
**catatan**
Anda dapat mengubah catatan NS yang ditetapkan di zona host pribadi jika Anda mau dan resolusi DNS pribadi akan tetap berfungsi. Kami tidak menyarankan melakukannya, tetapi jika Anda memilih untuk melakukannya, Anda harus menggunakan nama domain cadangan yang tidak digunakan oleh server DNS publik.
Jika ingin merutekan lalu lintas untuk domain di internet, Anda menggunakan zona yang di-hosting *publik* Route 53. Untuk informasi selengkapnya, lihat [Bekerja dengan zona yang di-hosting publik](AboutHZWorkingWith.md).
**Topics**
+ [Pertimbangan saat bekerja dengan zona yang di-hosting privat](hosted-zone-private-considerations.md)
+ [Membuat zona yang di-hosting privat](hosted-zone-private-creating.md)
+ [Mencantumkan zona yang di-hosting privat](hosted-zone-private-listing.md)
+ [Mengaitkan lebih banyak VPCs dengan zona yang dihosting pribadi](hosted-zone-private-associate-vpcs.md)
+ [Mengaitkan VPC Amazon dan zona host pribadi yang Anda buat dengan akun berbeda AWS](hosted-zone-private-associate-vpcs-different-accounts.md)
+ [Memutuskan hubungan VPCs dari zona yang dihosting pribadi](hosted-zone-private-disassociate-vpcs.md)
+ [Menghapus zona yang di-hosting privat](hosted-zone-private-deleting.md)
+ [Izin VPC](hosted-zone-private-vpc-permissions.md)
# Pertimbangan saat bekerja dengan zona yang di-hosting privat
Saat menggunakan zona yang di-hosting privat, perhatikan pertimbangan berikut.
+ [Amazon VPC settings](#hosted-zone-private-considerations-vpc-settings)
+ [Route 53 health checks](#hosted-zone-private-considerations-health-checks)
+ [Supported routing policies for records in a private hosted zone](#hosted-zone-private-considerations-routing-policies)
+ [Split-view DNS](#hosted-zone-private-considerations-split-view-dns)
+ [Public and private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-public-private-overlapping)
+ [Private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-private-overlapping)
+ [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules)
+ [Delegating responsibility for a subdomain](#hosted-zone-private-considerations-delegating-subdomain)
+ [Custom DNS servers](#hosted-zone-private-considerations-custom-dns)
+ [Required IAM permissions](#hosted-zone-private-considerations-required-permissions)
**Pengaturan Amazon VPC**
Untuk menggunakan zona yang di-hosting privat, Anda harus mengatur pengaturan Amazon VPC berikut ke `true`:
+ `enableDnsHostnames`
+ `enableDnsSupport`
Untuk informasi selengkapnya, lihat [Melihat dan memperbarui atribut DNS untuk VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns-updating.html) di Panduan Pengguna *Amazon VPC*.
**Pemeriksaan kondisi Route 53**
Di zona host pribadi, Anda dapat mengaitkan pemeriksaan kesehatan Route 53 hanya dengan catatan failover, jawaban multivalue, tertimbang, latensi, geolokasi, dan catatan geoproximity. Untuk informasi tentang mengaitkan pemeriksaan kondisi dengan catatan failover, lihat [Mengonfigurasi failover di zona yang di-hosting secara privat](dns-failover-private-hosted-zones.md).
**Kebijakan perutean yang didukung untuk catatan di zona yang di-hosting privat**
Anda dapat menggunakan kebijakan perutean berikut ketika membuat catatan di zona yang di-hosting privat:
+ [Perutean sederhana](routing-policy-simple.md)
+ [Perutean failover](routing-policy-failover.md)
+ [Perutean jawaban multinilai](routing-policy-multivalue.md)
+ [Perutean tertimbang](routing-policy-weighted.md)
+ [Perutean berbasis latensi](routing-policy-latency.md)
+ [Perutean geolokasi](routing-policy-geo.md)
+ [Perutean geoproksimitas](routing-policy-geoproximity.md)
Membuat catatan di zona yang di-hosting privat menggunakan kebijakan perutean lainnya tidak didukung.
**DNS split-view**
Anda dapat menggunakan Route 53 untuk mengonfigurasi DNS split-view, juga dikenal sebagai DNS split-horizon. Di DNS split-view, Anda menggunakan nama domain yang sama (example.com) untuk penggunaan internal (accounting.example.com) dan penggunaan eksternal, seperti situs web publik (www.example.com). Anda mungkin juga ingin menggunakan nama subdomain yang sama secara internal dan eksternal, tetapi melayani konten yang berbeda atau memerlukan autentikasi yang berbeda untuk pengguna internal dan eksternal.
Untuk mengonfigurasi DNS split-view, lakukan langkah-langkah berikut:
1. Membuat zona yang di-hosting publik dan privat yang memiliki nama yang sama. (DNS split-view masih berfungsi jika Anda menggunakan layanan DNS lain untuk zona yang di-hosting publik.)
1. Kaitkan satu atau lebih Amazon VPCs dengan zona host pribadi. Route 53 VPC Resolver menggunakan zona host pribadi untuk merutekan kueri DNS dalam yang ditentukan. VPCs
1. Membuat catatan di setiap zona yang di-hosting. Catatan di zona yang dihosting publik mengontrol cara lalu lintas internet dirutekan, dan catatan di zona host pribadi mengontrol cara lalu lintas dirutekan di Amazon Anda. VPCs
Jika Anda perlu melakukan resolusi nama untuk VPC dan beban kerja lokal, Anda dapat menggunakan Route 53 VPC Resolver. Untuk informasi selengkapnya, lihat [Apa itu Route 53 VPC Resolver?](resolver.md).
**Zona yang di-hosting publik dan privat dengan namespace yang tumpang tindih**
Jika Anda memiliki zona host pribadi dan publik yang memiliki ruang nama yang tumpang tindih, seperti example.com dan accounting.example.com, VPC Resolver merutekan lalu lintas berdasarkan kecocokan paling spesifik. Saat pengguna masuk ke instans EC2 di VPC Amazon yang telah Anda kaitkan dengan zona host pribadi, inilah cara Route 53 VPC Resolver menangani kueri DNS:
1. VPC Resolver mengevaluasi apakah nama zona host pribadi cocok dengan nama domain dalam permintaan, seperti accounting.example.com. Kecocokan ditentukan sebagai berikut:
+ Kecocokan identik
+ Nama zona yang di-hosting privat adalah induk dari nama domain dalam permintaan. Misalnya, nama domain dalam permintaan adalah sebagai berikut:
**seattle.accounting.example.com**
Zona yang di-hosting berikut cocok karena mereka induk dari seattle.accounting.example.com:
+ **accounting.example.com**
+ **example.com**
Jika tidak ada zona host pribadi yang cocok, maka VPC Resolver meneruskan permintaan ke resolver DNS publik, dan permintaan Anda diselesaikan sebagai kueri DNS biasa.
1. Jika ada nama zona yang di-hosting privat yang cocok dengan nama domain dalam permintaan, zona yang di-hosting akan mencari catatan yang cocok dengan nama domain dan jenis DNS dalam permintaan, seperti catatan A untuk accounting.example.com.
**catatan**
Jika ada zona host pribadi yang cocok tetapi tidak ada catatan yang cocok dengan nama domain dan mengetik permintaan, VPC Resolver tidak meneruskan permintaan ke resolver DNS publik. Alih-alih, NXDOMAIN (domain tidak ada) dikembalikan ke klien.
**Zona yang di-hosting privat dengan namespace yang tumpang tindih**
Jika Anda memiliki dua atau lebih zona host pribadi yang memiliki ruang nama yang tumpang tindih, seperti example.com dan accounting.example.com, VPC Resolver merutekan lalu lintas berdasarkan kecocokan paling spesifik.
Jika Anda memiliki zona host pribadi (example.com) dan aturan Resolver VPC Route 53 yang merutekan lalu lintas ke jaringan Anda untuk nama domain yang sama, aturan Resolver VPC akan diutamakan. Lihat [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules).
Saat pengguna masuk ke instans EC2 di VPC Amazon yang telah Anda kaitkan dengan semua zona yang dihosting pribadi, inilah cara VPC Resolver menangani kueri DNS:
1. VPC Resolver mengevaluasi apakah nama domain dalam permintaan, seperti accounting.example.com, cocok dengan nama salah satu zona yang dihosting pribadi.
1. Jika tidak ada zona host yang sama persis dengan nama domain dalam permintaan, VPC Resolver memeriksa zona host yang memiliki nama yang merupakan induk dari nama domain dalam permintaan. Misalnya, nama domain dalam permintaan adalah sebagai berikut:
`seattle.accounting.example.com`
Zona yang di-hosting berikut cocok karena mereka induk dari `seattle.accounting.example.com`:
+ `accounting.example.com`
+ `example.com`
VPC Resolver memilih `accounting.example.com` karena lebih spesifik daripada. `example.com`
1. VPC Resolver mencari zona yang `accounting.example.com` dihosting untuk catatan yang cocok dengan nama domain dan jenis DNS dalam permintaan, seperti catatan A untuk. `seattle.accounting.example.com`
Jika tidak ada catatan yang cocok dengan nama domain dan jenis permintaan, VPC Resolver mengembalikan NXDOMAIN (domain yang tidak ada) ke klien.
**Zona yang dihosting pribadi dan aturan Route 53 VPC Resolver**
Jika Anda memiliki zona host pribadi (example.com) dan aturan Resolver VPC yang merutekan lalu lintas ke jaringan Anda untuk nama domain yang sama, aturan Resolver VPC akan diutamakan.
Sebagai contoh, anggap Anda memiliki konfigurasi berikut:
+ Anda memiliki zona yang di-hosting privat yang disebut example.com, dan mengaitkannya dengan VPC.
+ Anda membuat aturan Resolver VPC Route 53 yang meneruskan lalu lintas contoh.com ke jaringan Anda, dan Anda mengaitkan aturan dengan VPC yang sama.
Dalam konfigurasi ini, aturan Resolver VPC lebih diutamakan daripada zona host pribadi. Kueri DNS diteruskan ke jaringan Anda, bukan diselesaikan berdasarkan catatan di zona yang di-hosting privat.
**Mendelegasikan tanggung jawab untuk subdomain**
Anda sekarang dapat membuat catatan NS di zona host pribadi untuk mendelegasikan tanggung jawab untuk subdomain. Untuk informasi selengkapnya, lihat [Tutorial aturan delegasi penyelesai](outbound-delegation-tutorial.md).
**Server DNS kustom**
Jika Anda telah mengonfigurasi server DNS kustom dalam instans Amazon EC2 di VPC, Anda harus mengonfigurasi server DNS tersebut untuk merutekan kueri DNS privat ke alamat IP server DNS yang disediakan Amazon untuk VPC. Alamat IP ini adalah alamat IP di dasar rentang jaringan VPC "plus two". Misalnya, jika rentang CIDR untuk VPC adalah 10.0.0.0/16, alamat IP server DNS adalah 10.0.0.2.
Jika Anda ingin merutekan kueri DNS antara VPCs dan jaringan Anda, Anda dapat menggunakan VPC Resolver. Untuk informasi selengkapnya, lihat [Apa itu Route 53 VPC Resolver?](resolver.md).
**Izin IAM yang diperlukan**
Untuk membuat zona yang di-hosting privat, Anda perlu memberikan izin IAM untuk tindakan Amazon EC2 selain izin untuk tindakan Route 53. Untuk informasi selengkapnya, lihat [Kunci tindakan, sumber daya, dan kondisi untuk Rute 53](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html) di *Referensi Otorisasi Layanan*.
# Membuat zona yang di-hosting privat
Zona yang dihosting pribadi adalah wadah untuk catatan untuk domain yang Anda host di satu atau beberapa awan pribadi virtual Amazon (VPCs). Anda membuat zona yang dihosting untuk domain (seperti example.com), lalu Anda membuat catatan untuk memberi tahu Amazon Route 53 bagaimana Anda ingin lalu lintas dirutekan untuk domain tersebut di dalam dan di antara Anda. VPCs
**penting**
Ketika membuat zona yang di-hosting privat, Anda harus mengaitkan VPC dengan zona yang di-hosting, dan VPC yang Anda tentukan harus dibuat menggunakan akun yang sama yang Anda gunakan untuk membuat zona yang di-hosting. Setelah Anda membuat zona yang dihosting, Anda dapat mengaitkan tambahan VPCs dengannya, termasuk VPCs yang Anda buat dengan menggunakan AWS akun yang berbeda.
Untuk mengaitkan VPCs yang Anda buat dengan menggunakan satu akun dengan zona host pribadi yang Anda buat dengan menggunakan akun lain, Anda harus mengotorisasi asosiasi dan kemudian membuat asosiasi secara terprogram. Untuk informasi selengkapnya, lihat [Mengaitkan VPC Amazon dan zona host pribadi yang Anda buat dengan akun berbeda AWS](hosted-zone-private-associate-vpcs-different-accounts.md).
Untuk informasi tentang membuat zona yang di-hosting privat menggunakan API Route 53, lihat [Referensi API Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/APIReference/).
**Cara membuat zona yang di-hosting privat menggunakan konsol Route 53**
1. Untuk setiap VPC yang ingin Anda kaitkan dengan zona yang di-hosting Route 53, ubah pengaturan VPC berikut ke `true`:
+ `enableDnsHostnames`
+ `enableDnsSupport`
Untuk informasi selengkapnya, lihat [Memperbarui DNS dukungan untuk VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) dalam *Panduan Pengguna Amazon VPC*.
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Jika Anda baru mengenal Route 53, pilih **Memulai**
Jika Anda sudah menggunakan Route 53, pilih **Zona yang di-hosting** pada panel navigasi.
1. Pilih **Buat Zona yang di-hosting**.
1. Pada panel **Buat zona yang di-hosting privat**, masukkan nama domain dan, secara opsional, komentar.
Untuk informasi tentang cara menentukan karakter selain a-z, 0-9, dan - (tanda hubung) serta cara menentukan nama domain internasional, lihat [Format nama domain DNS](DomainNameFormat.md).
1. Di daftar **Jenis**, pilih **Zona yang di-hosting privat**.
1. Di daftar **ID VPC**, pilih VPC yang ingin Anda kaitkan dengan zona yang di-hosting.
**catatan**
Jika konsol menampilkan pesan berikut, Anda mencoba mengaitkan zona yang di-hosting yang menggunakan namespace yang sama seperti zona yang di-hosting lainnya dalam VPC yang sama:
"Domain yang bertentangan sudah terkait dengan VPC atau Set Delegasi yang diberikan".
Misalnya, jika zona A yang dihosting dan zona B yang dihosting keduanya memiliki nama domain yang sama, misalnya`example.com`, Anda tidak dapat mengaitkan kedua zona yang dihosting dengan VPC yang sama.
1. Pilih **Buat zona yang di-hosting**.
# Mencantumkan zona yang di-hosting privat
Anda dapat menggunakan konsol Amazon Route 53 untuk mencantumkan semua zona yang dihosting yang Anda buat dengan AWS akun saat ini. Untuk informasi tentang cara mencantumkan zona yang dihosting menggunakan API Route 53, lihat [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)di *Referensi API Amazon Route 53*.
**Untuk membuat daftar zona yang dihosting yang terkait dengan AWS akun**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pada panel navigasi, pilih **Zona yang di-hosting**.
Halaman **Zona yang Dihosting** secara otomatis menampilkan daftar semua zona yang dihosting yang dibuat menggunakan AWS akun saat ini. Kolom **Jenis** menunjukkan apakah zona yang di-hosting adalah privat atau publik. Pilih judul kolom untuk mengelompokkan semua zona yang di-hosting privat dan semua zona yang di-hosting publik.
# Mengaitkan lebih banyak VPCs dengan zona yang dihosting pribadi
Anda dapat menggunakan konsol Amazon Route 53 untuk mengaitkan lebih banyak VPCs dengan zona host pribadi jika Anda membuat zona yang dihosting dan VPCs dengan menggunakan AWS akun yang sama.
**penting**
Jika Anda ingin mengaitkan VPCs yang Anda buat dengan menggunakan satu akun dengan zona host pribadi yang Anda buat dengan menggunakan akun lain, Anda harus terlebih dahulu mengotorisasi asosiasi tersebut. Selain itu, Anda tidak dapat menggunakan AWS konsol untuk mengotorisasi asosiasi atau mengaitkannya VPCs dengan zona yang dihosting. Untuk informasi selengkapnya, lihat [Mengaitkan VPC Amazon dan zona host pribadi yang Anda buat dengan akun berbeda AWS](hosted-zone-private-associate-vpcs-different-accounts.md).
Untuk informasi tentang cara mengaitkan lebih lanjut VPCs dengan zona yang dihosting pribadi menggunakan API Route 53, lihat [Mengaitkan VPCWith HostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html) di *Referensi API Amazon Route 53*.
**Untuk mengaitkan tambahan VPCs dengan zona host pribadi menggunakan konsol Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pada panel navigasi, pilih **Zona yang di-hosting**.
1. Pilih tombol radio untuk zona host pribadi yang ingin Anda kaitkan lebih banyak VPCs .
1. Pilih **Edit**.
1. Pilih **Tambah VPC**.
1. Pilih Wilayah dan ID VPC yang ingin Anda kaitkan dengan zona yang di-hosting ini.
1. Untuk mengaitkan lebih banyak VPCs dengan zona yang dihosting ini, ulangi langkah 5 dan 6.
1. Pilih **Simpan perubahan**.
# Mengaitkan VPC Amazon dan zona host pribadi yang Anda buat dengan akun berbeda AWS
Jika Anda ingin mengaitkan VPC yang Anda buat dengan satu AWS akun dengan zona host pribadi yang Anda buat dengan akun lain, lakukan prosedur berikut:
**Untuk mengaitkan VPC Amazon dan zona host pribadi yang Anda buat dengan akun berbeda AWS**
1. Dengan akun yang membuat zona yang di-hosting, otorisasi pengaitan VPC dengan zona yang di-hosting privat menggunakan salah satu metode berikut:
+ **AWS CLI**— Lihat [create-vpc-association-authorization](https://docs.aws.amazon.com/cli/latest/reference/route53/create-vpc-association-authorization.html)di *Referensi AWS CLI Perintah*
+ ** AWS SDK** atau **AWS Tools for Windows PowerShell**— Lihat dokumentasi yang berlaku di halaman [AWS Dokumentasi](https://docs.aws.amazon.com/)
+ **Amazon Route 53 API** - Lihat [Membuat VPCAssociation Otorisasi](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html) di Referensi *API Amazon Route 53*
Perhatikan hal-hal berikut:
+ Jika Anda ingin mengaitkan beberapa VPCs yang Anda buat dengan satu akun dengan zona host yang Anda buat dengan akun berbeda, Anda harus mengirimkan satu permintaan otorisasi untuk setiap VPC.
+ Ketika mengotorisasi pengaitan, Anda harus menentukan ID zona yang di-hosting, maka dari itu zona yang di-hosting privat harus sudah ada.
+ Anda tidak dapat menggunakan konsol Route 53 untuk mengotorisasi pengaitan VPC dengan zona yang di-hosting privat atau untuk membuat pengaitan.
1. Menggunakan akun yang membuat VPC, kaitkan VPC dengan zona yang di-hosting. Seperti halnya mengotorisasi asosiasi, Anda dapat menggunakan AWS SDK, Tools for Windows PowerShell, the AWS CLI, atau Route 53 API. Jika Anda menggunakan API, gunakan VPCWith HostedZone tindakan [Associate](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html).
1. *Direkomendasikan* – Menghapus otorisasi untuk mengaitkan VPC dengan zona yang di-hosting. Menghapus otorisasi tidak memengaruhi pengaitan, ini hanya mencegah Anda agar tidak mengaitkan ulang VPC dengan zona yang di-hosting di masa mendatang. Jika ingin mengaitkan ulang VPC dengan zona yang di-hosting, Anda harus mengulangi langkah 1 dan 2 dari prosedur ini.
**penting**
`ListHostedZonesByVPC`Pengembalian zona yang dihosting yang diberikan VPC dan `GetHostedZone` API mengembalikan zona yang VPCs terkait dengan zona yang dihosting. Ini APIs hanya mempertimbangkan zona yang dihosting ke asosiasi VPC yang dibuat oleh `AssociateVPCWithHostedZone` API atau saat zona host pribadi dibuat. Jika Anda ingin daftar lengkap asosiasi zona yang dihosting ke VPC, hubungi juga. [ListProfileResourceAssociations](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53profiles_ListProfileResourceAssociations.html)
**catatan**
Untuk jumlah maksimum otorisasi yang dapat Anda buat, lihat [Kuota pada entitas](DNSLimitations.md#limits-api-entities).
# Memutuskan hubungan VPCs dari zona yang dihosting pribadi
Anda dapat menggunakan konsol Amazon Route 53 untuk memisahkan diri VPCs dari zona host pribadi. Tindakan ini membuat Route 53 menghentikan perutean lalu lintas menggunakan catatan di zona yang di-hosting untuk kueri DNS yang berasal dari VPC. Sebagai contoh, jika zona yang di-hosting privat example.com dikaitkan dengan VPC dan Anda memisahkan zona yang di-hosting dari VPC tersebut, Route 53 berhenti menyelesaikan kueri DNS untuk example.com atau salah satu catatan lainnya di zona yang di-hosting example.com.
**catatan**
Anda tidak dapat memisahkan VPC terakhir dari zona yang di-hosting privat. Jika ingin memisahkan VPC, Anda terlebih dahulu harus mengaitkan VPC lain dengan zona yang di-hosting.
**Untuk memisahkan diri VPCs dari zona yang dihosting pribadi**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pada panel navigasi, pilih **Zona yang di-hosting**.
1. Pilih tombol radio untuk zona host pribadi yang ingin Anda lepaskan satu atau lebih VPCs .
1. Pilih **Edit**.
1. Pilih **Hapus VPC** di sebelah VPC yang Anda ingin pisahkan dari zona yang di-hosting.
1. Pilih **Simpan perubahan**.
# Menghapus zona yang di-hosting privat
Bagian ini menjelaskan cara menghapus zona yang di-hosting privat menggunakan konsol Amazon Route 53.
Anda dapat menghapus zona yang di-hosting privat hanya jika tidak ada catatan selain catatan SOA dan NS default. Jika zona yang di-hosting berisi catatan lain, Anda harus menghapusnya sebelum Anda dapat menghapus zona yang di-hosting. Hal ini mencegah Anda agar tidak menghapus zona yang di-hosting yang masih berisi catatan secara tidak sengaja.
**Topics**
+ [Menghapus zona yang di-hosting privat yang dibuat oleh layanan lain](#delete-private-hosted-zone-created-by-another-service)
+ [Menggunakan konsol Route 53 untuk menghapus zona yang di-hosting privat](#delete-private-hosted-zone-procedure)
## Menghapus zona yang di-hosting privat yang dibuat oleh layanan lain
Jika zona yang di-hosting privat dibuat oleh layanan lain, Anda tidak dapat menghapusnya menggunakan konsol Route 53. Sebagai gantinya, Anda perlu menggunakan proses yang berlaku untuk layanan lainnya:
+ **AWS Cloud Map**— Untuk menghapus zona host yang AWS Cloud Map dibuat saat Anda membuat namespace DNS pribadi, hapus namespace. AWS Cloud Map menghapus zona yang dihosting secara otomatis. Untuk informasi selengkapnya, lihat [Menghapus namespace](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) di *Panduan Developer AWS Cloud Map *.
+ **Penemuan Layanan Amazon Elastic Container Service (Amazon ECS)** – Untuk menghapus zona yang di-hosting privat yang dibuat Amazon ECS ketika Anda membuat layanan menggunakan penemuan layanan, hapus layanan Amazon ECS yang menggunakan namespace, dan hapus namespace. Untuk informasi lebih lanjut, lihat [Menghapus layanan](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) dalam *Panduan Developer Amazon Elastic Container Service*.
## Menggunakan konsol Route 53 untuk menghapus zona yang di-hosting privat
Untuk menggunakan konsol Route 53 guna menghapus zona yang di-hosting privat, lakukan prosedur berikut.
**Cara menghapus zona yang di-hosting privat menggunakan konsol Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Mengonfirmasi bahwa zona yang di-hosting yang ingin Anda hapus hanya berisi catatan NS dan SOA. Jika berisi catatan tambahan, hapuslah:
1. Pilih nama zona yang di-hosting yang ingin Anda hapus.
1. Pada halaman **Catatan**, jika daftar catatan termasuk catatan dengan nilai selain **NS** atau **SOA** pada kolom **Jenis**, pilih baris, dan pilih **Hapus**.
Untuk memilih beberapa catatan berturut-turut, pilih baris pertama, tekan dan tahan tombol **Shift**, dan pilih baris terakhir. Untuk memilih beberapa catatan tidak berturut-turut, pilih baris pertama, tekan dan tahan tombol **Ctrl**, dan pilih baris yang tersisa.
1. Di halaman Zona yang Di-hosting, pilih baris zona yang di-hosting yang ingin Anda hapus.
1. Pilih **Hapus**.
1. Ketik kunci konfirmasi dan pilih **Hapus**.
# Izin VPC
[https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteVPCAssociationAuthorization.html](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteVPCAssociationAuthorization.html) APIs
Dengan kondisi kebijakan IAM`route53:VPCs`, Anda dapat memberikan hak administratif terperinci kepada pengguna lain AWS . Ini memungkinkan Anda memberikan izin kepada seseorang untuk mengaitkan zona yang dihosting dengan, memisahkan zona yang dihosting dari, membuat otorisasi asosiasi VPC untuk, menghapus otorisasi asosiasi VPC untuk, membuat zona yang dihosting dengan atau mencantumkan zona yang dihosting untuk:
+ Sebuah VPC tunggal.
+ Semua orang VPCs dalam wilayah yang sama.
+ Berganda VPCs.
Untuk informasi selengkapnya tentang izin VPC, lihat. [Menggunakan ketentuan kebijakan IAM untuk kontrol akses terperinci](specifying-conditions-route53.md)
Untuk mempelajari cara mengautentikasi AWS pengguna, lihat [Mengautentikasi dengan identitas](security-iam.md#security_iam_authentication) dan mempelajari cara mengontrol akses ke sumber daya Route 53, lihat[Kontrol akses](security-iam.md#access-control).
# Migrasi zona yang dihosting ke akun lain AWS
Saat memigrasikan zona yang dihosting ke zona lain Akun AWS, ikuti langkah-langkah yang disarankan ini.
Langkah-langkah ini paling cocok untuk zona yang dihosting dengan perubahan catatan yang jarang terjadi. Untuk zona yang dihosting dengan pembaruan rekaman yang sering, pertimbangkan hal berikut:
+ Jangan memperbarui catatan sumber daya apa pun selama migrasi.
+ Publikasikan perubahan catatan sumber daya di zona host lama dan baru setelah delegasi ditransfer.
**Prasyarat**
Instal atau tingkatkan AWS CLI:
Untuk informasi tentang mengunduh, menginstal, dan mengonfigurasi AWS CLI, lihat [Panduan AWS Command Line Interface Pengguna](https://docs.aws.amazon.com/cli/latest/userguide/).
**catatan**
Mengkonfigurasi CLI agar Anda dapat menggunakannya ketika menggunakan akun yang membuat zona yang di-hosting dan akun yang dimigrasi ke zona yang di-hosting. Untuk informasi selengkapnya, lihat [Konfigurasi](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) dalam *Panduan Pengguna AWS Command Line Interface *
Jika Anda sudah menggunakan AWS CLI, kami sarankan Anda meningkatkan ke versi terbaru CLI sehingga perintah CLI mendukung fitur Route 53 terbaru.
**Topics**
+ [Langkah 1: Bersiaplah untuk Migrasi](#hosted-zones-migrating-prepare)
+ [Langkah 2: Membuat zona yang di-hosting baru](#hosted-zones-migrating-create-hosted-zone)
+ [Langkah 3: (Opsional) Migrasikan pemeriksaan kesehatan](#hosted-zones-migrating-health-checks)
+ [Langkah 4: Migrasikan catatan dari zona host lama ke zona host baru](#hosted-zones-migrating-old-to-new)
+ [Langkah 5: Bandingkan catatan di zona host lama dan baru](#hosted-zones-migrating-compare)
+ [Langkah 6: Perbarui pendaftaran domain untuk menggunakan server nama untuk zona host baru](#hosted-zones-migrating-update-domain)
+ [Langkah 7: Ubah TTL untuk catatan NS kembali ke nilai yang lebih tinggi](#hosted-zones-migrating-change-ttl)
+ [Langkah 8: Aktifkan kembali penandatanganan DNSSEC dan buat rantai kepercayaan (jika diperlukan)](#hosted-zones-migrating-enable-dnssec)
+ [Langkah 9: (Opsional) hapus zona host lama](#hosted-zones-migrating-delete-old-hosted-zone)
## Langkah 1: Bersiaplah untuk Migrasi
Langkah-langkah persiapan membantu Anda meminimalkan risiko yang terkait dengan migrasi zona yang dihosting.
**1. Memantau ketersediaan zona**
Anda dapat memantau zona untuk ketersediaan nama domain Anda. Ini dapat membantu Anda mengatasi masalah apa pun yang mungkin menyebabkan pengembalian migrasi. Anda dapat memantau nama domain Anda dengan sebagian besar lalu lintas dengan menggunakan CloudWatch atau melakukan pencatatan kueri. Untuk informasi selengkapnya tentang menyiapkan pencatatan kueri, lihat[Memantau Amazon Route 53](monitoring-overview.md).
Pemantauan dapat dilakukan melalui skrip shell, atau melalui layanan pihak ketiga. Namun, seharusnya tidak menjadi satu-satunya sinyal untuk menentukan apakah rollback diperlukan karena Anda mungkin juga mendapatkan umpan balik dari pelanggan Anda karena domain tidak tersedia.
**2. Turunkan pengaturan TTL**
Pengaturan TTL (waktu untuk tayang) bagi catatan menentukan durasi penyelesai DNS untuk meng-cache catatan dan menggunakan informasi yang di-cache. Ketika TTL berakhir, penyelesai mengirimkan kueri lain ke penyedia layanan DNS untuk domain guna mendapatkan informasi terbaru.
Pengaturan TTL khas untuk catatan NS adalah 172800 detik, atau dua hari. Catatan NS mencantumkan server nama yang dapat digunakan Sistem Nama Domain (DNS) untuk mendapatkan informasi tentang cara merutekan lalu lintas domain Anda. Menurunkan TTL untuk catatan NS, baik dengan penyedia layanan DNS Anda saat ini maupun dengan Route 53, mengurangi waktu henti untuk domain Anda jika Anda menemukan masalah saat Anda memigrasikan DNS ke Route 53. Jika Anda tidak menurunkan TTL, domain mungkin tidak tersedia di internet hingga dua hari jika terjadi kesalahan.
**Untuk menurunkan TTL**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pilih **Zona yang dihosting** di panel navigasi.
1. Pilih nama zona yang di-hosting.
1. Pilih catatan NS, dan di panel **Record details**, pilih **Edit record**.
1. Mengubah nilai **TTL (Detik)**. Kami rekomendasikan Anda menentukan nilai antara 60 detik hingga 900 detik (15 menit).
1. Pilih **Simpan**.
**3. Hapus catatan DS dari zona induk (Jika Anda memiliki DNSSEC dikonfigurasi)**
Jika Anda telah mengonfigurasi DNSSEC untuk domain, hapus catatan Delegation Signer (DS) dari zona induk sebelum memigrasi domain ke Route 53.
Jika zona induk di-host melalui Route 53, lihat [Menghapus kunci publik untuk domain](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys) untuk informasi selengkapnya. Jika zona induk di-host di registrar lain, hubungi mereka untuk menghapus catatan DS.
Route 53 saat ini tidak mendukung migrasi setelan DNSSEC. Dengan demikian, Anda harus menonaktifkan validasi DNSSEC yang dilakukan terhadap domain Anda sebelum migrasi dengan menghapus catatan DS dari zona induk. Setelah migrasi, Anda dapat mengaktifkan kembali validasi DNSSEC dengan mengonfigurasi DNSSEC di zona host baru dan menambahkan catatan DS masing-masing ke zona induk.
**4. Pastikan tidak ada operasi lain yang sedang berlangsung yang bergantung pada zona host yang bermigrasi**
Beberapa operasi akan bergantung pada resolusi DNS di zona host yang bermigrasi, misalnya, proses perpanjangan TLS/SSL sertifikat mungkin memerlukan perubahan catatan DNS dan penyedia akan mencoba menyelesaikan catatan DNS sebagai metode validasi. Sebelum migrasi, Anda harus memastikan tidak ada operasi lain yang terjadi, untuk menghindari dampak tak terduga dari migrasi zona yang dihosting.
## Langkah 2: Membuat zona yang di-hosting baru
Buat zona host baru di akun tempat Anda ingin memigrasikan zona yang dihosting.
Pilih tab untuk instruksi untuk konsol AWS CLI atau konsol.
+ [CLI](#migrate-hz-cli)
+ [Konsol](#migrate-hz-console)
------
#### [ CLI ]
Masukkan perintah berikut:
```
aws route53 create-hosted-zone \
--name $hosted_zone_name \
--caller-reference $unique_string
```
Untuk informasi selengkapnya, lihat [create-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/create-hosted-zone.html).
------
#### [ Console ]
**Cara membuat zona yang di-hosting baru menggunakan akun yang berbeda**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
Masuk dengan kredensial akun untuk akun yang ingin dimigrasi ke zona yang di-hosting.
1. Membuat zona yang di-hosting. Untuk informasi selengkapnya, lihat [Membuat zona yang di-hosting publik](CreatingHostedZone.md).
1. Catat ID zona yang di-hosting. Dalam beberapa kasus, Anda akan memerlukan informasi ini nanti dalam prosesnya.
1. Keluar dari konsol Route 53.
Turunkan NS TTL di zona baru juga, mirip dengan pengaturan TTL Bawah dalam persiapan Langkah 1, Turunkan pengaturan TTL.
------
## Langkah 3: (Opsional) Migrasikan pemeriksaan kesehatan
Anda dapat mengaitkan catatan DNS di akun baru dengan pemeriksaan kesehatan Route 53 dari akun tempat Anda bermigrasi. Untuk memigrasikan pemeriksaan kesehatan Route 53, Anda perlu membuat pemeriksaan kesehatan baru di akun baru Anda dengan konfigurasi yang sama dengan yang sudah ada. Untuk informasi selengkapnya, lihat [Membuat pemeriksaan kesehatan Amazon Route 53](dns-failover.md).
## Langkah 4: Migrasikan catatan dari zona host lama ke zona host baru
Anda dapat memigrasikan rekaman dari satu Akun AWS ke yang lain dengan menggunakan konsol atau file. AWS CLI
------
#### [ Console ]
Jika zona Anda hanya berisi beberapa catatan, Anda dapat mempertimbangkan untuk menggunakan konsol Route 53 untuk mencantumkan catatan di zona lama Anda, mencatatnya, dan membuatnya di zona baru. Jika Anda telah memigrasikan pemeriksaan kesehatan[Langkah 3: (Opsional) Migrasikan pemeriksaan kesehatan](#hosted-zones-migrating-health-checks), saat membuat catatan di zona host baru, Anda harus menentukan ID pemeriksaan kesehatan baru. Untuk informasi selengkapnya, lihat topik berikut:
+ [Mencantumkan catatan](resource-record-sets-listing.md)
+ [Membuat catatan dengan menggunakan konsol Amazon Route 53](resource-record-sets-creating.md)
+ [Mengonfigurasi failover DNS](dns-failover-configuring.md)
Anda harus menurunkan NS TTL di zona baru juga, mirip dengan pengaturan TTL Bawah di Langkah 1.
------
#### [ CLI ]
Jika zona Anda berisi sejumlah besar catatan, Anda dapat mengekspor catatan yang ingin Anda migrasi ke file, mengedit file, dan kemudian menggunakan file yang diedit untuk membuat catatan di zona host baru. Prosedur berikut menggunakan perintah AWS CLI, meskipun alat pihak ketiga juga tersedia untuk tujuan ini.
****
1. Jalankan perintah berikut:
```
aws route53 list-resource-record-sets --hosted-zone-id hosted-zone-id > path-to-output-file
```
Perhatikan hal-hal berikut:
+ Untuk*hosted-zone-id*, tentukan ID zona host lama yang berisi catatan yang ingin Anda migrasi.
+ Untuk*path-to-output-file*, tentukan jalur direktori dan nama file tempat Anda ingin menyimpan outputnya.
+ Karakter `>` mengirimkan output ke file yang ditentukan.
+ AWS CLI Secara otomatis menangani pagination untuk zona yang dihosting yang berisi lebih dari 100 catatan. Untuk informasi selengkapnya, lihat [Menggunakan opsi pagination Antarmuka Baris AWS Perintah](https://docs.aws.amazon.com/cli/latest/userguide/pagination.html) di *Panduan AWS Command Line Interface Pengguna*.
Jika Anda menggunakan metode terprogram lain untuk membuat daftar catatan, seperti salah satunya AWS SDKs, Anda bisa mendapatkan maksimal 100 catatan per halaman hasil. Jika zona yang di-hosting berisi lebih dari 100 catatan, Anda harus mengirimkan beberapa permintaan untuk mencantumkan semua catatan.
Buat salinan output ini. Setelah Anda membuat catatan di zona host baru, kami sarankan Anda menjalankan AWS CLI `list-resource-record-sets` perintah di zona host baru dan membandingkan dua output untuk memastikan bahwa semua catatan dibuat.
1. Edit catatan yang ingin Anda migrasikan.
Edit file yang diekspor sebelum Anda dapat menggunakannya dengan `change-resource-record-sets` perintah. Anda dapat membuat perubahan ini menggunakan fungsi pencarian dan ganti di editor teks.
**catatan**
Langkah-langkah berikut menjelaskan pengeditan manual menggunakan editor teks. Pengguna tingkat lanjut dapat mengotomatiskan transformasi ini menggunakan alat terprogram seperti jq, Python, atau bahasa scripting lainnya.
Buka salinan file yang Anda buat di langkah 1 prosedur ini yang berisi catatan yang ingin Anda migrasi, dan buat perubahan berikut:
+ Ganti ResourceRecordSets elemen di bagian atas file dengan `Changes` elemen.
+ Opsional - menambahkan `Comment` elemen.
+ Hapus baris yang terkait dengan catatan NS dan SOA dari nama zona yang dihosting. zona yang di-hosting baru sudah memiliki catatan tersebut.
+ Untuk setiap catatan, tambahkan `ResourceRecordSets` elemen `Action` dan, tambahkan tanda kurung pembuka dan penutup (`{ }`) sesuai kebutuhan untuk membuat kode JSON valid.
**catatan**
Anda dapat menggunakan validator JSON untuk memverifikasi bahwa semua tanda kurung ada di tempat yang benar. Untuk menemukan validator JSON online, cari “validator JSON” di browser Anda.
+ Jika zona yang di-hosting berisi alias yang merujuk ke catatan lain di zona yang di-hosting yang sama, buat perubahan berikut:
+ Ubah ID zona yang di-hosting menjadi ID zona yang di-hosting baru.
**penting**
Jika catatan alias menunjuk ke sumber daya lain, misalnya penyeimbang beban, jangan ubah ID zona yang dihosting ke ID zona yang dihosting domain. Jika Anda mengubah ID zona yang dihosting secara tidak sengaja, kembalikan ID zona yang dihosting ke id zona yang dihosting dari sumber daya itu sendiri, bukan ID zona yang dihosting dari domain tersebut. ID zona yang dihosting sumber daya dapat ditemukan di AWS konsol tempat sumber daya dibuat.
+ Pindahkan catatan alias ke bagian bawah file. Route 53 harus membuat catatan yang dirujuk catatan alias sebelum dapat membuat catatan alias.
**penting**
Jika satu atau lebih catatan alias merujuk ke catatan alias lain, catatan yang merupakan target alias harus muncul dalam file sebelum mereferensi catatan alias. Misalnya, jika `alias.example.com` adalah target alias untuk `alias.alias.example.com`, `alias.example.com` harus muncul terlebih dahulu di file.
+ Hapus catatan alias yang merutekan lalu lintas ke instans kebijakan lalu lintas. Catat catatan tersebut agar Anda dapat membuatnya lagi nanti.
+ Jika Anda memigrasikan pemeriksaan kesehatan[Langkah 3: (Opsional) Migrasikan pemeriksaan kesehatan](#hosted-zones-migrating-health-checks), ubah catatan untuk dikaitkan dengan pemeriksaan IDs kesehatan yang baru dibuat.
Contoh berikut menunjukkan versi catatan yang diedit untuk zona yang di-hosting bagi example.com. Teks merah dan dicetak miring adalah yang baru:
```
{
"Comment": "string",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet":{
"ResourceRecords": [
{
"Value": "192.0.2.4"
},
{
"Value": "192.0.2.5"
},
{
"Value": "192.0.2.6"
}
],
"Type": "A",
"Name": "route53documentation.com.",
"TTL": 300
}
},
{
"Action": "CREATE",
"ResourceRecordSet":{
"AliasTarget": {
"HostedZoneId": "Z3BJ6K6RIION7M",
"EvaluateTargetHealth": false,
"DNSName": "s3-website-us-west-2.amazonaws.com."
},
"Type": "A",
"Name": "www.route53documentation.com."
}
}
]
}
```
1. Membagi file besar menjadi file yang lebih kecil
Jika Anda memiliki banyak catatan atau jika Anda memiliki catatan dengan banyak nilai (misalnya, banyak alamat IP), Anda mungkin perlu membagi file menjadi file yang lebih kecil. Nilai maksnya adalah:
+ Setiap file dapat berisi maksimum 1.000 catatan.
+ Panjang nilai gabungan maksimum dalam semua elemen `Value` adalah 32.000 byte.
1. Buat catatan di zona host baru
Masukkan CLI berikut:
```
aws route53 change-resource-record-sets \
--hosted-zone-id new-hosted-zone-id \
--change-batch file://path-to-file-that-contains-records
```
Tentukan nilai-nilai berikut ini:
+ Untuk`new-hosted-zone-id`, tentukan ID zona host baru.
+ Untuk`path-to-file-that-contains-records`, tentukan jalur direktori dan nama file yang Anda edit di langkah sebelumnya.
Jika Anda menghapus catatan alias yang merutekan lalu lintas ke instans kebijakan lalu lintas, buat ulang catatan alias menggunakan konsol Route 53. Untuk informasi selengkapnya, lihat [Membuat catatan dengan menggunakan konsol Amazon Route 53](resource-record-sets-creating.md).
------
## Langkah 5: Bandingkan catatan di zona host lama dan baru
Untuk mengonfirmasi bahwa Anda berhasil membuat semua catatan Anda di zona host baru, masukkan perintah CLI berikut untuk membuat daftar catatan di zona host baru dan bandingkan output dengan daftar catatan dari zona host lama.
```
aws route53 list-resource-record-sets \
--hosted-zone-id new-hosted-zone-id \
--output json > path-to-output-file
```
Tentukan nilai-nilai berikut ini:
+ Untuk`new-hosted-zone-id`, tentukan ID zona host baru.
+ Untuk`path-to-output-file`, tentukan jalur direktori dan nama file tempat Anda ingin menyimpan outputnya. Gunakan nama file yang berbeda dari nama file yang Anda gunakan di Langkah 4.
Karakter `>` mengirimkan output ke file yang ditentukan.
Bandingkan output dengan output dari Langkah 4. Selain nilai catatan NS dan SOA dan perubahan apa pun yang Anda buat di Langkah 4 (seperti zona host IDs atau nama domain yang berbeda), kedua output harus identik.
Jika catatan di zona host baru tidak cocok dengan catatan di zona host lama, lakukan salah satu hal berikut:
+ Buat koreksi kecil menggunakan konsol Route 53. Untuk informasi selengkapnya, lihat [Mengedit catatan](resource-record-sets-editing.md).
+ Hapus semua catatan kecuali catatan NS dan SOA di zona host baru, dan ulangi prosedur di Langkah 4.
## Langkah 6: Perbarui pendaftaran domain untuk menggunakan server nama untuk zona host baru
Setelah Anda selesai memigrasikan catatan ke zona host baru, ubah server nama untuk pendaftaran domain untuk menggunakan server nama untuk zona host baru. Untuk informasi selengkapnya, lihat Menetapkan Amazon Route 53 sebagai layanan DNS untuk domain yang ada.
Jika zona host Anda sedang digunakan - misalnya, jika pengguna Anda menggunakan nama domain untuk menjelajah ke situs web atau mengakses aplikasi web - Anda harus terus memantau lalu lintas dan ketersediaan zona yang dihosting, termasuk lalu lintas situs web atau aplikasi, email, dll.
+ **Jika lalu lintas melambat atau berhenti** — Ubah layanan nama untuk pendaftaran domain kembali ke server nama sebelumnya dari zona host lama. Kemudian tentukan apa yang salah.
+ **Jika lalu lintas tidak terpengaruh** — Lanjutkan ke langkah berikutnya.
## Langkah 7: Ubah TTL untuk catatan NS kembali ke nilai yang lebih tinggi
Di zona host baru, ubah TTL untuk catatan NS ke nilai yang lebih khas, misalnya, 172800 detik (dua hari). Hal ini meningkatkan latensi untuk pengguna Anda karena mereka tidak harus sering menunggu penyelesai DNS mengirim kueri bagi server nama untuk domain Anda.
**Untuk mengubah TTL**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pilih **Zona yang dihosting** di panel navigasi.
1. Pilih nama zona yang di-hosting.
1. Pilih catatan NS, dan di panel **Record details**, pilih **Edit record**.
1. Ubah nilai **TTL (Seconds)** ke jumlah detik yang Anda inginkan DNS resolver untuk cache nama-nama server nama untuk domain Anda. Kami merekomendasikan nilai 172800 detik.
1. Pilih **Simpan**.
## Langkah 8: Aktifkan kembali penandatanganan DNSSEC dan buat rantai kepercayaan (jika diperlukan)
Anda dapat mengaktifkan kembali penandatanganan DNSSEC dalam dua langkah:
1. Aktifkan penandatanganan DNSSEC untuk Route 53, dan minta Route 53 membuat kunci penandatanganan kunci (KSK) berdasarkan kunci yang dikelola pelanggan. AWS Key Management Service
1. Buat rantai kepercayaan untuk zona yang dihosting dengan menambahkan catatan Delegation Signer (DS) ke zona induk, sehingga respons DNS dapat diautentikasi dengan tanda tangan kriptografi tepercaya.
Untuk petunjuk, lihat [Mengaktifkan penandatanganan DNSSEC dan membuat rantai kepercayaan](dns-configuring-dnssec-enable-signing.md).
## Langkah 9: (Opsional) hapus zona host lama
Ketika Anda yakin bahwa zona yang di-hosting lama tidak lagi diperlukan, Anda memiliki opsi untuk menghapusnya. Untuk petunjuk, lihat [Menghapus zona yang di-hosting publik](DeleteHostedZone.md).
**penting**
Jangan hapus zona yang di-hosting lama atau catatan di zona yang di-hosting tersebut setidaknya 48 jam setelah Anda memperbarui pendaftaran domain untuk menggunakan server nama bagi zona yang di-hosting baru. Jika Anda menghapus zona yang di-hosting lama sebelum penyelesai DNS berhenti menggunakan catatan di zona yang di-hosting tersebut, domain Anda mungkin tidak tersedia di internet hingga penyelesai mulai menggunakan zona yang di-hosting baru.
# Bekerja dengan catatan
Setelah Anda membuat zona yang di-hosting untuk domain Anda, seperti example.com, Anda membuat catatan untuk memberi tahu Domain Name System (DNS) bagaimana Anda ingin lalu lintas dirutekan untuk domain tersebut.
Misalnya, Anda mungkin membuat catatan yang menyebabkan DNS melakukan hal berikut:
+ Rutekan lalu lintas internet misalnya.com ke alamat IP host di pusat data Anda.
+ Rutekan email untuk domain tersebut (ichiro@example.com) ke server email (mail.example.com).
+ Rutekan lalu lintas untuk subdomain yang disebut operations.tokyo.example.com ke alamat IP dari host yang berbeda.
Setiap catatan mencakup nama domain atau subdomain, jenis catatan (misalnya, catatan dengan jenis email rute MX), dan informasi lain yang berlaku untuk jenis catatan (untuk data MX, nama host dari satu atau lebih server surat dan prioritas untuk setiap server). Untuk informasi selengkapnya tentang berbagai jenis catatan, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Nama setiap catatan di zona yang di-hosting harus diakhiri dengan nama zona yang di-hosting. Misalnya, zona yang di-hosting example.com dapat berisi catatan untuk subdomain www.example.com dan accounting.tokyo.example.com, tetapi tidak dapat berisi catatan untuk subdomain www.example.ca.
**catatan**
Untuk membuat catatan untuk konfigurasi perutean yang kompleks, Anda juga dapat menggunakan editor visual Aliran Lalu Lintas dan menyimpan konfigurasi sebagai kebijakan lalu lintas. Anda kemudian dapat mengaitkan kebijakan lalu lintas dengan satu atau lebih nama domain (seperti example.com) atau nama subdomain (seperti www.example.com), di zona yang di-hosting yang sama atau di beberapa zona yang di-hosting. Selain itu, Anda dapat memulihkan pembaruan jika konfigurasi baru tidak memiliki performa seperti yang Anda harapkan. Untuk informasi selengkapnya, lihat [Menggunakan Arus Lalu Lintas untuk merutekan lalu lintas DNS](traffic-flow.md).
Amazon Route 53 tidak mengenakan biaya untuk catatan yang Anda tambahkan ke zona yang di-hosting. Untuk informasi tentang jumlah maksimum catatan yang dapat Anda buat di zona yang di-hosting, lihat [Kuota](DNSLimitations.md).
**Topics**
+ [Memilih kebijakan perutean](routing-policy.md)
+ [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md)
+ [Tipe data DNS yang didukung](ResourceRecordTypes.md)
+ [Membuat catatan dengan menggunakan konsol Amazon Route 53](resource-record-sets-creating.md)
+ [Izin set catatan sumber daya](resource-record-sets-permissions.md)
+ [Nilai yang Anda tentukan saat membuat atau mengedit catatan Amazon Route 53](resource-record-sets-values.md)
+ [Membuat catatan dengan mengimpor file zona](resource-record-sets-creating-import.md)
+ [Mengedit catatan](resource-record-sets-editing.md)
+ [Menghapus catatan](resource-record-sets-deleting.md)
+ [Mencantumkan catatan](resource-record-sets-listing.md)
# Memilih kebijakan perutean
Saat Anda membuat catatan, Anda memilih kebijakan perutean, yang menentukan bagaimana Amazon Route 53 merespons kueri:
+ **Kebijakan perutean sederhana** – Gunakan untuk satu sumber daya yang menjalankan fungsi tertentu untuk domain Anda, misalnya, server web yang menyajikan konten untuk situs web example.com. Anda dapat menggunakan perutean sederhana untuk membuat catatan di zona host pribadi.
+ **Kebijakan perutean failover** – Gunakan ketika Anda ingin mengonfigurasi failover aktif-pasif. Anda dapat menggunakan perutean failover untuk membuat catatan di zona host pribadi.
+ **Kebijakan perutean geolokasi**– Gunakan saat Anda ingin merutekan lalu lintas berdasarkan lokasi pengguna Anda. Anda dapat menggunakan perutean geolokasi untuk membuat catatan di zona host pribadi.
+ **Kebijakan perutean geoproximity** - Gunakan saat Anda ingin merutekan lalu lintas berdasarkan lokasi sumber daya Anda dan, secara opsional, mengalihkan lalu lintas dari sumber daya di satu lokasi ke sumber daya di lokasi lain. Anda dapat menggunakan perutean geoproximity untuk membuat catatan di zona host pribadi.
+ **Kebijakan perutean latensi** — Gunakan saat Anda memiliki sumber daya dalam beberapa Wilayah AWS dan Anda ingin merutekan lalu lintas ke Wilayah yang memberikan latensi terbaik. Anda dapat menggunakan perutean latensi untuk membuat catatan di zona host pribadi.
+ **Kebijakan perutean berbasis IP** — Gunakan saat Anda ingin merutekan lalu lintas berdasarkan lokasi pengguna Anda, dan dapatkan alamat IP tempat lalu lintas berasal.
+ **Kebijakan perutean jawaban multinilai** – Gunakan saat Anda ingin Route 53 merespons kueri DNS dengan hingga delapan catatan sehat yang dipilih secara acak. Anda dapat menggunakan routing jawaban multivalue untuk membuat catatan di zona host pribadi.
+ **Kebijakan perutean berbobot** – Gunakan untuk merutekan lalu lintas ke beberapa sumber daya dalam proporsi yang Anda tentukan. Anda dapat menggunakan perutean tertimbang untuk membuat catatan di zona host pribadi.
**Topics**
+ [Perutean sederhana](routing-policy-simple.md)
+ [Perutean failover](routing-policy-failover.md)
+ [Perutean geolokasi](routing-policy-geo.md)
+ [Perutean geoproksimitas](routing-policy-geoproximity.md)
+ [Perutean berbasis latensi](routing-policy-latency.md)
+ [Perutean berbasis IP](routing-policy-ipbased.md)
+ [Perutean jawaban multinilai](routing-policy-multivalue.md)
+ [Perutean tertimbang](routing-policy-weighted.md)
+ [Bagaimana Amazon Route 53 digunakan EDNS0 untuk memperkirakan lokasi pengguna](routing-policy-edns0.md)
# Perutean sederhana
Perutean sederhana memungkinkan Anda mengonfigurasi data DNS standar, tanpa perutean Route 53 khusus seperti tertimbang atau latensi. Dengan perutean yang sederhana, Anda biasanya mengarahkan lalu lintas ke sumber daya tunggal, misalnya, ke server web untuk situs web Anda.
Anda dapat menggunakan kebijakan perutean sederhana untuk catatan di zona host pribadi.
Jika Anda memilih kebijakan perutean sederhana di konsol Route 53, Anda tidak dapat membuat beberapa catatan yang memiliki nama dan jenis yang sama, tetapi Anda dapat menentukan beberapa nilai dalam catatan yang sama, seperti beberapa alamat IP. (Jika Anda memilih kebijakan perutean sederhana untuk catatan alias, Anda hanya dapat menentukan satu AWS sumber daya atau satu catatan di zona yang dihosting saat ini.) Jika Anda menentukan beberapa nilai dalam catatan, Route 53 mengembalikan semua nilai ke resolver rekursif dalam urutan acak, dan resolver mengembalikan nilai ke klien (seperti perambabn web) yang mengirimkan kueri DNS. Klien kemudian memilih nilai dan mengirim ulang kueri. Dengan kebijakan routing sederhana, meskipun Anda dapat menentukan beberapa alamat IP, alamat IP ini tidak diperiksa kesehatan.
Untuk informasi tentang nilai yang Anda tentukan saat menggunakan kebijakan perutean sederhana untuk membuat rekaman, lihat topik berikut ini:
+ [Nilai khusus untuk catatan sederhana](resource-record-sets-values-basic.md)
+ [Nilai khusus untuk catatan alias sederhana](resource-record-sets-values-alias.md)
+ [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md)
+ [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md)
# Perutean failover
Perutean failover memungkinkan Anda merutekan lalu lintas ke sumber daya saat sumber daya sehat atau ke sumber daya lain saat sumber daya pertama tidak sehat. Catatan primer dan sekunder dapat merutekan lalu lintas ke apa pun dari bucket Amazon S3 yang dikonfigurasi sebagai situs web ke pohon catatan yang kompleks. Untuk informasi selengkapnya, lihat [Failover active-passive](dns-failover-types.md#dns-failover-types-active-passive).
Anda dapat menggunakan kebijakan perutean failover untuk catatan di zona host pribadi.
Untuk informasi tentang nilai yang Anda tentukan saat menggunakan kebijakan perutean failover untuk membuat catatan, lihat topik berikut ini:
+ [Nilai khusus untuk catatan failover](resource-record-sets-values-failover.md)
+ [Nilai khusus untuk catatan alias failover](resource-record-sets-values-failover-alias.md)
+ [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md)
+ [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md)
# Perutean geolokasi
Perutean geolokasi memungkinkan Anda memilih sumber daya yang melayani lalu lintas Anda berdasarkan lokasi geografis pengguna Anda, yang berarti lokasi asal kueri DNS. Misalnya, Anda mungkin ingin semua kueri dari Eropa dialihkan ke penyeimbang beban Elastic Load Balancing di Wilayah Frankfurt.
Saat Anda menggunakan perutean geolokasi, Anda dapat melokalkan konten Anda dan menyajikan beberapa atau semua situs web Anda dalam bahasa pengguna Anda. Anda juga dapat menggunakan perutean geolokasi untuk membatasi distribusi konten hanya ke lokasi di mana Anda memiliki hak distribusi. Penggunaan lain yang mungkin adalah untuk menyeimbangkan beban di seluruh titik akhir dengan easy-to-manage cara yang dapat diprediksi, sehingga setiap lokasi pengguna secara konsisten diarahkan ke titik akhir yang sama.
Anda dapat menentukan lokasi geografis menurut benua, negara, atau negara bagian di Amerika Serikat. Jika Anda membuat catatan terpisah untuk wilayah geografis yang tumpang tindih—misalnya, satu rekaman untuk Amerika Utara dan satu untuk Kanada—prioritas masuk ke wilayah geografis terkecil. Ini memungkinkan Anda untuk merutekan beberapa kueri untuk suatu benua ke satu sumber daya dan untuk merutekan kueri untuk negara yang dipilih di benua itu ke sumber daya yang berbeda. (Untuk daftar negara di setiap benua, lihat [Lokasi](resource-record-sets-values-geo.md#rrsets-values-geo-location).)
Geolokasi berfungsi dengan memetakan alamat IP ke lokasi. Namun, beberapa alamat IP tidak dipetakan ke lokasi geografis, jadi meskipun Anda membuat catatan geolokasi yang mencakup ketujuh benua, Amazon Route 53 akan menerima beberapa kueri DNS dari lokasi yang tidak dapat diidentifikasi. Anda dapat membuat catatan default yang menangani kedua kueri dari alamat IP yang tidak dipetakan ke lokasi mana pun dan kueri yang berasal dari lokasi yang data geolokasinya belum Anda buat. Jika Anda tidak membuat catatan default, Route 53 menghasilkan respons "tidak ada jawaban" untuk kueri dari lokasi tersebut.
Anda dapat menggunakan perutean geolokasi untuk catatan di zona host publik dan pribadi.
Untuk informasi selengkapnya, lihat [Bagaimana Amazon Route 53 digunakan EDNS0 untuk memperkirakan lokasi pengguna](routing-policy-edns0.md).
Untuk informasi tentang nilai yang Anda tentukan saat menggunakan kebijakan perutean geolokasi untuk membuat catatan, lihat topik berikut ini:
+ [Nilai khusus untuk catatan geolokasi](resource-record-sets-values-geo.md)
+ [Nilai khusus untuk catatan alias geolokasi](resource-record-sets-values-geo-alias.md)
+ [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md)
+ [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md)
# Perutean geolokasi di zona host pribadi
Untuk zona yang dihosting pribadi, Route 53 merespons kueri DNS berdasarkan VPC Wilayah AWS tempat kueri tersebut berasal. Untuk daftar Wilayah AWS, lihat [Wilayah dan zona](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) di panduan *pengguna Amazon EC2*.
Jika kueri DNS berasal dari bagian lokal dari jaringan hybrid, itu akan dianggap berasal dari tempat VPC berada. Wilayah AWS
Jika menyertakan pemeriksaan kesehatan, Anda dapat membuat catatan default untuk:
+ Alamat IP yang tidak dipetakan ke lokasi geografis.
+ Kueri DNS yang berasal dari lokasi yang belum Anda buat catatan geolokasi.
Jika catatan geolokasi untuk wilayah kueri DNS tidak sehat, catatan default akan dikembalikan (jika sehat).
Dalam konfigurasi contoh pada gambar berikut, kueri DNS yang berasal dari us-east-1 Wilayah AWS (Virginia) akan dialihkan ke titik akhir 1.1.1.1.
![\[Tangkapan layar yang menunjukkan catatan geolokasi untuk zona host pribadi.\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/geolocation-phz.png)
# Perutean geoproksimitas
Perutean geoproximity memungkinkan Amazon Route 53 merutekan lalu lintas ke sumber daya Anda berdasarkan lokasi geografis pengguna dan sumber daya Anda. Ini mengarahkan lalu lintas ke sumber daya terdekat yang tersedia. *Anda juga dapat memilih untuk mengarahkan lebih banyak lalu lintas atau lebih sedikit lalu lintas ke sumber daya tertentu dengan menentukan nilai, yang dikenal sebagai bias.* Bias memperluas atau mengecilkan ukuran wilayah geografis tempat lalu lintas dirutekan ke sumber daya.
Anda membuat aturan geoproximity untuk sumber daya Anda dan menentukan salah satu nilai berikut untuk setiap aturan:
+ Jika Anda menggunakan AWS sumber daya, tentukan Wilayah AWS atau Grup Zona Lokal tempat Anda membuat sumber daya.
+ Jika Anda menggunakan AWS non-sumber daya, tentukan garis lintang dan bujur sumber daya.
Untuk menggunakan AWS Local Zones, Anda harus mengaktifkannya terlebih dahulu. Untuk informasi selengkapnya, lihat [Memulai Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html) di *Panduan Pengguna AWS Local Zones*.
Untuk mempelajari perbedaan antara Wilayah AWS dan Local Zones, lihat [Wilayah dan Zona](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) di *Panduan Pengguna Amazon EC2*.
Untuk mengubah ukuran wilayah geografis dari mana Route 53 route lalu lintas ke sumber daya, tentukan nilai yang berlaku untuk bias:
+ Untuk memperluas ukuran wilayah geografis tempat Route 53 merutekan lalu lintas ke sumber daya, tentukan bilangan bulat positif dari 1 hingga 99 untuk bias. Route 53 menyusutkan ukuran wilayah yang berdekatan.
+ Untuk menyusutkan ukuran wilayah geografis yang lalu lintasnya dirutekan oleh Route 53 ke sumber daya, tentukan bias negatif -1 sampai -99. Route 53 memperluas ukuran wilayah yang berdekatan.
**catatan**
Kami memperbarui konsol Arus Lalu Lintas untuk Route 53. Selama masa transisi, Anda dapat terus menggunakan konsol lama.
Pilih tab untuk konsol yang Anda gunakan.
+ [Konsol baru](#traffic-flow-geoprox-routing-map-new)
+ [Konsol lama](#traffic-flow-geoprox-routing-map-old)
------
#### [ New console ]
Peta berikut menunjukkan empat Wilayah AWS (nomor 1 sampai 5):
1. AS Barat (Oregon)
1. Eropa (Frankfurt)
1. Asia Pasifik (Tokyo)
1. Africa (Cape Town)
1. Timur Tengah (Bahrain)
**catatan**
Peta hanya tersedia dengan Arus Lalu Lintas.
![\[Peta dunia yang menunjukkan bagaimana lalu lintas diarahkan ketika Anda memiliki catatan geoproximity untuk sumber daya Wilayah AWS di AS Barat (Oregon), Eropa (Frankfurt), Asia Pasifik (Tokyo), Afrika (Cape Town) dan Timur Tengah (Bahrain).\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png)
Peta berikut menunjukkan apa yang terjadi jika Anda menambahkan bias \$125 untuk Wilayah Barat AS (Oregon) (nomor **1** di peta). Lalu lintas diarahkan ke sumber daya di Wilayah itu dari sebagian besar Amerika Utara dan dari seluruh Amerika Selatan daripada sebelumnya.
![\[Peta dunia yang menunjukkan bagaimana lalu lintas dirutekan saat Anda menambahkan bias +25 di Wilayah US East (Northern Virginia).\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png)
Peta berikut menunjukkan apa yang terjadi jika Anda mengubah bias menjadi -25 untuk Wilayah Barat AS (Oregon). **Lalu lintas dialihkan ke sumber daya di Wilayah itu dari bagian yang lebih kecil di Amerika Utara dan Selatan daripada sebelumnya, dan lebih banyak lalu lintas diarahkan ke sumber daya di wilayah yang berdekatan **2**, **3**, dan 4.**
![\[Peta dunia yang menunjukkan bagaimana lalu lintas diarahkan ketika Anda menambahkan bias -25 di Wilayah AS Barat (Oregon).\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png)
------
#### [ Old console ]
Peta berikut menunjukkan empat Wilayah AWS (nomor 1 sampai 4) dan lokasi di Johannesburg, Afrika Selatan yang ditentukan oleh garis lintang dan bujur (5).
**catatan**
Peta hanya tersedia dengan Arus Lalu Lintas.
![\[Peta dunia yang menunjukkan bagaimana lalu lintas diarahkan ketika Anda memiliki catatan geoproximity untuk sumber daya Wilayah AWS di AS Barat (Oregon), AS Timur (Virginia N.), Eropa (Paris), dan Asia Pasifik (Tokyo), dan Anda memiliki catatan untuk AWS non-sumber daya di Johannesburg, Afrika Selatan.\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png)
Peta berikut menunjukkan apa yang terjadi jika Anda menambahkan bias \$125 untuk Wilayah AS Timur (Virginia N.) (nomor **2** di peta). Lalu lintas dialihkan ke sumber daya di Wilayah itu dari sebagian besar Amerika Utara daripada sebelumnya, dan dari seluruh Amerika Selatan.
![\[Peta dunia yang menunjukkan bagaimana lalu lintas dirutekan saat Anda menambahkan bias +25 di Wilayah US East (Northern Virginia).\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png)
Peta berikut menunjukkan apa yang terjadi jika Anda mengubah bias menjadi -25 untuk Wilayah AS Timur (Virginia N.). Lalu lintas dirutekan ke sumber daya di Wilayah itu dari bagian yang lebih kecil di Amerika Utara dan Selatan daripada sebelumnya, dan lebih banyak lalu lintas diarahkan ke sumber daya di wilayah yang berdekatan **1**, **3**, dan **5**.
![\[Peta dunia yang menunjukkan bagaimana lalu lintas diarahkan ketika Anda menambahkan bias -25 di Wilayah AS Timur (Virginia N.).\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png)
------
Efek mengubah bias untuk sumber daya Anda bergantung pada sejumlah faktor, termasuk berikut ini:
+ Jumlah sumber daya yang Anda miliki.
+ Seberapa dekat sumber daya satu sama lain.
+ Jumlah pengguna yang Anda miliki di dekat area perbatasan antar wilayah geografis. Misalnya, Anda memiliki sumber daya di Wilayah AWS AS Timur (Virginia N.) dan AS Barat (Oregon), dan Anda memiliki banyak pengguna di Dallas, Austin, dan San Antonio, Texas, AS. Kota-kota itu kira-kira berjarak sama antara sumber daya Anda, sehingga perubahan kecil dalam bias dapat mengakibatkan perubahan besar dalam lalu lintas dari sumber daya satu Wilayah AWS ke yang lain.
Kami menyarankan Anda mengubah bias secara bertahap untuk mencegah sumber daya Anda yang berlebihan, karena perubahan lalu lintas yang tidak terduga.
Untuk informasi selengkapnya, lihat [Bagaimana Amazon Route 53 digunakan EDNS0 untuk memperkirakan lokasi pengguna](routing-policy-edns0.md).
## Bagaimana Amazon Route 53 menggunakan bias untuk merutekan lalu lintas
Berikut rumus yang digunakan Amazon Route 53 untuk menentukan cara merutekan lalu lintas:
**Bias**
`Biased distance = actual distance * [1 - (bias/100)]`
Ketika nilai bias positif, Route 53 memperlakukan sumber kueri DNS dan sumber daya yang Anda tentukan dalam catatan geoproximity (seperti instance EC2 dalam an Wilayah AWS) seolah-olah mereka lebih dekat daripada yang sebenarnya. Misalnya, anggap Anda memiliki catatan geoproximity berikut:
+ Catatan untuk web server A, yang memiliki bias positif 50
+ Catatan untuk server web B, yang tidak memiliki bias
Saat catatan geoproximity memiliki bias positif sebesar 50, Route 53 membagi dua jarak antara sumber kueri dan sumber daya untuk rekaman tersebut. Kemudian Route 53 menghitung sumber daya mana yang lebih dekat dengan sumber kueri. Misalkan web server A berjarak 150 kilometer dari sumber kueri dan web server B berjarak 100 kilometer dari sumber kueri. Jika tidak ada catatan yang bias, Route 53 akan merutekan kueri ke server web B karena lebih dekat. Namun, karena catatan untuk server web A memiliki bias positif sebesar 50, Route 53 memperlakukan server web A seolah-olah berjarak 75 kilometer dari sumber kueri. Akibatnya, Route 53 merutekan kueri ke server web A.
Berikut perhitungan untuk bias positif 50:
```
Bias = 50
Biased distance = actual distance * [1 - (bias/100)]
Biased distance = 150 kilometers * [1 - (50/100)]
Biased distance = 150 kilometers * (1 - .50)
Biased distance = 150 kilometers * (.50)
Biased distance = 75 kilometers
```
# Perutean berbasis latensi
Jika aplikasi Anda di-host dalam beberapa Wilayah AWS, Anda dapat meningkatkan kinerja untuk pengguna Anda dengan menyajikan permintaan mereka dari Wilayah AWS yang menyediakan latensi terendah.
**catatan**
Data tentang latensi antara pengguna dan sumber daya Anda didasarkan sepenuhnya pada lalu lintas antara pengguna dan pusat data AWS . Jika Anda tidak menggunakan sumber daya dalam file Wilayah AWS, latensi aktual antara pengguna dan sumber daya Anda dapat sangat bervariasi dari data AWS latensi. Ini benar bahkan jika sumber daya Anda terletak di kota yang sama dengan Wilayah AWS.
Untuk menggunakan perutean berbasis latensi, Anda membuat catatan latensi untuk sumber daya Anda dalam beberapa. Wilayah AWS Saat Route 53 menerima kueri DNS untuk domain atau subdomain Anda (example.com atau acme.example.com), Route 53 menentukan untuk mana Wilayah AWS Anda telah membuat catatan latensi, menentukan Wilayah mana yang memberikan latensi terendah kepada pengguna, dan kemudian memilih catatan latensi untuk Wilayah tersebut. Route 53 merespons dengan nilai dari catatan yang dipilih, seperti alamat IP untuk server web.
Misalnya, Anda memiliki penyeimbang beban Elastic Load Balancing di Wilayah AS Barat (Oregon) dan di Wilayah Asia Pasifik (Singapura). Anda membuat catatan latensi untuk setiap penyeimbang beban. Inilah yang terjadi saat pengguna di London memasukkan nama domain Anda di peramban:
1. DNS merutekan kueri ke server nama Route 53.
1. Route 53 mengacu pada datanya tentang latensi antara London dan Wilayah Singapura dan antara London dan Wilayah Oregon.
1. Jika latensi lebih rendah antara Wilayah London dan Oregon, Route 53 merespons kueri dengan alamat IP untuk penyeimbang beban Oregon. Jika latensi lebih rendah antara London dan Wilayah Singapura, Route 53 merespons dengan alamat IP untuk penyeimbang beban Singapura.
Latensi antara host di internet dapat berubah seiring waktu sebagai akibat dari perubahan konektivitas jaringan dan perutean. Perutean berbasis latensi didasarkan pada pengukuran latensi yang dilakukan selama periode waktu tertentu, dan pengukuran mencerminkan perubahan ini. Permintaan yang dialihkan ke Wilayah Oregon minggu ini mungkin akan dialihkan ke Wilayah Singapura minggu depan.
**catatan**
Ketika browser atau penampil lain menggunakan DNS resolver yang mendukung edns-client-subnet ekstensi EDNS0, DNS resolver mengirimkan Route 53 versi terpotong dari alamat IP pengguna. Jika Anda mengonfigurasi perutean berbasis latensi, Route 53 mempertimbangkan nilai ini saat merutekan lalu lintas ke sumber daya Anda. Untuk informasi selengkapnya, lihat [Bagaimana Amazon Route 53 digunakan EDNS0 untuk memperkirakan lokasi pengguna](routing-policy-edns0.md).
Anda dapat menggunakan kebijakan perutean latensi untuk catatan di zona host pribadi.
Untuk informasi tentang nilai yang Anda tentukan saat menggunakan kebijakan perutean latensi untuk membuat catatan, lihat topik berikut ini:
+ [Nilai khusus untuk catatan latensi](resource-record-sets-values-latency.md)
+ [Nilai khusus untuk catatan alias latensi](resource-record-sets-values-latency-alias.md)
+ [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md)
+ [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md)
# Perutean berbasis latensi di zona host pribadi
Untuk zona yang dihosting pribadi, Route 53 menjawab kueri DNS dengan titik akhir yang sama Wilayah AWS, atau jaraknya paling dekat dengan VPC Wilayah AWS tempat kueri berasal.
**catatan**
Jika Anda memiliki titik akhir keluar yang diteruskan ke titik akhir masuk, catatan akan diselesaikan berdasarkan di mana titik akhir masuk berada, bukan titik akhir keluar.
Jika Anda menyertakan pemeriksaan kesehatan, dan catatan dengan latensi terendah ke asal kueri tidak sehat, titik akhir yang sehat dengan latensi terendah berikutnya akan dikembalikan.
Dalam konfigurasi contoh pada gambar berikut, kueri DNS yang berasal dari us-east-1, atau yang paling dekat dengannya Wilayah AWS, akan dirutekan ke titik akhir 1.1.1.1. Kueri DNS dari us-west-2, atau yang paling dekat dengannya, akan dirutekan ke titik akhir 2.2.2.2.
![\[Tangkapan layar yang menunjukkan dua catatan latensi untuk zona host pribadi.\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/latency-phz.png)
# Perutean berbasis IP
Dengan perutean berbasis IP di Amazon Route 53, Anda dapat menyempurnakan perutean DNS Anda dengan menggunakan pemahaman Anda tentang jaringan, aplikasi, dan klien Anda untuk membuat keputusan perutean DNS terbaik bagi pengguna akhir Anda. Perutean berbasis IP memberi Anda kontrol granular untuk mengoptimalkan kinerja atau mengurangi biaya jaringan dengan mengunggah data Anda ke Route 53 dalam bentuk pemetaan. user-IP-to-endpoint
Perutean berbasis geolokasi dan latensi didasarkan pada data yang dikumpulkan dan diperbarui oleh Route 53. Pendekatan ini bekerja dengan baik untuk sebagian besar pelanggan, tetapi perutean berbasis IP menawarkan Anda kemampuan tambahan untuk mengoptimalkan perutean berdasarkan pengetahuan khusus tentang basis pelanggan Anda. Misalnya, penyedia konten video global mungkin ingin merutekan pengguna akhir dari penyedia layanan internet (ISP) tertentu.
Beberapa kasus penggunaan umum untuk perutean berbasis IP adalah sebagai berikut:
+ Anda ingin merutekan pengguna akhir dari titik akhir tertentu ISPs ke titik akhir tertentu sehingga Anda dapat mengoptimalkan biaya atau kinerja transit jaringan.
+ Anda ingin menambahkan penggantian ke jenis perutean Route 53 yang ada, seperti perutean geolokasi, berdasarkan pengetahuan Anda tentang lokasi fisik klien Anda.
**Mengelola rentang IP dan mengaitkannya ke kumpulan catatan sumber daya () RRSet**
Untuk IPv4, Anda dapat menggunakan blok CIDR dengan panjang antara 1 dan 24 bit, inklusif, sedangkan untukIPv6, Anda dapat menggunakan blok CIDR dengan panjang antara 1 dan 48 bit, inklusif. Untuk menentukan blok CIDR nol bit (0.0.0.0/0 atau: :/0), gunakan lokasi default (“\$1”).
Untuk kueri DNS dengan CIDR yang lebih panjang dari yang ditentukan dalam koleksi CIDR, Route 53 akan mencocokkannya dengan CIDR yang lebih pendek. Misalnya, jika Anda menentukan 2001:0DB8: :/32 sebagai blok CIDR dalam koleksi CIDR Anda dan kueri berasal dari 2001:0DB8: 0000:1234: :/48, itu akan cocok. Jika, di sisi lain, Anda menentukan 2001:0DB8: 0000:1234: :/48 dalam koleksi CIDR Anda dan kueri berasal dari 2001:0DB8: :/32, ini tidak akan cocok dan Route 53 akan menjawab dengan catatan untuk lokasi default (“\$1”).
Anda dapat mengelompokkan kumpulan blok CIDR (atau rentang IP) ke dalam lokasi CIDR, yang pada gilirannya dikelompokkan ke dalam entitas yang dapat digunakan kembali yang disebut koleksi CIDR:
**Blok CIDR**
Rentang IP dalam notasi CIDR, misalnya, 192.0.2.0/24 atau 2001:: :/32. DB8
**Lokasi CIDR**
Daftar bernama blok CIDR. Misalnya, example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001:: :/32]. DB8 Blok dalam daftar lokasi CIDR tidak harus berdekatan atau rentang yang sama.
Satu lokasi dapat memiliki keduanya IPv4 dan IPv6 blok, dan lokasi ini dapat dikaitkan dengan set rekor A dan AAAA, masing-masing.
Nama lokasi sering merupakan lokasi berdasarkan konvensi, tetapi dapat berupa string apa pun, misalnya, *Perusahaan-A*.
**Koleksi CIDR**
Koleksi lokasi bernama. Misalnya, mycollection = [example-isp-seattle, example-isp-tokyo].
Set catatan sumber daya perutean berbasis IP mereferensikan lokasi dalam sebuah koleksi, dan semua set catatan sumber daya untuk nama dan tipe set catatan yang sama harus mereferensikan koleksi yang sama. Misalnya, jika Anda membuat situs web di dua Wilayah dan ingin mengarahkan kueri DNS dari dua lokasi CIDR yang berbeda ke situs web tertentu berdasarkan alamat IP asal, maka kedua lokasi tersebut harus terdaftar dalam koleksi CIDR yang sama.
Anda tidak dapat menggunakan kebijakan perutean berbasis IP untuk catatan di zona host pribadi.
Untuk informasi tentang nilai yang Anda tentukan saat menggunakan kebijakan perutean berbasis IP untuk membuat catatan, lihat topik berikut:
+ [Nilai khusus untuk catatan berbasis IP](resource-record-sets-values-ipbased.md)
+ [Nilai khusus untuk catatan alias berbasis IP](resource-record-sets-values-ipbased-alias.md)
+ [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md)
+ [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md)
**Topics**
+ [Membuat koleksi CIDR dengan lokasi dan blok CIDR](resource-record-sets-creating-cidr-collection.md)
+ [Bekerja dengan lokasi dan blok CIDR](resource-record-sets-working-with-cidr-locations.md)
+ [Menghapus koleksi CIDR](resource-record-sets-delete-cidr-collection.md)
+ [Memindahkan geolokasi ke perutean berbasis IP](resource-record-sets-move-geolocation-to-cidr.md)
# Membuat koleksi CIDR dengan lokasi dan blok CIDR
Untuk memulai, buat koleksi CIDR dan tambahkan blok dan lokasi CIDR ke dalamnya.
**Untuk membuat koleksi CIDR menggunakan konsol Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. **Di panel navigasi, pilih **perutean berbasis IP**, lalu koleksi CIDR.**
1. Pilih **Buat koleksi CIDR**.
1. Di panel **Buat koleksi CIDR**, di bawah **Detail**, masukkan nama untuk koleksi.
1. Pilih **Buat koleksi** untuk membuat koleksi kosong.
- atau -
Di bagian **Buat lokasi CIDR**, masukkan nama untuk lokasi CIDR di kotak lokasi **CIDR.** Nama lokasi dapat berupa string pengidentifikasi, misalnya**company 1**, atau**Seattle**. Tidak harus menjadi lokasi geografis yang sebenarnya.
**penting**
Nama lokasi CIDR memiliki panjang maksimum 16 karakter.
Masukkan blok CIDR di kotak **blok CIDR** satu per baris. Ini bisa berupa IPv4 atau IPv6 alamat mulai dari /0 hingga /24 untuk IPv4 dan /0 hingga /48 untuk. IPv6
1. Setelah Anda memasukkan blok CIDR, pilih **Buat koleksi CIDR**, atau **Tambahkan lokasi lain untuk tetap memasukkan lokasi** dan blok CIDR. Anda dapat memasukkan beberapa lokasi CIDR per koleksi.
1. Setelah Anda memasukkan lokasi CIDR, pilih **Buat koleksi CIDR.**
# Bekerja dengan lokasi dan blok CIDR
**Untuk bekerja dengan lokasi CIDR dengan menggunakan konsol Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. **Di panel navigasi, pilih **perutean berbasis IP**, **koleksi CIDR** dan kemudian, di bagian **koleksi CIDR**, klik tautan ke koleksi CIDR di daftar nama Koleksi.**
Pada halaman **lokasi CIDR**, Anda dapat membuat lokasi CIDR, menghapusnya, atau mengedit lokasi dan bloknya.
+ Untuk membuat lokasi, pilih **Buat lokasi CIDR.**
+ **Di panel **Buat lokasi CIDR**, masukkan nama untuk lokasi, blok CIDR yang terkait dengan lokasi, lalu pilih Buat.**
+ Untuk melihat lokasi CIDR dan blok di dalamnya, pilih tombol radio di sebelah lokasi untuk menampilkan nama dan blok CIDR di panel lokasi.
Di panel ini, Anda juga dapat memilih **Edit** untuk memperbarui nama lokasi atau blok CIDR-nya. Pilih **Simpan** setelah Anda selesai mengedit.
+ Untuk menghapus lokasi CIDR dan blok di dalamnya, pilih tombol radio di sebelah lokasi yang ingin Anda hapus, lalu pilih **Hapus**. Untuk mengonfirmasi penghapusan, masukkan nama lokasi di bidang input teks dan pilih **Hapus** lagi.
**penting**
Menghapus lokasi CIDR tidak dapat dibatalkan. Jika Anda memiliki catatan DNS yang terkait dengan lokasi, domain Anda mungkin tidak dapat dijangkau.
# Menghapus koleksi CIDR
**Untuk menghapus koleksi CIDR, lokasinya, dan bloknya dengan menggunakan konsol Route 53**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. **Di panel navigasi, pilih **perutean berbasis IP** dan kemudian koleksi CIDR.**
1. Di bagian **koleksi CIDR**, klik nama yang ditautkan dari koleksi yang ingin Anda hapus.
1. Pada halaman **lokasi CIDR**, pilih setiap lokasi satu per satu, pilih **Hapus**, masukkan namanya di kotak dialog, lalu pilih **Hapus**. Anda harus menghapus setiap lokasi yang terkait dengan koleksi CIDR sebelum Anda dapat menghapus koleksi.
1. **Setelah penghapusan setiap lokasi CIDR selesai, pada halaman **lokasi CIDR**, pilih tombol radio di sebelah koleksi yang ingin Anda hapus, lalu pilih Hapus.**
# Memindahkan geolokasi ke perutean berbasis IP
Jika Anda menggunakan kebijakan perutean geolokasi atau geoproximity, dan Anda secara konsisten melihat klien tertentu dirutekan ke titik akhir yang tidak optimal berdasarkan lokasi fisik atau topologi jaringan mereka, Anda dapat menargetkan rentang IP publik klien ini dengan lebih baik dengan menggunakan IP berbasis routing.
Tabel berikut berisi contoh konfigurasi geolokasi untuk perutean geolokasi yang ada yang akan kami sempurnakan untuk rentang IP California.
| Rekam nama set | Kebijakan dan asal perutean | Alamat IP dari titik akhir aplikasi |
| --- | --- | --- |
| contoh.com | Geolokasi-routing (AS) | `198.51.100.1` |
| contoh.com | Perutean geolokasi (UE) | `198.51.100.2` |
Untuk mengganti rentang IP dari California untuk pergi ke titik akhir aplikasi baru, pertama-tama buat ulang perutean geolokasi di bawah nama set catatan baru.
| Rekam nama set | Kebijakan dan asal perutean | Alamat IP dari titik akhir aplikasi |
| --- | --- | --- |
| geo.example.com | Geolokasi-routing (AS) | `198.51.100.1` |
| geo.example.com | Perutean geoloaction (UE) | `198.51.100.2` |
Kemudian, buat catatan perutean berbasis IP dan catatan default yang menunjuk ke kumpulan rekaman perutean geolokasi yang baru saja dibuat ulang.
| Rekam nama set | Kebijakan dan asal perutean | Alamat IP dari titik akhir aplikasi |
| --- | --- | --- |
| contoh.com | Perutean berbasis IP (default) | Alias merekam ke titik akhir aplikasi geo.example.com yang ingin Anda jadikan default. Misalnya, `198.51.100.1`. |
| contoh.com | Perutean berbasis IP (rentang IP California) | `198.51.100.3` |
# Perutean jawaban multinilai
Perutean jawaban multinilai memungkinkan Anda mengonfigurasi Amazon Route 53 untuk mengembalikan beberapa nilai, seperti alamat IP untuk server web Anda, sebagai respons terhadap kueri DNS. Anda dapat menentukan beberapa nilai untuk hampir semua catatan, tetapi perutean jawaban multinilai juga memungkinkan Anda memeriksa kondisi setiap sumber daya, jadi Route 53 hanya mengembalikan nilai untuk sumber daya yang sehat. Ini bukan pengganti penyeimbang beban, tetapi kemampuan untuk mengembalikan beberapa alamat IP yang dapat diperiksa kondisinya adalah cara menggunakan DNS untuk meningkatkan ketersediaan dan penyeimbangan beban.
Untuk merutekan lalu lintas secara kira-kira secara acak ke beberapa sumber daya, seperti server web, Anda membuat satu catatan jawaban multinilai untuk setiap sumber daya dan, secara opsional, mengaitkan pemeriksaan kondisi Route 53 dengan setiap catatan. Route 53 merespons kueri DNS dengan hingga delapan catatan yang sehat dan memberikan jawaban yang berbeda untuk DNS resolver yang berbeda. Jika server web menjadi tidak tersedia setelah resolver men-cache respons, perangkat lunak klien dapat mencoba alamat IP lain dalam respons.
Perhatikan hal-hal berikut:
+ Jika Anda mengaitkan pemeriksaan kondisi dengan catatan jawaban multinilai, Route 53 merespons kueri DNS dengan alamat IP yang sesuai hanya saat pemeriksaan kondisi yang baik.
+ Jika Anda tidak mengaitkan pemeriksaan kondisi dengan catatan jawaban multinilai, Route 53 selalu menganggap catatan tersebut sehat.
+ Jika Anda memiliki delapan catatan kondisi baik atau kurang dari itu, maka Route 53 menanggapi semua kueri DNS dengan semua catatan kondisi baik.
+ Saat semua catatan tidak sehat, Route 53 akan merespons kueri DNS dengan hingga delapan catatan yang tidak sehat.
Anda dapat menggunakan kebijakan perutean jawaban multivalue untuk catatan di zona host pribadi.
Untuk informasi tentang nilai yang Anda tentukan saat Anda menggunakan kebijakan perutean jawaban multivalue untuk membuat catatan, lihat dan. [Nilai khusus untuk catatan jawaban multivalue](resource-record-sets-values-multivalue.md) [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md)
# Perutean tertimbang
Perutean tertimbang memungkinkan Anda mengaitkan beberapa sumber daya dengan satu nama domain (example.com) atau nama subdomain (acme.example.com) dan memilih berapa banyak lalu lintas yang diarahkan ke setiap sumber daya. Ini dapat berguna untuk berbagai tujuan, termasuk penyeimbangan beban dan pengujian perangkat lunak versi baru.
Untuk mengonfigurasi perutean berbobot, Anda membuat catatan yang memiliki nama dan jenis yang sama untuk setiap sumber daya Anda. Anda menetapkan setiap catatan bobot relatif yang sesuai dengan berapa banyak lalu lintas yang ingin Anda kirim ke setiap sumber daya. Amazon Route 53 mengirimkan lalu lintas ke sumber daya berdasarkan bobot yang Anda tetapkan ke catatan sebagai proporsi dari total bobot untuk semua catatan dalam grup:
![\[Rumus untuk berapa banyak lalu lintas yang dirutekan ke sumber daya yang diberikan: bobot untuk catatan tertentu/jumlah bobot untuk semua catatan.\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/images/WRR_calculation.png)
Misalnya, jika Anda ingin mengirim sebagian kecil lalu lintas ke satu sumber daya dan sisanya ke sumber daya lain, Anda dapat menentukan bobot 1 dan 255. Sumber daya dengan bobot 1 mendapat 1/256 lalu lintas (1/(1\$1255)), dan sumber daya lainnya mendapat 255/256 (255/(1\$1255)). Anda dapat secara bertahap mengubah keseimbangan dengan mengubah bobot. Jika Anda ingin berhenti mengirim lalu lintas ke sumber daya, Anda dapat mengubah berat untuk catatan tersebut ke 0.
Untuk informasi tentang nilai yang Anda tentukan saat menggunakan kebijakan perutean berbobot untuk membuat catatan, lihat topik berikut ini:
+ [Nilai khusus untuk catatan tertimbang](resource-record-sets-values-weighted.md)
+ [Nilai khusus untuk catatan alias tertimbang](resource-record-sets-values-weighted-alias.md)
+ [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md)
+ [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md)
Anda dapat menggunakan kebijakan perutean tertimbang untuk catatan di zona host pribadi.
## Pemeriksaan kesehatan dan perutean tertimbang
Jika Anda menambahkan pemeriksaan kondisi ke semua catatan dalam grup catatan tertimbang, tetapi Anda memberikan bobot non-nol ke beberapa catatan dan bobot nol untuk catatan lainnya, pemeriksaan kondisi bekerja seperti ketika semua catatan memiliki bobot non-nol dengan pengecualian berikut:
+ Route 53 awalnya hanya mempertimbangkan catatan tertimbang non-nol, jika ada.
+ Jika semua catatan yang memiliki bobot lebih besar dari 0 dalam kondisi tidak sehat, Route 53 mempertimbangkan catatan tertimbang nol.
Tabel berikut merinci perilaku ketika catatan 0-berat mencakup pemeriksaan kesehatan:
| | Rekam 1 | Rekam 2 | Rekam 3 |
| --- |--- |--- |--- |
| Bobot | 1 | 1 | 0 |
| Termasuk pemeriksaan kesehatan? | Ya | Ya | Ya |
| |
| --- |
| Status pemeriksaan kondisi | Tidak sehat | Tidak sehat | Sehat |
| Kueri DNS dijawab? | Tidak | Tidak | Ya |
| |
| --- |
| Status pemeriksaan kondisi | Tidak sehat | Tidak sehat | Tidak sehat |
| Kueri DNS dijawab? | Ya | Ya | Tidak |
| |
| --- |
| Status pemeriksaan kondisi | Tidak sehat | Sehat | Tidak sehat |
| Kueri DNS dijawab? | Tidak | Ya | Tidak |
| |
| --- |
| Status pemeriksaan kondisi | Sehat | Sehat | Tidak sehat |
| Kueri DNS dijawab? | Ya | Ya | Tidak |
| |
| --- |
| Status pemeriksaan kondisi | Sehat | Sehat | Sehat |
| Kueri DNS dijawab? | Ya | Ya | Tidak |
Tabel berikut merinci perilaku ketika catatan 0-berat tidak termasuk pemeriksaan kesehatan:
| | Rekam 1 | Rekam 2 | Rekam 3 |
| --- |--- |--- |--- |
| Bobot | 1 | 1 | 0 |
| Termasuk pemeriksaan kesehatan? | Ya | Ya | Tidak |
| |
| --- |
| Status pemeriksaan kondisi | Sehat | Sehat | N/A |
| Kueri DNS dijawab? | Ya | Ya | Tidak |
| |
| --- |
| Status pemeriksaan kondisi | Tidak sehat | Tidak sehat | N/A |
| Kueri DNS dijawab? | Tidak | Tidak | Ya |
| |
| --- |
| Status pemeriksaan kondisi | Tidak sehat | Sehat | N/A |
| Kueri DNS dijawab? | Tidak | Ya | Tidak |
# Bagaimana Amazon Route 53 digunakan EDNS0 untuk memperkirakan lokasi pengguna
Untuk meningkatkan akurasi perutean geolokasi, geoproximity, berbasis IP, dan latensi, Amazon Route 53 mendukung perpanjangan. edns-client-subnet EDNS0 (EDNS0 menambahkan beberapa ekstensi opsional ke protokol DNS.) Route 53 edns-client-subnet hanya dapat digunakan ketika resolver DNS mendukungnya:
+ Ketika browser atau penampil lain menggunakan resolver DNS yang tidak mendukung edns-client-subnet, Route 53 menggunakan alamat IP sumber dari DNS resolver untuk memperkirakan lokasi pengguna dan merespons kueri geolokasi dengan catatan DNS untuk lokasi resolver.
+ Ketika browser atau penampil lain menggunakan DNS resolver yang mendukung edns-client-subnet, DNS resolver mengirimkan Route 53 versi terpotong dari alamat IP pengguna. Route 53 menentukan lokasi pengguna berdasarkan alamat IP yang terpotong daripada alamat IP sumber dari DNS resolver; ini biasanya memberikan perkiraan lokasi pengguna yang lebih akurat. Route 53 kemudian merespons kueri geolokasi dengan catatan DNS untuk lokasi pengguna.
+ EDNS0 tidak berlaku untuk zona host pribadi. Untuk zona yang dihosting pribadi, Rute 53 menggunakan data dari Resolver VPC di tempat zona host pribadi berada untuk membuat keputusan perutean geolokasi dan latensi. Wilayah AWS
Untuk informasi selengkapnya edns-client-subnet, lihat EDNS Client Subnet RFC, Client Subnet in DNS [Requests](https://www.rfc-editor.org/rfc/rfc7871).
# Memilih antara catatan alias dan nonalias
*Catatan alias* Amazon Route 53 menyediakan ekstensi khusus Route 53 untuk fungsionalitas DNS. Catatan alias memungkinkan Anda merutekan lalu lintas ke AWS sumber daya yang dipilih, termasuk namun tidak terbatas pada, CloudFront distribusi, dan bucket Amazon S3. Mereka juga memungkinkan Anda merutekan lalu lintas dari satu catatan di zona zona yang di-hosting ke catatan lain.
Tidak seperti catatan CNAME, Anda dapat membuat catatan alias di node atas dari namespace DNS, yang juga dikenal sebagai *zone apex*. Misalnya, jika Anda mendaftarkan nama DNS example.com, zone apex-nya adalah example.com. Anda tidak dapat membuat catatan CNAME untuk example.com, tetapi Anda dapat membuat catatan alias untuk example.com yang merutekan lalu lintas ke www.example.com (selama jenis rekaman untuk www.example.com bukan tipe CNAME).
Saat Route 53 menerima kueri DNS untuk catatan alias, Route 53 merespons dengan nilai yang berlaku untuk sumber daya tersebut:
+ **API regional kustom Amazon API Gateway atau API yang dioptimalkan edge** – Route 53 merespons dengan satu atau lebih alamat IP untuk API Anda.
+ **Titik akhir antarmuka Amazon VPC** – Route 53 merespons dengan satu atau lebih alamat IP untuk titik akhir antarmuka Anda.
+ ** CloudFront Distribusi** — Route 53 merespons dengan satu atau lebih alamat IP untuk server CloudFront edge yang dapat melayani konten Anda.
+ **Layanan Pelari Aplikasi** - Route 53 merespons dengan satu atau lebih alamat IP.
+ **Lingkungan Elastic Beanstalk**– Route 53 merespons dengan satu atau lebih alamat IP untuk lingkungan.
+ Penyeimbang **beban Elastic Load Balancing — Route 53 merespons dengan satu atau lebih alamat IP untuk penyeimbang** beban. Ini termasuk Application Load Balancer, Classic Load Balancer dan, Network Load Balancer.
+ ** AWS Global Accelerator Akselerator** — Route 53 merespons dengan alamat IP untuk akselerator.
+ ** OpenSearch Layanan** — Route 53 merespons dengan satu atau beberapa alamat IP untuk domain kustom OpenSearch Layanan.
+ **Bucket Amazon S3 yang dikonfigurasi sebagai situs web statis**- Route 53 merespons dengan satu alamat IP untuk bucket Amazon S3.
+ **Catatan Route 53 lainnya dari jenis yang sama di zona host yang sama** — Route 53 merespons seolah-olah kueri adalah untuk catatan yang direferensikan oleh catatan alias (lihat). [Perbandingan catatan alias dan CNAME](#resource-record-sets-choosing-alias-non-alias-comparison)
+ **AWS AppSync nama domain** — Route 53 merespons dengan satu atau lebih alamat IP untuk titik akhir antarmuka Anda.
Untuk informasi selengkapnya, lihat [Merutekan lalu lintas internet ke sumber daya Anda AWS](routing-to-aws-resources.md).
Saat Anda menggunakan catatan alias untuk merutekan lalu lintas ke AWS sumber daya, Route 53 secara otomatis mengenali perubahan dalam sumber daya. Misalnya, catatan alias untuk example.com menunjuk ke penyeimbang beban Elastic Load Balancing di lb1-1234.us-east-2.elb.amazonaws.com. Jika alamat IP penyeimbang beban berubah, Route 53 secara otomatis mulai merespons permintaan DNS menggunakan alamat IP baru.
Jika catatan alias menunjuk ke AWS sumber daya, Anda tidak dapat mengatur waktu untuk hidup (TTL); Route 53 menggunakan TTL default untuk sumber daya. Jika catatan alias menunjuk ke catatan lain di zona yang di-hosting yang sama, Route 53 menggunakan TTL catatan yang ditunjuk oleh catatan alias. Untuk informasi lebih lanjut tentang nilai TTL saat ini untuk Elastic Load Balancing, buka [Meminta perutean](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#request-routing) di *Panduan Pengguna Elastic Load Balancing* dan cari "ttl".
Untuk informasi tentang membuat catatan menggunakan konsol Route 53, lihat [Membuat catatan dengan menggunakan konsol Amazon Route 53](resource-record-sets-creating.md). Untuk informasi tentang nilai yang Anda tentukan untuk catatan alias, lihat topik yang berlaku di [Nilai yang Anda tentukan saat membuat atau mengedit catatan Amazon Route 53](resource-record-sets-values.md):
+ [Nilai khusus untuk catatan alias sederhana](resource-record-sets-values-alias.md)
+ [Nilai khusus untuk catatan alias tertimbang](resource-record-sets-values-weighted-alias.md)
+ [Nilai khusus untuk catatan alias latensi](resource-record-sets-values-latency-alias.md)
+ [Nilai khusus untuk catatan alias failover](resource-record-sets-values-failover-alias.md)
+ [Nilai khusus untuk catatan alias geolokasi](resource-record-sets-values-geo-alias.md)
+ [Nilai khusus untuk catatan alias geoproximity](resource-record-sets-values-geoprox-alias.md)
+ [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md)
## Perbandingan catatan alias dan CNAME
Catatan alias mirip dengan catatan CNAME, tetapi ada beberapa perbedaan penting. Daftar berikut membandingkan data alias dan data CNAME.
**Sumber daya tempat Anda dapat mengarahkan kueri**
**Catatan Alias**
Catatan alias hanya dapat mengarahkan kueri ke AWS sumber daya yang dipilih, termasuk namun tidak terbatas pada hal berikut:
+ Bucket Amazon S3
+ CloudFront distribusi
+ Catatan lain dalam zona yang di-hosting Route 53 yang sama
Misalnya, Anda dapat membuat catatan alias bernama acme.example.com yang mengalihkan kueri ke bucket Amazon S3 yang juga bernama acme.example.com. Anda juga dapat membuat catatan alias acme.example.com yang mengalihkan kueri ke catatan bernama zenith.example.com di zona yang di-hosting example.com.
**Catatan CNAME**
Data CNAME dapat mengalihkan kueri DNS ke data DNS apa pun. Misalnya, Anda dapat membuat data CNAME yang mengalihkan kueri dari acme.example.com ke zenith.example.com atau ke acme.example.org. Anda tidak perlu menggunakan Route 53 sebagai layanan DNS untuk domain tujuan pengalihan kueri.
**Membuat catatan yang memiliki nama yang sama dengan domain (catatan di zone apex)**
**Catatan Alias**
Di sebagian besar konfigurasi, Anda dapat membuat catatan alias yang memiliki nama yang sama dengan zona yang di-hosting (zone apex). Satu-satunya pengecualian adalah ketika Anda ingin mengalihkan kueri dari zone epex (seperti example.com) ke catatan di zona yang di-hosting yang sama yang memiliki tipe CNAME (seperti zenith.example.com). Catatan alias harus memiliki jenis yang sama dengan catatan yang Anda tuju, dan membuat catatan CNAME untuk Zone Apex tidak didukung bahkan untuk catatan alias.
**Catatan CNAME**
Anda tidak dapat membuat data CNAME yang memiliki nama yang sama dengan zona yang di-hosting (zone apex). Hal ini berlaku baik untuk zona yang di-hosting untuk nama domain (example.com) dan untuk zona yang di-hosting untuk subdomain (zenith.example.com).
**Harga untuk kueri DNS**
**Catatan alias**
Route 53 tidak mengenakan biaya untuk kueri alias ke AWS sumber daya. Untuk informasi lebih lanjut, lihat [Harga Amazon Route 53](https://aws.amazon.com/route53/pricing/).
**Catatan CNAME**
Route 53 biaya untuk kueri CNAME.
Jika Anda membuat catatan CNAME yang mengalihkan ke nama catatan lain di zona yang di-hosting Route 53 (zona yang di-hosting yang sama atau zona yang di-hosting lain), setiap kueri DNS dibebankan sebagai dua kueri:
+ Route 53 merespons kueri DNS pertama dengan nama catatan yang ingin Anda alihkan.
+ Kemudian DNS resolver harus mengirimkan kueri lain untuk dicatat dalam respons pertama untuk mendapatkan informasi tentang ke mana merutekan lalu lintas, misalnya, alamat IP server web.
Jika data CNAME dialihkan ke nama data yang di-hosting dengan layanan DNS lain, Route 53 mengenakan biaya untuk satu kueri. Layanan DNS lainnya mungkin mengenakan biaya untuk kueri kedua.
**Jenis catatan yang ditentukan dalam kueri DNS**
**Catatan Alias**
Route 53 merespons kueri DNS hanya jika nama catatan alias (seperti acme.example.com) dan jenis catatan alias (seperti A atau AAAA) cocok dengan nama dan ketik kueri DNS.
**Catatan CNAME**
Data CNAME mengalihkan kueri DNS untuk nama catatan terlepas dari jenis catatan yang ditentukan dalam kueri DNS, seperti A atau AAAA.
**Cara catatan dicantumkan dalam kueri pencarian atau nslookup**
**Catatan Alias**
Dalam respons terhadap kueri pencarian atau nslookup, catatan alias dicantumkan sebagai tipe catatan yang Anda tentukan saat Anda membuat catatan, seperti A atau AAAA. (Jenis catatan yang Anda tentukan untuk catatan alias bergantung pada sumber daya tujuan rute lalu lintas Anda. Misalnya, untuk merutekan lalu lintas ke bucket S3, Anda menentukan A untuk jenisnya.) Properti alias hanya terlihat di konsol Route 53 atau sebagai respons terhadap permintaan terprogram, seperti perintah CLI AWS . `list-resource-record-sets`
**Catatan CNAME**
Catatan CNAME terdaftar sebagai catatan CNAME sebagai tanggapan atas kueri penggalian atau nslookup.
# Tipe data DNS yang didukung
Amazon Route 53 mendukung jenis catatan DNS yang tercantum di bagian ini. Setiap jenis catatan juga mencakup contoh bagaimana memformat elemen `Value` ketika Anda mengakses Route 53 menggunakan API.
**catatan**
Untuk jenis catatan yang menyertakan nama domain, masukkan nama domain yang sepenuhnya memenuhi syarat, misalnya,*www.example.com*. Titik akhir adalah opsional; Route 53 mengasumsikan bahwa nama domain sepenuhnya memenuhi syarat. Ini berarti bahwa Route 53 memperlakukan*www.example.com*(tanpa titik akhir) dan*www.example.com.* (dengan titik akhir) sebagai identik.
Route 53 menyediakan ekstensi untuk fungsionalitas DNS yang dikenal sebagai catatan alias. Mirip dengan catatan CNAME, catatan alias memungkinkan Anda merutekan lalu lintas ke AWS sumber daya yang dipilih, seperti CloudFront distribusi dan bucket Amazon S3. Untuk informasi selengkapnya, termasuk perbandingan alias dan data CNAME, lihat [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Jenis catatan](#AFormat)
+ [Jenis catatan AAAA](#AAAAFormat)
+ [Jenis catatan CAA](#CAAFormat)
+ [Jenis catatan CNAME](#CNAMEFormat)
+ [Tipe catatan DS](#DSFormat)
+ [Jenis catatan HTTPS](#HTTPSFormat)
+ [Tipe catatan MX](#MXFormat)
+ [Jenis catatan NAPTR](#NAPTRFormat)
+ [Tipe catatan NS](#NSFormat)
+ [Tipe catatan PTR](#PTRFormat)
+ [Jenis catatan SOA](#SOAFormat)
+ [Tipe catatan SPF](#SPFFormat)
+ [Tipe catatan SRV](#SRVFormat)
+ [Jenis catatan SSHFP](#SSHFPFormat)
+ [Jenis catatan SVCB](#SVCBFormat)
+ [Jenis catatan TLSA](#TLSAFormat)
+ [Tipe catatan TXT](#TXTFormat)
## Jenis catatan
Anda menggunakan catatan A untuk merutekan lalu lintas ke sumber daya, seperti server web, menggunakan IPv4 alamat dalam notasi desimal bertitik.
**Contoh untuk konsol Amazon Route 53**
```
192.0.2.1
```
**Contoh untuk API Route 53**
```
192.0.2.1
```
## Jenis catatan AAAA
Anda menggunakan catatan AAAA untuk merutekan lalu lintas ke sumber daya, seperti server web, menggunakan IPv6 alamat dalam format heksadesimal yang dipisahkan titik dua.
**Contoh untuk konsol Amazon Route 53**
```
2001:0db8:85a3:0:0:8a2e:0370:7334
```
**Contoh untuk API Route 53**
```
2001:0db8:85a3:0:0:8a2e:0370:7334
```
## Jenis catatan CAA
Catatan CAA menentukan otoritas sertifikat (CAs) mana yang diizinkan untuk mengeluarkan sertifikat untuk domain atau subdomain. Membuat catatan CAA membantu CAs mencegah kesalahan menerbitkan sertifikat untuk domain Anda. Catatan CAA bukanlah pengganti persyaratan keamanan yang ditentukan oleh otoritas sertifikat Anda, seperti persyaratan untuk memvalidasi bahwa Anda adalah pemilik domain.
Anda dapat menggunakan catatan CAA untuk menentukan hal berikut:
+ Otoritas sertifikat mana (CAs) yang dapat mengeluarkan SSL/TLS sertifikat, jika ada
+ Alamat email atau URL untuk dihubungi saat CA mengeluarkan sertifikat untuk domain atau subdomain
Saat Anda menambahkan catatan CAA ke zona yang di-hosting, Anda menentukan tiga pengaturan yang dipisahkan oleh spasi:
`flags tag "value"`
Perhatikan hal berikut tentang format untuk catatan CAA:
+ Nilai dari `tag` hanya dapat berisi karakter A-Z, a-z, dan 0-9.
+ Selalu lampirkan `value` dalam tanda petik ("").
+ Beberapa CAs mengizinkan atau memerlukan nilai tambahan untuk`value`. Tentukan nilai tambahan sebagai pasangan nama-nilai, dan pisahkan dengan titik koma (;), misalnya:
`0 issue "ca.example.net; account=123456"`
+ Jika CA menerima permintaan sertifikat untuk subdomain (seperti www.example.com) dan jika tidak ada catatan CAA untuk subdomain, CA mengirimkan permintaan DNS untuk catatan CAA untuk domain induk (seperti example.com). Jika ada catatan untuk domain induk dan jika permintaan sertifikat valid, CA mengeluarkan sertifikat untuk subdomain.
+ Kami menyarankan Anda berkonsultasi dengan CA Anda untuk menentukan nilai apa yang harus ditentukan untuk catatan CAA.
+ Anda tidak dapat membuat data CAA dan data CNAME yang memiliki nama yang sama karena DNS tidak mengizinkan penggunaan nama yang sama untuk data CNAME dan jenis data lainnya.
**Topics**
+ [Otorisasi CA untuk mengeluarkan sertifikat untuk domain atau subdomain](#CAAFormat-issue)
+ [Otorisasi CA untuk mengeluarkan sertifikat wildcard untuk domain atau subdomain](#CAAFormat-issue-wild)
+ [Mencegah CA mengeluarkan sertifikat untuk domain atau subdomain](#CAAFormat-prevent-issue)
+ [Minta agar CA mana pun menghubungi Anda jika CA menerima permintaan sertifikat yang tidak valid](#CAAFormat-contact)
+ [Gunakan pengaturan lain yang didukung oleh CA](#CAAFormat-custom-setting)
+ [Contoh](#CAAFormat-examples)
### Otorisasi CA untuk mengeluarkan sertifikat untuk domain atau subdomain
Untuk mengizinkan CA menerbitkan sertifikat untuk domain atau subdomain, buat catatan yang memiliki nama yang sama dengan domain atau subdomain, dan tentukan pengaturan berikut:
+ **bendera** – `0`
+ **tanda** – `issue`
+ **nilai** – kode untuk CA yang Anda otorisasi untuk mengeluarkan sertifikat untuk domain atau subdomain
Misalnya, Anda ingin mengotorisasi ca.example.net untuk mengeluarkan sertifikat untuk example.com. Anda membuat catatan CAA untuk example.com dengan pengaturan berikut:
```
0 issue "ca.example.net"
```
Untuk informasi tentang cara AWS Certificate Manager mengotorisasi penerbitan sertifikat, lihat [Mengonfigurasi catatan CAA](https://docs.aws.amazon.com/acm/latest/userguide/setup-caa.html) di *AWS Certificate Manager Panduan Pengguna*.
### Otorisasi CA untuk mengeluarkan sertifikat wildcard untuk domain atau subdomain
Untuk mengotorisasi CA untuk mengeluarkan sertifikat wildcard untuk domain atau subdomain, buat catatan yang memiliki nama yang sama dengan domain atau subdomain, dan tentukan pengaturan berikut. Sertifikat wildcard berlaku untuk domain atau subdomain dan semua subdomainnya.
+ **bendera** – `0`
+ **tanda** – `issuewild`
+ **nilai** – kode untuk CA yang Anda otorisasi untuk mengeluarkan sertifikat untuk domain atau subdomain, dan subdomainnya
Misalnya, Anda ingin mengotorisasi ca.example.net untuk mengeluarkan sertifikat wildcard untuk example.com, yang berlaku untuk example.com dan semua subdomainnya. Anda membuat catatan CAA untuk example.com dengan pengaturan berikut:
```
0 issuewild "ca.example.net"
```
Saat Anda ingin mengotorisasi CA untuk mengeluarkan sertifikat wildcard untuk domain atau subdomain, buat catatan yang memiliki nama yang sama dengan domain atau subdomain, dan tentukan pengaturan berikut. Sertifikat wildcard berlaku untuk domain atau subdomain dan semua subdomainnya.
### Mencegah CA mengeluarkan sertifikat untuk domain atau subdomain
Untuk mencegah CA mengeluarkan sertifikat untuk domain atau subdomain, membuat catatan yang memiliki nama yang sama sebagai domain atau subdomain, dan menentukan pengaturan berikut:
+ **bendera** – `0`
+ **tanda** – `issue`
+ **Nilai** – `";"`
Misalnya, Anda tidak ingin CA untuk mengeluarkan sertifikat untuk example.com. Anda membuat catatan CAA untuk example.com dengan pengaturan berikut:
`0 issue ";"`
Jika Anda tidak ingin CA mengeluarkan sertifikat untuk example.com atau subdomainnya, buat data CAA untuk example.com dengan pengaturan berikut:
`0 issuewild ";"`
**catatan**
Jika Anda membuat catatan CAA untuk example.com dan menentukan kedua nilai berikut, CA yang menggunakan nilai ca.example.net dapat mengeluarkan sertifikat untuk example.com:
```
0 issue ";"
0 issue "ca.example.net"
```
### Minta agar CA mana pun menghubungi Anda jika CA menerima permintaan sertifikat yang tidak valid
Jika Anda ingin CA yang menerima permintaan sertifikat yang tidak valid untuk menghubungi Anda, tentukan pengaturan berikut:
+ **bendera** – `0`
+ **tanda** – `iodef`
+ **nilai** – URL atau alamat email yang Anda ingin CA beri tahu jika CA menerima permintaan sertifikat yang tidak valid. Gunakan format yang berlaku:
`"mailto:email-address"`
`"http://URL"`
`"https://URL"`
Misalnya, jika Anda ingin CA yang menerima permintaan sertifikat yang tidak valid untuk mengirim email ke admin@example.com, Anda membuat catatan CAA dengan pengaturan berikut:
```
0 iodef "mailto:admin@example.com"
```
### Gunakan pengaturan lain yang didukung oleh CA
Jika CA Anda mendukung fitur yang tidak ditentukan dalam RFC untuk catatan CAA, tentukan pengaturan berikut:
+ **bendera** – 128 (Nilai ini mencegah CA mengeluarkan sertifikat jika CA tidak mendukung fitur yang ditentukan.)
+ **Tanda**— tanda yang Anda otorisasi CA untuk menggunakan
+ **nilai**— nilai yang sesuai dengan nilai tanda
Misalnya, CA Anda mendukung pengiriman pesan teks jika CA menerima permintaan sertifikat yang tidak valid. (Kami tidak mengetahui ada CAs yang mendukung opsi ini.) Pengaturan untuk catatan mungkin sebagai berikut:
```
128 exampletag "15555551212"
```
### Contoh
**Contoh untuk konsol Route 53**
```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```
**Contoh untuk API Route 53**
```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```
## Jenis catatan CNAME
Data CNAME memetakan kueri DNS untuk nama data saat ini, seperti acme.example.com, ke domain lain (example.com atau example.net) atau subdomain (acme.example.com atau zenith.example.org).
**penting**
Protokol DNS tidak mengizinkan Anda membuat catatan CNAME untuk node teratas dari namespace DNS, yang juga dikenal sebagai apex zona. Misalnya, jika Anda mendaftarkan nama DNS example.com, zone apex-nya adalah example.com. Anda tidak dapat membuat data CNAME untuk example.com, tetapi Anda dapat membuat data CNAME untuk www.example.com, newproduct.example.com, dan seterusnya.
Selain itu, jika Anda membuat data CNAME untuk subdomain, Anda tidak dapat membuat data lain untuk subdomain tersebut. Misalnya, jika Anda membuat CNAME untuk www.example.com, Anda tidak dapat membuat catatan lain yang nilai bidang **Name**-nya adalah www.example.com.
Amazon Route 53 juga mendukung catatan alias, yang memungkinkan Anda merutekan kueri ke AWS sumber daya yang dipilih, seperti CloudFront distribusi dan bucket Amazon S3. Alias dalam beberapa hal serupa dengan jenis data CNAME; tetapi, Anda dapat membuat alias untuk zone apex. Untuk informasi selengkapnya, lihat [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md).
**Contoh untuk konsol Route 53**
```
hostname.example.com
```
**Contoh untuk API Route 53**
```
hostname.example.com
```
## Tipe catatan DS
Catatan delegasi penandatangan (DS) merujuk kunci zona untuk zona subdomain yang didelegasikan. Anda dapat membuat data DS saat membuat rantai kepercayaan saat mengonfigurasi penandatanganan DNSSEC. Untuk informasi lebih lanjut tentang konfigurasi DNSSEC di Route 53, lihat [Mengonfigurasi penandatanganan DNSSEC di Amazon Route 53](dns-configuring-dnssec.md).
Tiga nilai pertama adalah angka desimal yang mewakili tanda kunci, algoritma, dan jenis digest. Nilai keempat adalah penyerapan kunci zona. Untuk informasi lebih lanjut tentang format catatan, lihat [RFC 4034](https://www.ietf.org/rfc/rfc4034.txt).
**Contoh untuk konsol Route 53**
```
123 4 5 1234567890abcdef1234567890absdef
```
**Contoh untuk API Route 53**
```
123 4 5 1234567890abcdef1234567890absdef
```
## Jenis catatan HTTPS
Catatan sumber daya HTTPS adalah bentuk catatan DNS Service Binding (SVCB) yang menyediakan informasi konfigurasi yang diperluas, memungkinkan klien untuk terhubung dengan mudah dan aman ke layanan dengan protokol HTTP. Informasi konfigurasi disediakan dalam parameter yang memungkinkan koneksi dalam satu kueri DNS, daripada memerlukan beberapa kueri DNS.
Format untuk catatan sumber daya HTTPS adalah:
`SvcPriority TargetName SvcParams(optional)`
Parameter berikut dijelaskan dalam [RFC 9460,](https://www.rfc-editor.org/rfc/rfc9460.html#section-9.1) bagian 9.1.
**SvcPriority**
Sebuah integer yang mewakili prioritas. 0 prioritas berarti modus alias, dan umumnya ditujukan untuk aliasing di puncak zona. Nilai ini adalah bilangan bulat 0-32767 untuk Route 53 dimana 1-32767 adalah catatan mode layanan. Turunkan prioritas, lebih tinggi preferensi.
**TargetName**
Nama domain dari target alias (untuk mode alias) atau titik akhir alternatif (untuk). ServiceMode
**SvcParams (opsional)**
Daftar yang dipisahkan spasi putih, dengan setiap parameter terdiri dari pasangan Key=Value atau kunci mandiri. Jika ada lebih dari satu nilai, mereka disajikan sebagai daftar yang dipisahkan koma. Berikut ini adalah yang didefinisikanSvcParams:
+ `1:alpn`— Protokol Negosiasi IDs Protokol Lapisan Aplikasi. Defaultnya adalah HTTP/1.1, `h2` HTTP/2 melalui TLS, dan `h3` HTTP/3 (HTTP over QUIC protocol).
+ `2:no-default-alpn`— Default tidak didukung dan Anda harus memberikan `alpn` parameter.
+ `3:port`— titik akhir alternatif, atau port tempat layanan dapat dicapai.
+ `4:ipv4hint`— petunjuk IPv4 alamat.
+ `5:ech`— Klien Terenkripsi Halo.
+ `6:ipv6hint`— petunjuk IPv6 alamat.
+ `7:dohpath`— DNS melalui template HTTPS
+ `8:ohttp`— Layanan ini mengoperasikan target HTTP Oblivious
**Contoh untuk konsol Amazon Route 53 untuk mode alias**
```
0 example.com
```
**Contoh untuk konsol Amazon Route 53 untuk mode layanan**
```
16 example.com alpn="h2,h3" port=808
```
**Contoh untuk Amazon Route 53 API untuk mode alias**
```
0 example.com
```
**Contoh untuk API Route 53 untuk mode layanan**
```
16 example.com alpn="h2,h3" port=808
```
Untuk informasi selengkapnya, lihat [RFC 9460, Service Binding dan Spesifikasi Parameter melalui DNS (SVCB](https://datatracker.ietf.org/doc/html/rfc9460) dan HTTPS Resource Records).
**catatan**
Route 53 tidak mendukung format presentasi kunci yang tidak diketahui sewenang-wenang `keyNNNNN`
## Tipe catatan MX
Data MX menentukan nama server email Anda dan, jika Anda memiliki dua atau lebih server email, urutan prioritasnya. Setiap nilai untuk data MX berisi dua nilai, prioritas dan nama domain.
**Prioritas**
Bilangan bulat yang mewakili prioritas untuk server email. Jika Anda hanya menentukan satu server, prioritasnya dapat berupa bilangan bulat apa pun antara 0 dan 65535. Jika Anda menentukan beberapa server, nilai yang Anda tentukan untuk prioritas menunjukkan server email mana yang Anda inginkan untuk dirutekan ke email pertama, kedua, dan seterusnya. Server dengan nilai prioritas terendah didahulukan. Misalnya, jika Anda memiliki dua server email dan Anda menetapkan nilai 10 dan 20 untuk prioritas, email selalu masuk ke server dengan prioritas 10 kecuali jika tidak tersedia. Jika Anda menentukan nilai 10 dan 10, email dirutekan ke dua server kira-kira sama.
**Nama domain**
Nama domain server email. Tentukan nama (seperti mail.example.com) dari data A atau AAAA. Di bagian [RFC 2181, Klarifikasi ke Spesifikasi DNS, bagian 10.3](https://tools.ietf.org/html/rfc2181) melarang menentukan nama catatan CNAME untuk nilai nama domain. (Ketika RFC menyebutkan "alias", itu berarti catatan CNAME, bukan catatan alias Route 53.)
**Contoh untuk konsol Amazon Route 53**
```
10 mail.example.com
```
**Contoh untuk API Route 53**
```
10 mail.example.com
```
## Jenis catatan NAPTR
Name Authority Pointer (NAPTR) adalah jenis catatan yang digunakan oleh aplikasi Dynamic Delegation Discovery System (DDDS) untuk mengonversi satu nilai ke nilai lain atau mengganti satu nilai dengan nilai lainnya. Misalnya, salah satu penggunaan umum adalah mengubah nomor telepon menjadi SIP URIs.
Elemen `Value` untuk catatan NAPTR terdiri dari enam nilai yang dipisahkan oleh spasi:
**Urutan**
Saat Anda menentukan lebih dari satu catatan, urutan yang Anda inginkan agar aplikasi DDDS mengevaluasi catatan. Nilai yang valid: 0-65535.
**Preferensi**
Saat Anda menentukan dua atau lebih catatan yang memiliki **Urutan** yang sama, preferensi Anda untuk urutan yang dievaluasi dalam catatan tersebut. Misalnya, jika dua catatan memiliki **Urutan** 1, aplikasi DDDS pertama-tama mengevaluasi catatan yang memiliki **Preferensi** lebih rendah. Nilai yang valid: 0-65535.
**Bendera**
Pengaturan yang khusus untuk aplikasi DDDS. Nilai yang saat ini didefinisikan dalam [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt) adalah huruf besar dan huruf kecil **"A"**, **"P"**, **"S"**, dan **"U"**, dan string kosong, **""**. Sertakan **Bendera** dalam tanda petik.
**Layanan**
Pengaturan yang khusus untuk aplikasi DDDS. Sertakan **Layanan** dalam tanda petik.
Untuk informasi lebih lanjut, lihat yang berlaku RFCs:
+ **Aplikasi URI DDDS** — [https://tools.ietf.org/html/rfc3404](https://tools.ietf.org/html/rfc3404#section-4.4) \$1section -4.4
+ **Aplikasi S-NAPTR DDDS** [— /rfc3958 \$1section -6.5 https://tools.ietf.org/html](https://tools.ietf.org/html/rfc3958#section-6.5)
+ **Aplikasi U-NAPTR DDDS** [— /rfc4848 \$1section -4.5 https://tools.ietf.org/html](https://tools.ietf.org/html/rfc4848#section-4.5)
**Regexp**
Ekspresi reguler yang digunakan aplikasi DDDS untuk mengubah nilai input menjadi nilai output. Misalnya, sistem telepon IP mungkin menggunakan ekspresi reguler untuk mengonversi nomor telepon yang dimasukkan oleh pengguna menjadi URI SIP. Sertakan **Regexp** dalam tanda petik. Tentukan baik nilai untuk **Regexp** atau nilai untuk **Pengganti** , tetapi tidak keduanya.
Ekspresi reguler dapat menyertakan salah satu karakter ASCII yang dapat dicetak berikut ini:
+ a-z
+ 0-9
+ - (tanda hubung)
+ (spasi)
+ \$1 \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ ] ^ \$1 ` \$1 \$1 \$1 \$1 .
+ " (tanda kutip). Untuk menyertakan kutipan literal dalam string, awali dengan \$1 karakter: \$1".
+ \$1 (garis miring terbalik). Untuk menyertakan garis miring terbalik dalam string, awali dengan karakter \$1: \$1\$1.
Tentukan semua nilai lainnya, seperti nama domain internasional, dalam format oktal.
Untuk sintaks untuk **Regexp**, lihat [RFC 3402, bagian 3.2, Sintaks Ekspresi Substitusi](https://tools.ietf.org/html/rfc3402#section-3.2)
**Pengganti**
Nama domain yang sepenuhnya memenuhi syarat (FQDN) dari nama domain berikutnya yang Anda inginkan agar aplikasi DDDS mengirimkan permintaan DNS. Aplikasi DDDS menggantikan nilai input dengan nilai yang Anda tentukan untuk **Pengganti**, jika ada. Tentukan baik nilai untuk **Regexp** atau nilai untuk **Pengganti** , tetapi tidak keduanya. Jika Anda menentukan nilai untuk **Regexp**, tentukan titik (**.**) untuk **Penggantian**.
Nama domain dapat menyertakan a-z, 0-9, dan - (tanda hubung).
Untuk informasi selengkapnya tentang aplikasi DDDS dan tentang catatan NAPTR, lihat berikut ini: RFCs
+ [RFC 3401](https://www.ietf.org/rfc/rfc3401.txt)
+ [RFC 3402](https://www.ietf.org/rfc/rfc3402.txt)
+ [RFC 3403](https://www.ietf.org/rfc/rfc3403.txt)
+ [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt)
**Contoh untuk konsol Amazon Route 53**
```
100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
```
**Contoh untuk API Route 53**
```
100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
```
## Tipe catatan NS
Catatan NS mengidentifikasi server nama untuk zona yang di-hosting. Perhatikan hal berikut:
+ Penggunaan paling umum untuk catatan NS adalah untuk mengontrol bagaimana lalu lintas internet dirutekan untuk suatu domain. Untuk menggunakan catatan di zona yang di-hosting untuk merutekan lalu lintas untuk domain, Anda memperbarui pengaturan pendaftaran domain untuk menggunakan empat server nama dalam catatan NS default. (Ini adalah catatan NS yang memiliki nama yang sama dengan zona yang di-hosting.)
+ Anda dapat membuat zona yang di-hosting terpisah untuk subdomain (acme.example.com) dan menggunakan zona yang di-hosting tersebut untuk merutekan lalu lintas internet untuk subdomain dan subdomainnya (subdomain.acme.example.com). Anda menyiapkan konfigurasi ini, yang dikenal sebagai "mendelegasikan tanggung jawab untuk subdomain ke zona yang di-hosting" dengan membuat data NS lain di zona yang di-hosting untuk domain root (example.com). Untuk informasi selengkapnya, lihat [Merutekan lalu lintas untuk subdomain](dns-routing-traffic-for-subdomains.md).
+ Anda juga menggunakan data NS untuk mengonfigurasi server nama label putih. Untuk informasi selengkapnya, lihat [Mengonfigurasi server nama label putih](white-label-name-servers.md).
+ Penggunaan lain untuk catatan NS adalah untuk zona yang dihosting pribadi saat Anda membuat aturan delegasi untuk mendelegasikan otoritas subdomain ke resolver lokal Anda. Anda harus membuat catatan NS ini sebelum Anda membuat aturan delegasi. Untuk informasi selengkapnya, lihat [Bagaimana titik akhir Resolver meneruskan kueri DNS dari Anda ke jaringan Anda VPCs](resolver-overview-forward-vpc-to-network.md).
Untuk informasi lebih lanjut tentang catatan NS, lihat [Catatan NS dan SOA yang dibuat Amazon Route 53 untuk zona yang di-hosting publik](SOA-NSrecords.md).
**Contoh untuk konsol Amazon Route 53**
```
ns-1.example.com
```
**Contoh untuk API Route 53**
```
ns-1.example.com
```
## Tipe catatan PTR
Catatan PTR memetakan alamat IP ke nama domain yang sesuai.
**Contoh untuk konsol Amazon Route 53**
```
hostname.example.com
```
**Contoh untuk API Route 53**
```
hostname.example.com
```
## Jenis catatan SOA
Catatan awal otoritas (SOA) memberikan informasi tentang domain dan zona yang di-hosting Amazon Route 53 yang sesuai. Untuk informasi tentang bidang di catatan SOA, lihat [Catatan NS dan SOA yang dibuat Amazon Route 53 untuk zona yang di-hosting publik](SOA-NSrecords.md).
**Contoh untuk konsol Route 53**
```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```
**Contoh untuk API Route 53**
```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```
## Tipe catatan SPF
Catatan SPF sebelumnya digunakan untuk memverifikasi identitas pengirim pesan email. Namun, kami tidak lagi menyarankan Anda membuat catatan yang jenis catatannya adalah SPF. RFC 7208, *Kerangka Kebijakan Pengirim (SPF) untuk Mengotorisasi Penggunaan Domain di Email, Versi 1, telah diperbarui untuk mengatakan*, “... [I] keberadaan dan mekanisme yang didefinisikan dalam [RFC4408] telah menyebabkan beberapa masalah interoperabilitas. Dengan demikian, penggunaannya tidak lagi sesuai untuk SPF versi 1; implementasi tidak menggunakannya." Di RFC 7208, lihat bagian 14.1, [Jenis Catatan DNS SPF](http://tools.ietf.org/html/rfc7208#section-14.1).
Sebagai ganti data SPF, sebaiknya Anda membuat data TXT yang berisi nilai yang berlaku. Untuk informasi selengkapnya tentang nilai yang valid, lihat artikel Wikipedia [Kerangka Kebijakan Pengirim](https://en.wikipedia.org/wiki/Sender_Policy_Framework).
**Contoh untuk konsol Amazon Route 53**
```
"v=spf1 ip4:192.168.0.1/16 -all"
```
**Contoh untuk API Route 53**
```
"v=spf1 ip4:192.168.0.1/16 -all"
```
## Tipe catatan SRV
Elemen `Value` catatan SRV terdiri dari empat nilai yang dipisahkan oleh spasi. Tiga nilai pertama adalah angka desimal yang mewakili prioritas, bobot, dan port. Nilai keempat adalah nama domain. Catatan SRV digunakan untuk mengakses layanan, seperti layanan untuk email atau komunikasi. Untuk informasi tentang format catatan SRV, lihat dokumentasi untuk layanan yang ingin Anda sambungkan.
**Contoh untuk konsol Amazon Route 53**
```
10 5 80 hostname.example.com
```
**Contoh untuk API Route 53**
```
10 5 80 hostname.example.com
```
## Jenis catatan SSHFP
Catatan sidik jari Secure Shell (SSHFP) mengidentifikasi kunci SSH yang terkait dengan nama domain. Catatan SSHFP harus diamankan dengan DNSSEC agar rantai kepercayaan dapat ditetapkan. Untuk informasi lebih lanjut tentang DNSSEC, lihat [Mengonfigurasi penandatanganan DNSSEC di Amazon Route 53](dns-configuring-dnssec.md)
Format untuk catatan sumber daya SSHFP adalah:
`[Key Algorithm] [Hash Type] Fingerprint`
Parameter berikut didefinisikan dalam [RFC 4255](https://datatracker.ietf.org/doc/html/rfc4255).
**Algoritma Kunci**
Jenis algoritma:
+ `0`— Dicadangkan dan tidak digunakan.
+ `1: RSA`Algoritma Rivest—Shamir—Adleman adalah salah satu kriptosistem kunci publik pertama dan masih digunakan untuk transmisi data yang aman.
+ `2: DSA`Algoritma Tanda Tangan Digital adalah Standar Pemrosesan Informasi Federal untuk tanda tangan digital. DSA didasarkan pada eksponensial modular dan model matematika logaritma diskrit.
+ `3: ECDSA`— Elliptic Curve Digital Signature Algorithm adalah varian dari DSA yang menggunakan kriptografi kurva elips.
+ `4: Ed25519`Algoritma Ed25519 adalah skema tanda tangan eDDSA yang menggunakan SHA-512 (SHA-2) dan Curve25519.
+ `6: Ed448`- Ed448 adalah skema tanda tangan eDDSA yang menggunakan dan Curve448. SHAKE256
**Jenis Hash**
Algoritma yang digunakan untuk membuat hash kunci publik:
+ `0`—Dicadangkan dan tidak digunakan.
+ `1: SHA-1`
+ `2: SHA-256`
**Sidik jari**
Representasi heksadesimal dari hash.
**Contoh untuk konsol Amazon Route 53**
```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```
**Contoh untuk API Route 53**
```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```
Untuk informasi selengkapnya, lihat [RFC 4255: Menggunakan DNS untuk Mempublikasikan Sidik Jari Kunci Secure Shell (](https://datatracker.ietf.org/doc/html/rfc4255)SSH) dengan Aman.
## Jenis catatan SVCB
Anda menggunakan catatan SVCB untuk mengirimkan informasi konfigurasi untuk mengakses titik akhir layanan. SVCB adalah catatan DNS generik dan dapat digunakan untuk menegosiasikan parameter untuk berbagai protokol aplikasi.
Format untuk catatan sumber daya SVCB adalah:
`SvcPriority TargetName SvcParams(optional)`
Parameter berikut dijelaskan dalam [RFC 9460,](https://www.rfc-editor.org/rfc/rfc9460.html#section-2.3) bagian 2.3.
**SvcPriority**
Sebuah integer yang mewakili prioritas. 0 prioritas berarti modus alias, dan umumnya ditujukan untuk aliasing di puncak zona. Turunkan prioritas, lebih tinggi preferensi.
**TargetName**
Nama domain dari target alias (untuk mode alias) atau titik akhir alternatif (untuk). ServiceMode
**SvcParams (opsional)**
Daftar yang dipisahkan spasi putih, dengan setiap parameter terdiri dari pasangan Key=Value atau kunci mandiri. Jika ada lebih dari satu nilai, mereka disajikan sebagai daftar yang dipisahkan koma. Nilai ini adalah bilangan bulat 0-32767 untuk Route 53 dimana 1-32767 adalah catatan mode layanan. Berikut ini adalah yang didefinisikanSvcParams:
+ `1:alpn`— Protokol Negosiasi IDs Protokol Lapisan Aplikasi. Defaultnya adalah HTTP/1.1, `h2` HTTP/2 melalui TLS, dan `h3` HTTP/3 (HTTP over QUIC protocol).
+ `2:no-default-alpn`— Default tidak didukung dan Anda harus memberikan `alpn` parameter.
+ `3:port`— port untuk titik akhir alternatif di mana layanan dapat dicapai.
+ `4:ipv4hint`— petunjuk IPv4 alamat.
+ `5:ech`— Klien Terenkripsi Halo.
+ `6:ipv6hint`— petunjuk IPv6 alamat.
+ `7:dohpath`— DNS melalui template HTTPS
+ `8:ohttp`— Layanan ini mengoperasikan target HTTP Oblivious
**Contoh untuk konsol Amazon Route 53 untuk mode alias**
```
0 example.com
```
**Contoh untuk konsol Amazon Route 53 untuk mode layanan**
```
16 example.com alpn="h2,h3" port=808
```
**Contoh untuk Amazon Route 53 API untuk mode alias**
```
0 example.com
```
**Contoh untuk API Route 53 untuk mode layanan**
```
16 example.com alpn="h2,h3" port=808
```
Untuk informasi selengkapnya, lihat [RFC 9460, Service Binding dan Spesifikasi Parameter melalui DNS (SVCB](https://datatracker.ietf.org/doc/html/rfc9460) dan HTTPS Resource Records).
**catatan**
Route 53 tidak mendukung format presentasi kunci yang tidak diketahui sewenang-wenang `keyNNNNN`
## Jenis catatan TLSA
Anda menggunakan catatan TLSA untuk menggunakan Autentikasi Berbasis DNS dari Entitas Bernama (DANE). Catatan TLSA mengaitkan certificate/public kunci dengan titik akhir Transport Layer Security (TLS), dan klien dapat memvalidasi certificate/public kunci menggunakan catatan TLSA yang ditandatangani dengan DNSSEC.
Catatan TLSA hanya dapat dipercaya jika DNSSEC diaktifkan di domain Anda. Untuk informasi lebih lanjut tentang DNSSEC, lihat [Mengonfigurasi penandatanganan DNSSEC di Amazon Route 53](dns-configuring-dnssec.md)
Format untuk catatan sumber daya TLSA adalah:
`[Certificate usage] Selector [Matching type] [Certificate association data]`
Parameter berikut ditentukan dalam [RFC 6698, bagian](https://datatracker.ietf.org/doc/html/rfc6698#section-3) 3.
**Penggunaan sertifikat**
Menentukan asosiasi yang disediakan yang akan digunakan untuk mencocokkan sertifikat yang disajikan dalam jabat tangan TLS:
+ 0: CA Constraint — Sertifikat atau kunci publik harus ditemukan di jalur sertifikasi Public Key Infrastructure (PKIX) untuk sertifikat entitas akhir yang disediakan oleh server di TLS. Batasan batasan ini yang CAs dapat digunakan untuk menerbitkan sertifikat untuk layanan tertentu.
+ 1: Kendala Sertifikat Layanan - Menentukan sertifikat entitas akhir (atau kunci publik) yang harus sesuai dengan sertifikat entitas akhir yang diberikan oleh server di TLS. Sertifikasi ini membatasi sertifikat entitas akhir mana yang dapat digunakan oleh layanan tertentu pada host.
+ 2: Pernyataan Jangkar kepercayaan - Menentukan sertifikat (atau kunci publik) yang harus digunakan sebagai “jangkar kepercayaan” saat memvalidasi sertifikat entitas akhir yang diberikan oleh server di TLS. Memungkinkan administrator domain untuk menentukan jangkar kepercayaan.
+ 3: Sertifikasi yang Diterbitkan Domain - Menentukan sertifikat (atau kunci publik) yang harus cocok dengan sertifikat entitas akhir yang diberikan oleh server di TLS. Sertifikasi ini memungkinkan administrator domain untuk mengeluarkan sertifikat untuk domain tanpa melibatkan CA pihak ketiga. Sertifikat ini tidak harus lulus validasi PKIX.
**Pemilih**
Menentukan bagian mana dari sertifikat yang disajikan oleh server dalam jabat tangan yang cocok dengan nilai asosiasi:
+ 0: Seluruh sertifikat harus dicocokkan.
+ 1: Kunci Publik Subjek, atau struktur biner yang dikodekan DER, harus dicocokkan.
**Jenis pencocokan**
Menentukan presentasi (sebagaimana ditentukan oleh bidang Selector) dari kecocokan sertifikat:
+ 0: Pencocokan konten yang tepat.
+ 1: SHA-256 hash.
+ 2: SHA-512 hash.
**Data asosiasi sertifikat**
Data yang akan dicocokkan berdasarkan pengaturan bidang lainnya.
**Contoh untuk konsol Amazon Route 53**
```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```
**Contoh untuk API Route 53**
```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```
Untuk informasi selengkapnya, lihat [RFC 6698, Protokol Transport Layer Security (TLS) Transport Layer Security (DANE) Berbasis DNS](https://datatracker.ietf.org/doc/html/rfc6698): TLSA.
## Tipe catatan TXT
Catatan TXT berisi satu atau lebih string yang diapit dengan tanda petik ganda (`"`). Saat Anda menggunakan [kebijakan perutean](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) sederhana, sertakan semua nilai untuk domain (example.com) atau subdomain (www.example.com) dalam data TXT yang sama.
**Topics**
+ [Memasukkan nilai catatan TXT](#TXTformat-limits)
+ [Karakter khusus dalam nilai catatan TXT](#TXTformat-special-characters)
+ [Huruf besar dan huruf kecil dalam nilai catatan TXT](#TXTformat-case)
+ [Contoh](#TXTformat-examples)
### Memasukkan nilai catatan TXT
Satu string dapat berisi hingga 255 karakter, termasuk yang berikut:
+ a-z
+ A-Z
+ 0-9
+ Spasi
+ - (tanda hubung)
+ \$1 " \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ \$1 ] ^ \$1 ` \$1 \$1 \$1 \$1 .
Jika Anda perlu memasukkan nilai yang lebih panjang dari 255 karakter, pisahkan nilai menjadi string 255 karakter atau kurang, dan sertakan setiap string dalam tanda kutip ganda (`"`). Di konsol, cantumkan semua string pada baris yang sama:
```
"String 1" "String 2" "String 3"
```
Untuk API, sertakan semua string dalam elemen `Value` yang sama:
```
"String 1" "String 2" "String 3"
```
Panjang maksimum nilai dalam data TXT adalah 4.000 karakter.
Untuk memasukkan lebih dari satu nilai TXT, masukkan satu nilai per baris.
### Karakter khusus dalam nilai catatan TXT
Jika catatan TXT Anda berisi salah satu karakter berikut, Anda harus menentukan karakter dengan menggunakan kode escape dalam format: `\` *three-digit octal code*
+ Karakter 000 hingga 040 oktal (0 hingga 32 desimal, 0x00 hingga 0x20 heksadesimal)
+ Karakter 177 hingga 377 oktal (127 hingga 255 desimal, 0x7F hingga 0xFF heksadesimal)
Misalnya, jika nilai data TXT Anda adalah `"exämple.com"`, Anda menentukan `"ex\344mple.com"`.
Untuk pemetaan antara karakter ASCII dan kode oktal, lakukan pencarian internet untuk “kode oktal ASCII.” Satu referensi yang berguna adalah [Kode ASCII - Tabel ASCII yang diperluas](https://www.ascii-code.com/).
Untuk menyertakan tanda kutip (`"`) dalam sebuah string, letakkan karakter garis miring terbalik (`\`) sebelum tanda kutip: `\"`.
### Huruf besar dan huruf kecil dalam nilai catatan TXT
Kasus dipertahankan, sehingga `"Ab"` dan `"aB"` adalah nilai-nilai yang berbeda.
### Contoh
**Contoh untuk konsol Amazon Route 53**
Letakkan setiap nilai pada baris terpisah:
```
"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"
```
**Contoh untuk API Route 53**
Letakkan setiap nilai dalam elemen `Value` terpisah:
```
"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"
```
# Membuat catatan dengan menggunakan konsol Amazon Route 53
Prosedur berikut menjelaskan cara membuat catatan menggunakan konsol Amazon Route 53. Untuk informasi tentang cara membuat rekaman menggunakan API Route 53, lihat [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)di *Referensi API Amazon Route 53*.
**catatan**
Untuk membuat catatan untuk konfigurasi perutean yang kompleks, Anda juga dapat menggunakan editor visual Aliran Lalu Lintas dan menyimpan konfigurasi sebagai kebijakan lalu lintas. Anda kemudian dapat mengaitkan kebijakan lalu lintas dengan satu atau lebih nama domain (seperti example.com) atau nama subdomain (seperti www.example.com), di zona yang di-hosting yang sama atau di beberapa zona yang di-hosting. Selain itu, Anda dapat memulihkan pembaruan jika konfigurasi baru tidak memiliki performa seperti yang Anda harapkan. Untuk informasi selengkapnya, lihat [Menggunakan Arus Lalu Lintas untuk merutekan lalu lintas DNS](traffic-flow.md).
**Untuk membuat catatan menggunakan konsol Route 53**
1. Jika Anda tidak membuat catatan alias, lanjutkan ke langkah 2.
Juga pergi ke langkah 2 jika Anda membuat catatan alias yang merutekan lalu lintas DNS ke AWS sumber daya selain penyeimbang beban Elastic Load Balancing atau catatan Route 53 lainnya.
Jika Anda membuat catatan alias yang merutekan lalu lintas ke penyeimbang beban Elastic Load Balancing, dan jika Anda membuat zona yang dihosting dan penyeimbang beban menggunakan akun yang berbeda, lakukan [Mendapatkan nama DNS untuk penyeimbang beban Elastic Load Balancing](#resource-record-sets-elb-dns-name-procedure) prosedur untuk mendapatkan nama DNS untuk penyeimbang beban.
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pada panel navigasi, pilih **Zona yang di-hosting**.
1. Jika Anda sudah memiliki zona yang di-hosting untuk domain Anda, lewati ke langkah 5. Jika belum, lakukan prosedur yang berlaku untuk membuat zona yang di-hosting:
+ Untuk merutekan lalu lintas internet ke sumber daya Anda, seperti bucket Amazon S3 atau instans Amazon EC2, lihat [Membuat zona yang di-hosting publik](CreatingHostedZone.md).
+ Untuk merutekan lalu lintas di VPC Anda, lihat [Membuat zona yang di-hosting privat](hosted-zone-private-creating.md).
1. Pada halaman **Zona yang di-hosting**, pilih nama zona yang dihosting tempat Anda ingin membuat catatan.
1. Pilih **Buat catatan**.
1. Pilih dan tentukan kebijakan dan nilai perutean yang berlaku. Untuk informasi selengkapnya, lihat topik untuk jenis catatan yang ingin Anda buat:
+ [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md)
+ [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md)
+ [Nilai khusus untuk catatan sederhana](resource-record-sets-values-basic.md)
+ [Nilai khusus untuk catatan alias sederhana](resource-record-sets-values-alias.md)
+ [Nilai khusus untuk catatan failover](resource-record-sets-values-failover.md)
+ [Nilai khusus untuk catatan alias failover](resource-record-sets-values-failover-alias.md)
+ [Nilai khusus untuk catatan geolokasi](resource-record-sets-values-geo.md)
+ [Nilai khusus untuk catatan alias geolokasi](resource-record-sets-values-geo-alias.md)
+ [Nilai khusus untuk catatan geoproximity](resource-record-sets-values-geoprox.md)
+ [Nilai khusus untuk catatan alias geoproximity](resource-record-sets-values-geoprox-alias.md)
+ [Nilai khusus untuk catatan latensi](resource-record-sets-values-latency.md)
+ [Nilai khusus untuk catatan alias latensi](resource-record-sets-values-latency-alias.md)
+ [Nilai khusus untuk catatan berbasis IP](resource-record-sets-values-ipbased.md)
+ [Nilai khusus untuk catatan alias berbasis IP](resource-record-sets-values-ipbased-alias.md)
+ [Nilai khusus untuk catatan jawaban multivalue](resource-record-sets-values-multivalue.md)
+ [Nilai khusus untuk catatan tertimbang](resource-record-sets-values-weighted.md)
+ [Nilai khusus untuk catatan alias tertimbang](resource-record-sets-values-weighted-alias.md)
1. Pilih **Create records** (Buat catatan).
**catatan**
Catatan baru Anda membutuhkan waktu untuk menyebar ke server DNS Route 53. Saat ini, satu-satunya cara untuk memverifikasi bahwa perubahan telah disebarkan adalah dengan menggunakan tindakan [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. Perubahan umumnya menyebar ke semua server nama Route 53 dalam waktu 60 detik.
1. Jika Anda membuat beberapa catatan, ulangi langkah 7 hingga 8.
**Mendapatkan nama DNS untuk penyeimbang beban Elastic Load Balancing**
1. Masuk ke akun Konsol Manajemen AWS menggunakan AWS akun yang digunakan untuk membuat Classic, Application, atau Network Load Balancer yang ingin Anda buat catatan alias.
1. Buka konsol Amazon EC2 di. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Di panel navigasi, pilih **Load Balancers**.
1. Dalam daftar penyeimbang beban, pilih penyeimbang beban yang ingin Anda buatkan data aliasnya.
1. Pada tab **Deskripsi**, dapatkan nilai **Nama DNS**.
1. Jika Anda ingin membuat catatan alias untuk penyeimbang beban Elastic Load Balancing lainnya, ulangi langkah 4 dan 5.
1. Keluar dari Konsol Manajemen AWS.
1. Masuk ke akun Konsol Manajemen AWS lagi menggunakan AWS akun yang Anda gunakan untuk membuat zona yang dihosting Route 53.
1. Kembali ke langkah 3 prosedur untuk [Membuat catatan dengan menggunakan konsol Amazon Route 53](#resource-record-sets-creating).
# Izin set catatan sumber daya
Izin kumpulan catatan sumber daya menggunakan kondisi kebijakan Manajemen Identitas dan Akses (IAM) untuk memungkinkan Anda menetapkan izin terperinci untuk tindakan di konsol Route 53 atau untuk menggunakan API. [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)
Kumpulan catatan sumber daya didefinisikan sebagai beberapa catatan sumber daya dengan nama dan jenis yang sama (dan kelas, tetapi untuk sebagian besar tujuan kelas selalu IN, atau internet), tetapi berisi data yang berbeda. Misalnya, jika Anda memilih perutean geolokasi, Anda dapat memiliki beberapa catatan A atau AAAA yang menunjuk ke titik akhir yang berbeda untuk domain yang sama. Semua catatan A atau AAAA ini bergabung untuk membentuk kumpulan catatan sumber daya. Untuk informasi lebih lanjut tentang terminologi DNS, lihat [RFC](https://datatracker.ietf.org/doc/html/rfc7719) 7719.
Dengan ketentuan kebijakan IAM,,`route53:ChangeResourceRecordSetsNormalizedRecordNames`, dan `route53:ChangeResourceRecordSetsRecordTypes``route53:ChangeResourceRecordSetsActions`, Anda dapat memberikan hak administratif terperinci kepada AWS pengguna lain di akun lain AWS mana pun. Ini memungkinkan Anda memberikan izin kepada seseorang untuk:
+ Satu set catatan sumber daya.
+ Semua kumpulan catatan sumber daya dari jenis catatan DNS tertentu.
+ Rekaman sumber daya menetapkan di mana nama berisi string tertentu.
+ Lakukan salah satu, atau semua `CREATE | UPSERT | DELETE ` tindakan saat menggunakan [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)API, atau konsol Route 53.
Anda juga dapat membuat izin akses yang menggabungkan salah satu kondisi kebijakan Route 53. Misalnya, Anda dapat memberikan izin kepada seseorang untuk mengubah data catatan A untuk pemasaran-example.com, tetapi tidak mengizinkan pengguna tersebut untuk menghapus catatan apa pun.
Untuk informasi selengkapnya tentang izin kumpulan catatan sumber daya dan contoh cara menggunakannya, lihat[Menggunakan ketentuan kebijakan IAM untuk kontrol akses terperinci](specifying-conditions-route53.md).
Untuk mempelajari cara mengautentikasi AWS pengguna, lihat [Mengautentikasi dengan identitas](security-iam.md#security_iam_authentication) dan mempelajari cara mengontrol akses ke sumber daya Route 53, lihat[Kontrol akses](security-iam.md#access-control).
# Nilai yang Anda tentukan saat membuat atau mengedit catatan Amazon Route 53
Saat Anda membuat rekaman menggunakan konsol Amazon Route 53, nilai yang Anda tentukan bergantung pada kebijakan perutean yang ingin Anda gunakan dan apakah Anda membuat catatan alias, yang merutekan lalu lintas ke AWS sumber daya.
Alias mencatat lalu lintas yang merutekan lalu lintas ke AWS sumber daya tertentu yang Anda tentukan sumber daya targetnya (misalnya, Elastic Load Balancing CloudFront , distribusi, bucket Amazon S3). Anda juga dapat secara opsional mengaitkan pemeriksaan kesehatan dan mengonfigurasi evaluasi kesehatan target. Topik berikut memberikan informasi terperinci tentang nilai yang diperlukan untuk setiap kebijakan perutean dan jenis rekaman, membantu Anda mengonfigurasi catatan Route 53 Anda secara efektif.
**Topics**
+ [Nilai yang umum untuk semua kebijakan perutean](resource-record-sets-values-shared.md)
+ [Nilai yang umum untuk catatan alias untuk semua kebijakan perutean](resource-record-sets-values-alias-common.md)
+ [Nilai khusus untuk catatan sederhana](resource-record-sets-values-basic.md)
+ [Nilai khusus untuk catatan alias sederhana](resource-record-sets-values-alias.md)
+ [Nilai khusus untuk catatan failover](resource-record-sets-values-failover.md)
+ [Nilai khusus untuk catatan alias failover](resource-record-sets-values-failover-alias.md)
+ [Nilai khusus untuk catatan geolokasi](resource-record-sets-values-geo.md)
+ [Nilai khusus untuk catatan alias geolokasi](resource-record-sets-values-geo-alias.md)
+ [Nilai khusus untuk catatan geoproximity](resource-record-sets-values-geoprox.md)
+ [Nilai khusus untuk catatan alias geoproximity](resource-record-sets-values-geoprox-alias.md)
+ [Nilai khusus untuk catatan latensi](resource-record-sets-values-latency.md)
+ [Nilai khusus untuk catatan alias latensi](resource-record-sets-values-latency-alias.md)
+ [Nilai khusus untuk catatan berbasis IP](resource-record-sets-values-ipbased.md)
+ [Nilai khusus untuk catatan alias berbasis IP](resource-record-sets-values-ipbased-alias.md)
+ [Nilai khusus untuk catatan jawaban multivalue](resource-record-sets-values-multivalue.md)
+ [Nilai khusus untuk catatan tertimbang](resource-record-sets-values-weighted.md)
+ [Nilai khusus untuk catatan alias tertimbang](resource-record-sets-values-weighted-alias.md)
# Nilai yang umum untuk semua kebijakan perutean
Ini adalah nilai umum yang dapat Anda tentukan saat membuat atau mengedit rekaman Amazon Route 53. Nilai-nilai ini digunakan oleh semua kebijakan routing.
**Topics**
+ [Nama catatan](#rrsets-values-common-name)
+ [Menilai/Merutekan lalu lintas](#rrsets-values-common-value)
+ [TTL (detik)](#rrsets-values-common-ttl)
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama**.
**Catatan CNAME**
Jika Anda membuat catatan yang memiliki nilai **CNAME** untuk **Jenis catatan**, nama catatan tidak dapat sama dengan nama zona yang di-hosting.
**Karakter-karakter khusus**
Untuk informasi tentang cara menentukan karakter selain a-z, 0-9, dan - (tanda hubung) serta cara menentukan nama domain internasional, lihat [Format nama domain DNS](DomainNameFormat.md).
**Karakter wildcard **
Anda dapat menggunakan karakter tanda bintang (\$1) dalam nama. DNS memperlakukan karakter \$1 sebagai wildcard atau sebagai karakter \$1 (ASCII 42), tergantung tempat karakter muncul dalam nama. Untuk informasi selengkapnya, lihat [Menggunakan tanda bintang (\$1) dalam nama zona yang di-hosting dan catatan](DomainNameFormat.md#domain-name-format-asterisk).
Anda tidak dapat menggunakan wildcard \$1 untuk set catatan sumber daya yang memiliki tipe **NS**.
## Menilai/Merutekan lalu lintas
Pilih **IP address or another value depending on the record type** (Alamat IP atau nilai lain tergantung jenis catatan). Masukkan nilai yang sesuai untuk nilai **Jenis catatan**. Untuk semua jenis kecuali **CNAME**, Anda dapat memasukkan lebih dari satu nilai. Masukkan setiap nilai pada baris terpisah.
**A — IPv4 alamat**
Alamat IP dalam IPv4 format, misalnya, **192.0.2.235**.
**AAAA — alamat IPv6 **
Alamat IP dalam IPv6 format, misalnya, **2001:0 db 8:85 a 3:0:0:8 a2e: 0370:7334**.
**CAA — Otorisasi Otoritas Sertifikat**
Tiga nilai yang dipisahkan spasi yang mengontrol otoritas sertifikat mana yang diizinkan untuk menerbitkan sertifikat atau sertifikat wildcard untuk domain atau subdomain yang ditentukan oleh **Nama catatan**. Anda dapat menggunakan catatan CAA untuk menentukan hal berikut:
+ Otoritas sertifikat mana (CAs) yang dapat mengeluarkan SSL/TLS sertifikat, jika ada
+ Alamat email atau URL untuk dihubungi saat CA mengeluarkan sertifikat untuk domain atau subdomain
**CNAME — Nama kanonis**
Nama domain yang sepenuhnya memenuhi syarat (misalnya, *www.example.com*) yang Anda inginkan untuk dihasilkan oleh Route 53 sebagai tanggapan atas kueri DNS untuk catatan ini. Titik akhir adalah opsional; Route 53 mengasumsikan bahwa nama domain sepenuhnya memenuhi syarat. Ini berarti bahwa Route 53 memperlakukan*www.example.com*(tanpa titik akhir) dan*www.example.com.* (dengan titik akhir) sebagai identik.
**MX — Pertukaran surat**
Prioritas dan nama domain yang menentukan server email, misalnya,**10 mailserver.example.com**. Titik trailing diperlakukan sebagai opsional.
**NAPTR - Nama Authority Pointer**
Enam pengaturan dipisahkan ruang yang digunakan oleh Dynamic Delegation Discovery System (DDDS) aplikasi untuk mengonversi satu nilai lain atau untuk mengganti satu nilai dengan yang lain. Untuk informasi selengkapnya, lihat [Jenis catatan NAPTR](ResourceRecordTypes.md#NAPTRFormat).
**PTR — Pointer**
Nama domain yang Anda inginkan untuk dihasilkan Route 53.
**NS — Server nama**
Nama domain dari server nama, misalnya, **ns1.example.com**.
Anda dapat menentukan catatan NS hanya dengan kebijakan perutean sederhana.
**SPF — Kerangka Kebijakan Pengirim**
Catatan SPF yang diapit tanda kutip, misalnya, **"v=spf1 ip4:192.168.0.1/16-all"**. Catatann SPF tidak disarankan. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
**SRV — Locator layanan**
Catatan SRV. Catatan SRV digunakan untuk mengakses layanan, seperti layanan untuk email atau komunikasi. Untuk informasi tentang format catatan SRV, lihat dokumentasi untuk layanan yang ingin Anda sambungkan. Trailing dot diperlakukan sebagai opsional.
Format catatan SRV adalah:
**[prioritas] [berat] [port] [nama host server]**
Contoh:
**1 10 5269 xmpp-server.example.com.**
**TXT — Teks**
Catatan teks. Lampirkan teks dalam tanda kutip, sebagai contoh, **""Contoh entri teks"**.
## TTL (detik)
Jumlah waktu, dalam detik, yang Anda inginkan untuk resolver rekursif DNS untuk menyimpan informasi tentang catatan ini dalam cache. Jika Anda menentukan nilai yang lebih lama (misalnya, 172.800 detik, atau dua hari), Anda mengurangi jumlah panggilan yang harus dilakukan oleh resolver rekursif DNS ke Route 53 untuk mendapatkan informasi terbaru dalam catatan ini. Ini memiliki efek mengurangi latensi dan mengurangi tagihan Anda untuk layanan Route 53. Untuk informasi selengkapnya, lihat [Cara Amazon Route 53 merutekan lalu lintas untuk domain Anda](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Namun, jika Anda menentukan nilai yang lebih lama untuk TTL, diperlukan waktu lebih lama agar perubahan pada catatan (misalnya, alamat IP baru) diterapkan karena resolver rekursif menggunakan nilai dalam cache mereka untuk waktu yang lebih lama sebelum mereka meminta Route 53 untuk informasi terakhir. Jika Anda mengubah setelan untuk domain atau subdomain yang sudah digunakan, sebaiknya tentukan dulu nilai yang lebih pendek, seperti 300 detik, dan tingkatkan nilainya setelah mengonfirmasi bahwa pengaturan baru sudah benar.
Jika Anda mengaitkan catatan ini dengan pemeriksaan kondisi, sebaiknya tentukan TTL 60 detik atau kurang sehingga klien merespons dengan cepat perubahan status kondisi.
# Nilai yang umum untuk catatan alias untuk semua kebijakan perutean
Ini adalah nilai alias umum yang dapat Anda tentukan saat membuat atau mengedit rekaman Amazon Route 53. Nilai-nilai ini digunakan oleh semua kebijakan routing.
**Topics**
+ [Nama catatan](#rrsets-values-common-alias-name)
+ [Menilai/Merutekan lalu lintas](#rrsets-values-alias-common-target)
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama**.
**Catatan CNAME**
Jika Anda membuat catatan yang memiliki nilai **CNAME** untuk **Jenis**, nama catatan tidak boleh sama dengan nama zona yang di-hosting.
**Alias untuk CloudFront distribusi dan bucket Amazon S3**
Nilai yang Anda tentukan sebagian bergantung pada AWS sumber daya yang Anda rutekan lalu lintas ke:
+ **CloudFront distribusi** — Distribusi Anda harus menyertakan nama domain alternatif yang cocok dengan nama catatan. Misalnya, jika nama catatan adalah **acme.example.com, CloudFront distribusi Anda harus menyertakan **acme.example.com**** sebagai salah satu nama domain alternatif. Untuk informasi selengkapnya, lihat [Menggunakan nama domain alternatif (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) di *Panduan CloudFront Pengembang Amazon*.
+ **Bucket Amazon S3** – Nama catatan harus sesuai dengan nama bucket Amazon S3 Anda. Misalnya, jika nama bucket Anda **acme.example.com**, nama catatan ini juga harus **acme.example.com**.
Selain itu, Anda harus mengonfigurasi bucket untuk meng-host situs web. Untuk informasi selengkapnya, lihat [Mengonfigurasi bucket untuk hosting situs web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon*.
**Karakter-karakter khusus**
Untuk informasi tentang cara menentukan karakter selain a-z, 0-9, dan - (tanda hubung) serta cara menentukan nama domain internasional, lihat [Format nama domain DNS](DomainNameFormat.md).
**Karakter wildcard **
Anda dapat menggunakan karakter tanda bintang (\$1) dalam nama. DNS memperlakukan karakter \$1 sebagai wildcard atau sebagai karakter \$1 (ASCII 42), tergantung tempat karakter muncul dalam nama. Untuk informasi selengkapnya, lihat [Menggunakan tanda bintang (\$1) dalam nama zona yang di-hosting dan catatan](DomainNameFormat.md#domain-name-format-asterisk).
## Menilai/Merutekan lalu lintas
Nilai yang Anda pilih dari daftar atau yang Anda ketik di bidang tergantung pada AWS sumber daya yang Anda rutekan lalu lintas.
Untuk informasi selengkapnya tentang cara mengonfigurasi Route 53 untuk merutekan lalu lintas ke AWS sumber daya tertentu, lihat[Merutekan lalu lintas internet ke sumber daya Anda AWS](routing-to-aws-resources.md).
**penting**
Jika Anda menggunakan AWS akun yang sama untuk membuat zona yang dihosting dan sumber daya yang Anda rutekan lalu lintas, dan jika sumber daya Anda tidak muncul di daftar **Titik Akhir**, periksa hal berikut:
Konfirmasi bahwa Anda memilih nilai yang didukung untuk **Jenis catatan**. Nilai yang didukung khusus untuk sumber daya tempat Anda merutekan lalu lintas. Misalnya, untuk merutekan lalu lintas ke bucket S3, Anda harus memilih ** IPv4 alamat A —** untuk **jenis Rekam**.
Konfirmasikan bahwa akun memiliki izin IAM yang diperlukan untuk mencantumkan sumber daya yang berlaku. Misalnya, agar CloudFront distribusi muncul di daftar **Titik Akhir**, akun harus memiliki izin untuk melakukan tindakan berikut:. `cloudfront:ListDistributions`
Untuk contoh kebijakan IAM, lihat [Izin diperlukan untuk menggunakan konsol Amazon Route 53](access-control-managing-permissions.md#console-required-permissions) .
Jika Anda menggunakan AWS akun yang berbeda untuk membuat zona yang dihosting dan sumber daya, daftar **Endpoint** tidak menampilkan sumber daya Anda. Lihat dokumentasi berikut untuk jenis sumber daya Anda untuk menentukan nilai yang akan diketik di **Titik Akhir**.
**API Gateway khusus regional APIs dan dioptimalkan tepi APIs**
Untuk API Gateway kustom regional APIs dan edge-optimize APIs, lakukan salah satu hal berikut:
+ **Jika Anda menggunakan akun yang sama untuk membuat zona yang di-hosting Route 53 dan API Anda** – Pilih **Endpoint** (Titik Akhir), lalu pilih API dari daftar. Jika Anda memiliki banyak APIs, Anda dapat memasukkan beberapa karakter pertama dari titik akhir API untuk memfilter daftar.
**catatan**
Nama data ini harus cocok dengan nama domain khusus untuk API Anda, seperti **api.example.com**.
+ **Jika Anda menggunakan akun yang berbeda untuk membuat zona yang di-hosting Route 53 dan API Anda**– Masukkan titik akhir API untuk API, seperti **api.example.com**.
Jika Anda menggunakan satu AWS akun untuk membuat zona host saat ini dan akun lain untuk membuat API, API tidak akan muncul di daftar **Titik Akhir** di bawah **API Gateway APIs**.
Jika Anda menggunakan satu akun untuk membuat zona host saat ini dan satu atau beberapa akun berbeda untuk membuat semua akun Anda APIs, daftar **Titik Akhir** akan menampilkan **Tidak ada target yang tersedia** di bawah **API Gateway APIs**. Untuk informasi selengkapnya, lihat [Merutekan lalu lintas ke API Amazon API Gateway dengan menggunakan nama domain Anda](routing-to-api-gateway.md).
**CloudFront distribusi**
Untuk CloudFront distribusi, lakukan salah satu hal berikut:
+ **Jika Anda menggunakan akun yang sama untuk membuat zona yang dihosting Route 53 dan CloudFront distribusi Anda** — Pilih **Titik Akhir** dan pilih distribusi dari daftar. Jika Anda memiliki banyak distribusi, Anda dapat memasukkan beberapa karakter pertama dari nama domain untuk distribusi Anda untuk memfilter daftar.
Jika distribusi Anda tidak muncul dalam daftar, perhatikan hal berikut:
+ Nama catatan ini harus cocok dengan nama domain alternatif di distribusi Anda.
+ Jika Anda baru saja menambahkan nama domain alternatif ke distribusi Anda, mungkin diperlukan waktu 15 menit agar perubahan Anda menyebar ke semua lokasi CloudFront tepi. Sampai perubahan menyebar, Route 53 tidak dapat mengetahui tentang nama domain alternatif yang baru.
+ **Jika Anda menggunakan akun yang berbeda untuk membuat zona yang dihosting Route 53 dan distribusi Anda — Masukkan nama CloudFront domain untuk distribusi**, seperti **d111111abcdef8.cloudfront.net**.
Jika Anda menggunakan satu AWS akun untuk membuat zona host saat ini dan akun lain untuk membuat distribusi, distribusi tidak akan muncul di daftar **Endpoints**.
**Jika Anda menggunakan satu akun untuk membuat zona yang dihosting saat ini dan satu atau beberapa akun berbeda untuk membuat semua distribusi, daftar **Titik Akhir** menunjukkan **Tidak ada target yang tersedia** di bawah CloudFront distribusi.**
Jangan merutekan kueri ke CloudFront distribusi yang belum disebarkan ke semua lokasi tepi, atau pengguna Anda tidak akan dapat mengakses konten yang berlaku.
CloudFront Distribusi Anda harus menyertakan nama domain alternatif yang cocok dengan nama catatan. Misalnya, jika nama catatan adalah **acme.example.com, CloudFront distribusi Anda harus menyertakan **acme.example.com**** sebagai salah satu nama domain alternatif. Untuk informasi selengkapnya, lihat [Menggunakan nama domain alternatif (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) di *Panduan CloudFront Pengembang Amazon*.
Jika IPv6 diaktifkan untuk distribusi, buat dua catatan, satu dengan nilai **A — IPv4 alamat** untuk **jenis Rekaman**, dan satu dengan nilai **AAAA — IPv6** alamat. Untuk informasi selengkapnya, lihat [Merutekan lalu lintas ke CloudFront distribusi Amazon dengan menggunakan nama domain Anda](routing-to-cloudfront-distribution.md).
**Layanan Pelari Aplikasi**
Untuk layanan App Runner, lakukan salah satu hal berikut:
+ **Jika Anda menggunakan akun yang sama untuk membuat zona yang dihosting Route 53 dan layanan App Runner Anda** — pilih Wilayah AWS, lalu pilih nama domain lingkungan tempat Anda ingin mengarahkan lalu lintas dari daftar.
+ **Jika Anda menggunakan akun yang berbeda untuk membuat zona yang dihosting Route 53 dan Pelari Aplikasi Anda** — Masukkan nama domain khusus. Untuk informasi selengkapnya, lihat [Mengelola nama domain khusus untuk App Runner](https://docs.aws.amazon.com/apprunner/latest/dg/manage-custom-domains.html).
Jika Anda menggunakan satu AWS akun untuk membuat zona yang dihosting saat ini dan akun lain untuk membuat Pelari Aplikasi, Pelari Aplikasi tidak akan muncul di daftar Titik **Akhir**.
Untuk informasi selengkapnya, lihat [Mengonfigurasi Amazon Route 53 untuk merutekan lalu lintas ke layanan App Runner](routing-to-app-runner.md#routing-to-app-runner-configuring).
**Lingkungan Elastic Beanstalk yang memiliki subdomain regional**
Jika nama domain untuk lingkungan Elastic Beanstalk Anda menyertakan Wilayah tempat Anda menerapkan lingkungan, Anda dapat membuat catatan alias yang merutekan lalu lintas ke lingkungan. Sebagai contoh, nama domain `my-environment.us-west-2.elasticbeanstalk.com` adalah nama domain regional.
Untuk lingkungan yang dibuat sebelum awal 2016, nama domain tidak termasuk Wilayah. Untuk merutekan lalu lintas ke lingkungan ini, Anda harus membuat catatan CNAME, alih-alih catatan alias. Perhatikan bahwa Anda tidak dapat membuat catatan CNAME untuk nama domain root. Misalnya, jika nama domain Anda adalah example.com, Anda dapat membuat catatan yang mengarahkan lalu lintas untuk acme.example.com ke lingkungan Elastic Beanstalk Anda, tetapi Anda tidak dapat membuat catatan yang mengarahkan lalu lintas untuk example.com ke lingkungan Elastic Beanstalk Anda.
Untuk lingkungan Elastic Beanstalk yang memiliki subdomain regional, lakukan salah satu hal berikut:
+ **Jika Anda menggunakan akun yang sama untuk membuat zona yang di-hosting Route 53 dan lingkungan Elastic Beanstalk Anda** – Pilih **Endpoint** (Titik akhir), lalu pilih lingkungan dari daftar. Jika Anda memiliki banyak lingkungan, Anda dapat memasukkan beberapa karakter pertama dari atribut CNAME untuk lingkungan guna memfilter daftar.
+ **Jika Anda menggunakan akun yang berbeda untuk membuat zona yang di-hosting Route 53 dan lingkungan Elastic Beanstalk Anda** – Masukkan atribut CNAME untuk lingkungan Elastic Beanstalk.
Untuk informasi selengkapnya, lihat [Merutekan lalu lintas ke lingkungan AWS Elastic Beanstalk](routing-to-beanstalk-environment.md).
**Penyeimbang beban ELB**
Di bagian penyeimbang beban ELB, lakukan salah satu hal berikut:
+ **Jika Anda menggunakan akun yang sama untuk membuat zona yang di-hosting Route 53 dan penyeimbang beban Anda** – Pilih **Endpoint** (Titik akhir) dan pilih penyeimbang beban dari daftar. Jika Anda memiliki banyak penyeimbang beban, Anda dapat memasukkan beberapa karakter pertama dari nama DNS untuk memfilter daftar.
+ **Jika Anda menggunakan akun yang berbeda untuk membuat zona yang di-hosting Route 53 dan penyeimbang beban Anda** – Masukkan nilai yang Anda dapatkan dalam prosedur [Mendapatkan nama DNS untuk penyeimbang beban Elastic Load Balancing](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure).
Jika Anda menggunakan satu AWS akun untuk membuat zona host saat ini dan akun lain untuk membuat penyeimbang beban, penyeimbang beban tidak akan muncul di daftar Titik **Akhir**.
Jika Anda menggunakan satu akun untuk membuat zona yang dihosting saat ini dan satu atau beberapa akun berbeda untuk membuat semua penyeimbang beban Anda, daftar **Titik Akhir** menunjukkan **Tidak ada target yang tersedia** di bawah **Elastic Load Balancers**.
**Konsol menambahkan dualstack.** untuk Aplikasi dan Classic Load Balancer dari akun yang berbeda. Ketika klien, seperti browser web, meminta alamat IP untuk nama domain Anda (example.com) atau nama subdomain (www.example.com), klien dapat meminta alamat (catatan A), IPv4 alamat (catatan AAAA), atau keduanya IPv4 dan IPv6 alamat (dalam permintaan terpisah). IPv6 Penunjukan **dualstack.** memungkinkan Route 53 untuk merespons dengan alamat IP yang sesuai untuk penyeimbang beban Anda berdasarkan format alamat IP yang diminta klien.
Untuk informasi selengkapnya, lihat [Merutekan lalu lintas ke penyeimbang beban ELB](routing-to-elb-load-balancer.md).
**AWS Akselerator Akselerator Global**
Untuk akselerator AWS Global Accelerator, masukkan nama DNS untuk akselerator. Anda dapat memasukkan nama DNS akselerator yang Anda buat menggunakan AWS akun saat ini atau menggunakan akun lain AWS .
**Bucket Amazon S3**
Untuk bucket Amazon S3 yang dikonfigurasi sebagai titik akhir situs web, lakukan salah satu hal berikut:
+ **Jika Anda menggunakan akun yang sama untuk membuat zona yang di-hosting Route 53 dan bucket Amazon S3 Anda** – Pilih **Endpoint** (Titik Akhir) dan pilih bucket dari daftar. Jika Anda memiliki banyak bucket, Anda dapat memasukkan beberapa karakter pertama dari nama DNS untuk memfilter daftar.
Nilai **Titik Akhir** berubah ke titik akhir situs web Amazon S3 untuk bucket Anda.
+ **Jika Anda menggunakan akun yang berbeda untuk membuat zona yang dihosting Route 53 dan bucket Amazon S3 Anda** — Masukkan nama Wilayah tempat Anda membuat bucket S3. Gunakan nilai yang muncul di kolom **titik akhir Situs Web** dalam tabel titik akhir [situs Amazon S3](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints) di. *Referensi Umum Amazon Web Services*
**Jika Anda menggunakan AWS akun selain akun saat ini untuk membuat bucket Amazon S3, bucket tidak akan muncul di daftar Titik Akhir.**
Anda dapat mengonfigurasi bucket untuk meng-host situs web. Untuk informasi selengkapnya, lihat [Mengonfigurasi bucket untuk hosting situs web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon*.
Nama catatan harus cocok dengan nama bucket Amazon S3 Anda. Misalnya, jika nama bucket Amazon S3 Anda adalah **acme.example.com**, nama catatan ini juga harus **acme.example.com**.
Dalam grup catatan alias berbobot, alias latensi, alias failover, atau alias geolokasi, Anda hanya dapat membuat satu catatan yang merutekan kueri ke bucket Amazon S3 karena nama catatan harus cocok dengan nama bucket dan nama bucket harus unik secara global.
** OpenSearch Layanan Amazon**
Untuk OpenSearch Layanan, lakukan salah satu hal berikut:
+ **OpenSearch Domain kustom layanan**: Nama catatan harus cocok dengan domain kustom. Misalnya, jika nama domain kustom Anda adalah test.example.com, nama catatan ini juga harus test.example.com.
+ **Jika Anda menggunakan akun yang sama untuk membuat zona host Route 53 dan domain OpenSearch Layanan Anda** — pilih Wilayah AWS, lalu pilih nama domain.
+ **Jika Anda menggunakan akun yang berbeda untuk membuat zona yang dihosting Route 53 dan domain OpenSearch Layanan Anda** — Masukkan nama domain khusus. Untuk informasi selengkapnya, lihat [Membuat titik akhir kustom](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/customendpoint.html).
Jika Anda menggunakan satu AWS akun untuk membuat zona host saat ini dan akun lain untuk membuat domain OpenSearch Layanan, domain tidak akan muncul dalam daftar **Titik Akhir**.
**Jika Anda menggunakan satu akun untuk membuat zona yang dihosting saat ini dan satu atau beberapa akun berbeda untuk membuat semua domain OpenSearch Layanan Anda, daftar **Titik Akhir** menunjukkan **Tidak ada target yang tersedia** di bawah OpenSearch Layanan.**
Untuk informasi selengkapnya, lihat [Mengonfigurasi Amazon Route 53 untuk merutekan lalu lintas ke titik akhir domain OpenSearch Layanan Amazon](routing-to-open-search-service.md#routing-to-open-search-service-configuring).
**Titik akhir antarmuka Amazon VPC**
Untuk titik akhir antarmuka Amazon VPC, lakukan salah satu hal berikut:
+ **Jika Anda menggunakan akun yang sama untuk membuat zona host Route 53 dan titik akhir antarmuka Anda** – Pilih **Endpoint** (Titik Akhir), lalu pilih titik akhir antarmuka dari daftar. Jika Anda memiliki banyak titik akhir antarmuka, Anda dapat memasukkan beberapa karakter pertama dari nama host DNS untuk memfilter daftar.
+ **Jika Anda menggunakan akun yang berbeda untuk membuat zona host Route 53 dan titik akhir antarmuka Anda — Masukkan nama host DNS untuk titik akhir antarmuka****, seperti vpce-123456789abcdef01- -1a.elasticloadbalancing.us-east-1.vpce.amazonaws.com. example-us-east**
**Jika Anda menggunakan satu AWS akun untuk membuat zona host saat ini dan akun lain untuk membuat titik akhir antarmuka, titik akhir antarmuka tidak akan muncul di daftar Titik Akhir di bawah **titik akhir** VPC.**
Jika Anda menggunakan satu akun untuk membuat zona yang di-hosting saat ini dan satu atau beberapa akun berbeda untuk membuat semua titik akhir antarmuka Anda, daftar **Titik Akhir** menunjukkan **Tidak ada target yang tersedia** di **VPC endpoint**.
Untuk informasi selengkapnya, lihat [Merutekan lalu lintas ke titik akhir antarmuka Amazon Virtual Private Cloud dengan menggunakan nama domain Anda](routing-to-vpc-interface-endpoint.md).
**Catatan di Zona yang Di-hosting ini**
Untuk rekaman di zona yang di-hosting ini, pilih **Endpoint** (Titik Akhir) dan pilih catatan yang berlaku. Jika Anda memiliki banyak catatan, Anda dapat memasukkan beberapa karakter pertama dari nama tersebut untuk memfilter daftar.
Jika zona yang di-hosting hanya berisi catatan NS dan SOA default, daftar **Titik Akhir** menunjukkan **Tidak ada target yang tersedia**.
Jika Anda membuat catatan alias yang memiliki nama yang sama sebagai zona yang dihosting (dikenal sebagai *zone apex*), Anda tidak dapat memilih catatan dengan nilai **Record type** (Jenis catatan) adalah **CNAME**. Ini karena catatan alias harus memiliki jenis yang sama dengan catatan yang Anda tuju, dan membuat catatan CNAME untuk Zone Apex tidak didukung bahkan untuk catatan alias.
# Nilai khusus untuk catatan sederhana
Saat Anda membuat catatan sederhana, Anda menentukan nilai berikut.
**Topics**
+ [Kebijakan perutean](#rrsets-values-basic-routing-policy)
+ [Nama catatan](#rrsets-values-basic-name)
+ [Menilai/Merutekan lalu lintas](#rrsets-values-basic-value)
+ [Tipe catatan](#rrsets-values-basic-type)
+ [TTL (detik)](#rrsets-values-basic-ttl)
## Kebijakan perutean
Pilih **Simple routing** (Perutean sederhana).
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama**.
Untuk informasi selengkapnya tentang nama rekaman, lihat[Nama catatan](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Menilai/Merutekan lalu lintas
Pilih **IP address or another value depending on the record type** (Alamat IP atau nilai lain tergantung jenis catatan). Masukkan nilai yang sesuai untuk nilai **Jenis catatan**. Untuk semua jenis kecuali **CNAME**, Anda dapat memasukkan lebih dari satu nilai. Masukkan setiap nilai pada baris terpisah.
Anda dapat merutekan lalu lintas ke, atau menentukan nilai berikut:
+ **A — IPv4 alamat**
+ **AAAA — alamat IPv6 **
+ **CAA - Otorisasi Otoritas Sertifikat**
+ **CNAME — Nama kanonik**
+ **MX - Pertukaran surat**
+ **NAPTR - Penunjuk Otoritas Nama**
+ **NS - Server nama**
Nama domain dari server nama, misalnya, **ns1.example.com**.
**catatan**
Anda dapat menentukan catatan NS hanya dengan kebijakan perutean sederhana.
+ **PTR — Penunjuk**
+ **SPF - Kerangka Kebijakan Pengirim**
+ **SRV - Pencari lokasi layanan**
+ **TXT - Teks**
Untuk informasi selengkapnya tentang nilai di atas, lihat [nilai umum untuk Value/Route lalu lintas ke](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai untuk **Jenis catatan** berdasarkan bagaimana Anda ingin Route 53 untuk menanggapi permintaan DNS.
## TTL (detik)
Jumlah waktu, dalam detik, yang Anda inginkan untuk resolver rekursif DNS untuk menyimpan informasi tentang catatan ini dalam cache. Jika Anda menentukan nilai yang lebih lama (misalnya, 172.800 detik, atau dua hari), Anda mengurangi jumlah panggilan yang harus dilakukan oleh resolver rekursif DNS ke Route 53 untuk mendapatkan informasi terbaru dalam catatan ini. Ini memiliki efek mengurangi latensi dan mengurangi tagihan Anda untuk layanan Route 53. Untuk informasi selengkapnya, lihat [Cara Amazon Route 53 merutekan lalu lintas untuk domain Anda](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Namun, jika Anda menentukan nilai yang lebih lama untuk TTL, diperlukan waktu lebih lama agar perubahan pada catatan (misalnya, alamat IP baru) diterapkan karena resolver rekursif menggunakan nilai dalam cache mereka untuk waktu yang lebih lama sebelum mereka meminta Route 53 untuk informasi terakhir. Jika Anda mengubah setelan untuk domain atau subdomain yang sudah digunakan, sebaiknya tentukan dulu nilai yang lebih pendek, seperti 300 detik, dan tingkatkan nilainya setelah mengonfirmasi bahwa pengaturan baru sudah benar.
# Nilai khusus untuk catatan alias sederhana
Saat Anda membuat catatan alias, Anda menentukan nilai berikut. Untuk informasi selengkapnya, lihat [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md).
**catatan**
Jika Anda menggunakan Route 53 di AWS GovCloud (US) Region, fitur ini memiliki beberapa batasan. Untuk informasi selengkapnya, lihat halaman [Amazon Route 53](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html) di *Panduan Pengguna AWS GovCloud (US) *.
**Topics**
+ [Kebijakan perutean](#rrsets-values-alias-routing-policy)
+ [Nama catatan](#rrsets-values-alias-name)
+ [Nilai/Rutekan lalu lintas ke](#rrsets-values-alias-alias-target)
+ [Tipe catatan](#rrsets-values-alias-type)
+ [Mengevaluasi Kondisi Target](#rrsets-values-alias-evaluate-target-health)
## Kebijakan perutean
Pilih **Simple routing** (Perutean sederhana).
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama**.
Untuk informasi selengkapnya tentang nama rekaman, lihat[Nama catatan](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Nilai/Rutekan lalu lintas ke
Nilai yang Anda pilih dari daftar atau yang Anda ketik di bidang tergantung pada AWS sumber daya yang Anda rutekan lalu lintas.
Untuk informasi tentang AWS sumber daya yang dapat Anda targetkan, lihat [nilai umum untuk catatan alias untuk value/route lalu lintas](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Untuk informasi selengkapnya tentang cara mengonfigurasi Route 53 untuk merutekan lalu lintas ke AWS sumber daya tertentu, lihat[Merutekan lalu lintas internet ke sumber daya Anda AWS](routing-to-aws-resources.md).
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai yang berlaku berdasarkan AWS sumber daya yang Anda rutekan lalu lintas ke:
**API regional kustom API Gateway atau API yang dioptimalkan edge**
Pilih **A — IPv4 alamat**.
**Titik akhir antarmuka Amazon VPC**
Pilih **A — IPv4 alamat**.
**CloudFront distribusi**
Pilih **A — IPv4 alamat**.
Jika IPv6 diaktifkan untuk distribusi, buat dua catatan, satu dengan nilai **A — IPv4 alamat** untuk **Jenis**, dan satu dengan nilai **AAAA — IPv6 ** alamat.
**Layanan Pelari Aplikasi**
Select **A — IPv4 alamat**
**Lingkungan Elastic Beanstalk yang memiliki subdomain regional**
Select **A — IPv4 alamat**
**Penyeimbang beban ELB**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Buket Amazon S3**
Select **A — IPv4 alamat**
**OpenSearch Layanan**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Catatan lain di zona yang di-hosting ini**
Pilih jenis catatan yang Anda buatkan alias. Semua jenis didukung kecuali **NS** dan **SOA**.
Jika Anda membuat catatan alias yang memiliki nama yang sama sebagai zona yang di-hosting (dikenal sebagai *zone apex*), Anda tidak dapat merutekan lalu lintas ke catatan dengan nilai **Jenis** adalah **CNAME**. Ini karena catatan alias harus memiliki jenis yang sama dengan catatan yang Anda tuju, dan membuat catatan CNAME untuk Zone Apex tidak didukung bahkan untuk catatan alias.
## Mengevaluasi Kondisi Target
Ketika nilai **Kebijakan perutean ** adalah **Sederhana**, Anda dapat memilih **Tidak** atau default **Ya** karena **Mengevaluasi kondisi target** tidak berpengaruh untuk perutean **Sederhana**. Jika Anda hanya memiliki satu catatan yang memiliki nama dan tipe tertentu, Route 53 merespons kueri DNS dengan menggunakan nilai dalam catatan tersebut terlepas dari apakah sumber dayanya sehat.
Untuk kebijakan perutean lainnya, **Evaluasi kesehatan target** menentukan apakah Route 53 memeriksa kesehatan sumber daya yang dirujuk oleh catatan alias:
+ **Layanan di mana Evaluasi kesehatan target memberikan manfaat operasional**: Untuk penyeimbang beban (ELB) dan AWS Elastic Beanstalk lingkungan dengan penyeimbang beban, pengaturan **Evaluasi kesehatan target** ke **Ya** memungkinkan Rute 53 untuk merutekan lalu lintas dari sumber daya yang tidak sehat.
+ **Layanan yang sangat tersedia**: Untuk layanan seperti bucket Amazon S3, titik akhir antarmuka VPC, Amazon API Gateway, Amazon Service AWS Global Accelerator, dan Amazon VPC Lattice OpenSearch **, Evaluate target** health tidak memberikan manfaat operasional karena layanan ini dirancang untuk ketersediaan tinggi. Untuk skenario failover dengan layanan ini, gunakan [pemeriksaan kesehatan Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html) sebagai gantinya.
Untuk informasi terperinci tentang cara kerja **Evaluasi kesehatan target** dengan berbagai AWS layanan, lihat [ EvaluateTargetHealth](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth)dokumentasi di referensi API.
# Nilai khusus untuk catatan failover
Saat Anda membuat catatan failover, Anda menentukan nilai berikut.
**catatan**
Untuk informasi tentang cara membuat catatan failover di zona yang di-hosting pribadi, lihat [Mengonfigurasi failover di zona yang di-hosting secara privat](dns-failover-private-hosted-zones.md).
**Topics**
+ [Kebijakan perutean](#rrsets-values-failover-routing-policy)
+ [Nama catatan](#rrsets-values-failover-name)
+ [Tipe catatan](#rrsets-values-failover-type)
+ [TTL (detik)](#rrsets-values-failover-ttl)
+ [Menilai/Merutekan lalu lintas](#rrsets-values-failover-value)
+ [Tipe catatan failover](#rrsets-values-failover-record-type)
+ [Pemeriksaan kondisi](#rrsets-values-failover-associate-with-health-check)
+ [ID catatan](#rrsets-values-failover-set-id)
## Kebijakan perutean
Pilih **Failover**.
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama catatan**.
Masukkan nama yang sama untuk kedua catatan dalam grup catatan failover.
Untuk informasi selengkapnya tentang nama rekaman, lihat[Nama catatan](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai yang sama untuk catatan failover primer dan sekunder.
## TTL (detik)
Jumlah waktu, dalam detik, yang Anda inginkan untuk resolver rekursif DNS untuk menyimpan informasi tentang catatan ini dalam cache. Jika Anda menentukan nilai yang lebih lama (misalnya, 172.800 detik, atau dua hari), Anda mengurangi jumlah panggilan yang harus dilakukan oleh resolver rekursif DNS ke Route 53 untuk mendapatkan informasi terbaru dalam catatan ini. Ini memiliki efek mengurangi latensi dan mengurangi tagihan Anda untuk layanan Route 53. Untuk informasi selengkapnya, lihat [Cara Amazon Route 53 merutekan lalu lintas untuk domain Anda](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Namun, jika Anda menentukan nilai yang lebih lama untuk TTL, diperlukan waktu lebih lama agar perubahan pada catatan (misalnya, alamat IP baru) diterapkan karena resolver rekursif menggunakan nilai dalam cache mereka untuk waktu yang lebih lama sebelum mereka meminta Route 53 untuk informasi terakhir. Jika Anda mengubah setelan untuk domain atau subdomain yang sudah digunakan, sebaiknya tentukan dulu nilai yang lebih pendek, seperti 300 detik, dan tingkatkan nilainya setelah mengonfirmasi bahwa pengaturan baru sudah benar.
Jika Anda mengaitkan catatan ini dengan pemeriksaan kondisi, sebaiknya tentukan TTL 60 detik atau kurang sehingga klien merespons dengan cepat perubahan status kondisi.
## Menilai/Merutekan lalu lintas
Pilih **IP address or another value depending on the record type** (Alamat IP atau nilai lain tergantung jenis catatan). Masukkan nilai yang sesuai untuk nilai **Jenis catatan**. Untuk semua jenis kecuali **CNAME**, Anda dapat memasukkan lebih dari satu nilai. Masukkan setiap nilai pada baris terpisah.
Anda dapat merutekan lalu lintas ke, atau menentukan nilai berikut:
+ **A — IPv4 alamat**
+ **AAAA — alamat IPv6 **
+ **CAA - Otorisasi Otoritas Sertifikat**
+ **CNAME — Nama kanonik**
+ **MX - Pertukaran surat**
+ **NAPTR - Penunjuk Otoritas Nama**
+ **PTR — Penunjuk**
+ **SPF - Kerangka Kebijakan Pengirim**
+ **SRV - Pencari lokasi layanan**
+ **TXT - Teks**
Untuk informasi selengkapnya tentang nilai di atas, lihat [nilai umum untuk Value/Route lalu lintas ke](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Tipe catatan failover
Pilih nilai yang berlaku untuk catatan ini. Agar failover berfungsi dengan benar, Anda harus membuat satu catatan failover primer dan satu sekunder.
Anda tidak dapat membuat rekaman non-failover yang memiliki nilai yang sama untuk **Nama catatan** dan **Jenis catatan** sebagai catatan failover.
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Mengevaluasi Kesehatan Target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias latensi, alias berbasis IP, atau catatan alias tertimbang. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama Domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama Domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan primer dan sekunder.
# Nilai khusus untuk catatan alias failover
Ketika Anda membuat catatan alias failover, Anda menentukan nilai-nilai berikut.
Untuk informasi, lihat topik berikut:
+ Untuk informasi tentang membuat rekaman failover di zona yang di-hosting pribadi, lihat [Mengonfigurasi failover di zona yang di-hosting secara privat](dns-failover-private-hosted-zones.md).
+ Untuk informasi tentang catatan alias, lihat [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Kebijakan perutean](#rrsets-values-failover-alias-routing-policy)
+ [Nama catatan](#rrsets-values-failover-alias-name)
+ [Tipe catatan](#rrsets-values-failover-alias-type)
+ [Nilai/Rutekan lalu lintas ke](#rrsets-values-failover-alias-alias-target)
+ [Tipe catatan failover](#rrsets-values-failover-alias-failover-record-type)
+ [Pemeriksaan kondisi](#rrsets-values-failover-alias-associate-with-health-check)
+ [Mengevaluasi Kondisi Target](#rrsets-values-failover-alias-evaluate-target-health)
+ [ID catatan](#rrsets-values-failover-alias-set-id)
## Kebijakan perutean
Pilih **Failover**.
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama catatan**.
Masukkan nama yang sama untuk kedua catatan dalam grup catatan failover.
Untuk informasi selengkapnya tentang nama rekaman, lihat[Nama catatan](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai yang berlaku berdasarkan AWS sumber daya yang Anda rutekan lalu lintas. Pilih nilai yang sama untuk catatan failover primer dan sekunder:
**API regional kustom API Gateway atau API yang dioptimalkan edge**
Pilih **A — IPv4 alamat**.
**Titik akhir antarmuka Amazon VPC**
Pilih **A — IPv4 alamat**.
**CloudFront distribusi**
Pilih **A — IPv4 alamat**.
Jika IPv6 diaktifkan untuk distribusi, buat dua catatan, satu dengan nilai **A — IPv4 alamat** untuk **Jenis**, dan satu dengan nilai **AAAA — IPv6 ** alamat.
**Layanan Pelari Aplikasi**
Select **A — IPv4 alamat**
**Lingkungan Elastic Beanstalk yang memiliki subdomain regional**
Select **A — IPv4 alamat**
**Penyeimbang beban ELB**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Buket Amazon S3**
Select **A — IPv4 alamat**
**OpenSearch Layanan**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Catatan lain di zona yang di-hosting ini**
Pilih jenis catatan yang Anda buatkan alias. Semua jenis didukung kecuali **NS** dan **SOA**.
Jika Anda membuat catatan alias yang memiliki nama yang sama sebagai zona yang di-hosting (dikenal sebagai *zone apex*), Anda tidak dapat merutekan lalu lintas ke catatan dengan nilai **Jenis** adalah **CNAME**. Ini karena catatan alias harus memiliki jenis yang sama dengan catatan yang Anda tuju, dan membuat catatan CNAME untuk Zone Apex tidak didukung bahkan untuk catatan alias.
## Nilai/Rutekan lalu lintas ke
Nilai yang Anda pilih dari daftar atau yang Anda ketik di bidang tergantung pada AWS sumber daya yang Anda rutekan lalu lintas.
Untuk informasi tentang AWS sumber daya yang dapat Anda targetkan, lihat [nilai umum untuk catatan alias untuk value/route lalu lintas](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Untuk informasi selengkapnya tentang cara mengonfigurasi Route 53 untuk merutekan lalu lintas ke AWS sumber daya tertentu, lihat[Merutekan lalu lintas internet ke sumber daya Anda AWS](routing-to-aws-resources.md).
**catatan**
Saat Anda membuat catatan failover primer dan sekunder, Anda dapat secara opsional membuat satu failover dan satu catatan *alias* failover yang memiliki nilai yang sama untuk **Nama** dan **Jenis catatan**. Jika Anda mencampur failover dan failover alias catatan, salah satunya bisa menjadi catatan utama.
## Tipe catatan failover
Pilih nilai yang berlaku untuk catatan ini. Agar failover berfungsi dengan benar, Anda harus membuat satu catatan failover primer dan satu sekunder.
Anda tidak dapat membuat rekaman non-failover yang memiliki nilai yang sama untuk **Nama catatan** dan **Jenis catatan** sebagai catatan failover.
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Mengevaluasi Kesehatan Target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias latensi, alias berbasis IP, atau catatan alias tertimbang. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama Domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama Domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
## Mengevaluasi Kondisi Target
Pilih **Ya** jika Anda ingin Route 53 untuk menentukan apakah untuk menanggapi permintaan DNS menggunakan catatan ini dengan memeriksa kondisi sumber daya yang ditentukan oleh **Titik akhir**.
Perhatikan hal-hal berikut:
**API Gateway khusus regional APIs dan dioptimalkan tepi APIs**
Tidak ada persyaratan khusus untuk menyetel **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah API regional kustom API Gateway atau API yang dioptimalkan edge.
**CloudFront distribusi**
Anda tidak dapat menetapkan **Evaluasi kesehatan target** ke **Ya** ketika titik akhir adalah CloudFront distribusi.
**Lingkungan Elastic Beanstalk yang memiliki subdomain regionalisasi**
Jika Anda menentukan lingkungan Elastic Beanstalk di **Titik Akhir** dan lingkungan berisi penyeimbang beban ELB, Elastic Load Balancing hanya merutekan kueri ke Instans Amazon EC2 yang sehat dan terdaftar dengan penyeimbang beban. (Lingkungan secara otomatis berisi penyeimbang beban ELB jika mencakup lebih dari satu Instans Amazon EC2.) Jika Anda mengatur **Evaluasi kondisi target** ke **Ya** dan Instans Amazon EC2 atau penyeimbang beban tidak ada yang sehat, Route 53 merutekan kueri ke sumber daya lain sehat yang tersedia, jika ada.
Jika lingkungan berisi contoh Instans Amazon EC2 tunggal, tidak ada persyaratan khusus.
**penyeimbang beban ELB**
Perilaku pemeriksaan kondisi tergantung jenis penyeimbang beban:
+ **Classic Load Balancer** – Jika Anda menentukan Classic Load Balancer ELB di **Titik akhir**, Elastic Load Balancing merutekan kueri hanya ke instans Amazon EC2 sehat yang terdaftar dengan penyeimbang beban. Jika Anda menyetel **Evaluasi kondisi target** ke **Ya** dan tidak ada instans EC2 yang sehat atau penyeimbang beban itu sendiri tidak sehat, Route 53 merutekan kueri ke sumber daya lain.
+ **Aplikasi dan Penyeimbang Beban Jaringan** – Jika Anda menentukan Aplikasi ELB atau Penyeimbang Beban Jaringan dan Anda menyetel **Evaluasi kondisi target** ke **Ya**, Route 53 merutekan kueri ke penyeimbang beban berdasarkan kondisi grup target yang terkait dengan penyeimbang beban:
+ Agar Aplikasi atau Network Load Balancer dianggap sehat, kelompok sasaran yang berisi target harus mengandung setidaknya satu target yang sehat. Jika setiap kelompok target hanya berisi target yang tidak sehat, penyeimbang beban dianggap tidak sehat, dan Route 53 merutekan permintaan ke sumber daya lainnya.
+ Grup target yang tidak memiliki target terdaftar dianggap tidak sehat.
Bila Anda membuat penyeimbang beban, Anda mengonfigurasi pengaturan untuk pemeriksaan kondisi Elastic Load Balancing; bukan pemeriksaan kondisi Route 53, tetapi melakukan fungsi serupa. Tidak membuat pemeriksaan kondisi Route 53 untuk Instans EC2 yang Anda daftarkan dengan penyeimbang beban ELB.
**Bucket S3**
Tidak ada persyaratan khusus untuk pengaturan **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah bucket S3.
**Titik akhir antarmuka Amazon VPC**
Tidak ada persyaratan khusus untuk pengaturan **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah antarmuka Amazon VPC.
**Catatan lain di zona yang di-hosting**
Jika AWS sumber daya yang Anda tentukan di **Endpoint** adalah rekaman atau grup catatan (misalnya, grup catatan tertimbang) tetapi bukan catatan alias lain, sebaiknya Anda mengaitkan pemeriksaan kesehatan dengan semua catatan di titik akhir. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda menghilangkan pemeriksaan kondisi?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan primer dan sekunder.
# Nilai khusus untuk catatan geolokasi
Saat Anda membuat catatan geolokasi, Anda menentukan nilai berikut.
**Topics**
+ [Kebijakan perutean](#rrsets-values-geo-routing-policy)
+ [Nama catatan](#rrsets-values-geo-name)
+ [Tipe catatan](#rrsets-values-geo-type)
+ [TTL (detik)](#rrsets-values-geo-ttl)
+ [Menilai/Merutekan lalu lintas](#rrsets-values-geo-value)
+ [Lokasi](#rrsets-values-geo-location)
+ [Negara bagian AS](#rrsets-values-geo-sublocation)
+ [Pemeriksaan kondisi](#rrsets-values-geo-associate-with-health-check)
+ [ID catatan](#rrsets-values-geo-set-id)
## Kebijakan perutean
Pilih **Geolocation** (Geolokasi).
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama**.
Masukkan nama yang sama untuk semua catatan dalam grup catatan geolokasi.
Untuk informasi selengkapnya tentang nama rekaman, lihat[Nama catatan](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai yang sama untuk semua catatan dalam grup catatan geolokasi.
## TTL (detik)
Jumlah waktu, dalam detik, yang Anda inginkan untuk resolver rekursif DNS untuk menyimpan informasi tentang catatan ini dalam cache. Jika Anda menentukan nilai yang lebih lama (misalnya, 172.800 detik, atau dua hari), Anda mengurangi jumlah panggilan yang harus dilakukan oleh resolver rekursif DNS ke Route 53 untuk mendapatkan informasi terbaru dalam catatan ini. Ini memiliki efek mengurangi latensi dan mengurangi tagihan Anda untuk layanan Route 53. Untuk informasi selengkapnya, lihat [Cara Amazon Route 53 merutekan lalu lintas untuk domain Anda](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Namun, jika Anda menentukan nilai yang lebih lama untuk TTL, diperlukan waktu lebih lama agar perubahan pada catatan (misalnya, alamat IP baru) diterapkan karena resolver rekursif menggunakan nilai dalam cache mereka untuk waktu yang lebih lama sebelum mereka meminta Route 53 untuk informasi terakhir. Jika Anda mengubah setelan untuk domain atau subdomain yang sudah digunakan, sebaiknya tentukan dulu nilai yang lebih pendek, seperti 300 detik, dan tingkatkan nilainya setelah mengonfirmasi bahwa pengaturan baru sudah benar.
Jika Anda mengaitkan catatan ini dengan pemeriksaan kondisi, sebaiknya tentukan TTL 60 detik atau kurang sehingga klien merespons dengan cepat perubahan status kondisi.
## Menilai/Merutekan lalu lintas
Pilih **IP address or another value depending on the record type** (Alamat IP atau nilai lain tergantung jenis catatan). Masukkan nilai yang sesuai untuk nilai **Jenis catatan**. Untuk semua jenis kecuali **CNAME**, Anda dapat memasukkan lebih dari satu nilai. Masukkan setiap nilai pada baris terpisah.
Anda dapat merutekan lalu lintas ke, atau menentukan nilai berikut:
+ **A — IPv4 alamat**
+ **AAAA — alamat IPv6 **
+ **CAA - Otorisasi Otoritas Sertifikat**
+ **CNAME — Nama kanonik**
+ **MX - Pertukaran surat**
+ **NAPTR - Penunjuk Otoritas Nama**
+ **PTR — Penunjuk**
+ **SPF - Kerangka Kebijakan Pengirim**
+ **SRV - Pencari lokasi layanan**
+ **TXT - Teks**
Untuk informasi selengkapnya tentang nilai di atas, lihat [nilai umum untuk Value/Route lalu lintas ke](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Lokasi
Saat Anda mengonfigurasi Route 53 untuk merespons kueri DNS berdasarkan lokasi asal kueri, pilih benua atau negara yang Anda inginkan agar Route 53 merespons dengan pengaturan dalam catatan ini. Jika Anda ingin Route 53 merespons kueri DNS untuk masing-masing negara bagian di Amerika Serikat, pilih **United States** (Amerika Serikat) dari daftar **Location** (Lokasi), lalu pilih negara bagian di bagian grup **Sublocation** (Sublokasi).
Untuk zona host pribadi, pilih benua, negara, atau sub-divisi Wilayah AWS yang paling dekat dengan tempat sumber daya Anda berada. Misalnya, jika sumber daya Anda ada di us-east-1, Anda dapat menentukan Amerika Utara, Amerika Serikat, atau Virginia.
**penting**
Kami merekomendasikan agar Anda membuat satu data geolokasi yang memiliki nilai **Default** untuk **Lokasi**. Ini mencakup lokasi geografis yang catatannya belum Anda buat dan alamat IP yang lokasinya tidak dapat diidentifikasi oleh Route 53.
Anda tidak dapat membuat catatan nongeolokasi yang memiliki nilai yang sama untuk **Nama catatan** dan **Jenis catatan** sebagai catatan geolokasi.
Untuk informasi selengkapnya, lihat [Perutean geolokasi](routing-policy-geo.md).
Berikut adalah negara-negara yang Amazon Route 53 kaitkan dengan setiap benua. Kode negara berasal dari ISO 3166. Untuk informasi lebih lanjut, lihat artikel Wikipedia [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2):
**Afrika (AF)**
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW
**Antartika (AN)**
AQ, GS, TF
**Asia (AS)**
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE
**Eropa (Uni Eropa)**
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK
Beberapa penyedia menganggap TR berada di Asia dan alamat IP akan mencerminkan hal itu.
**Amerika Utara (NA)**
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI
**Oseania (OC)**
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS
**Amerika Selatan (SA)**
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE
**catatan**
Route 53 tidak mendukung pembuatan catatan geolokasi untuk negara-negara berikut: Pulau Bouvet (BV), Pulau Natal (CX), Sahara Barat (EH), dan Pulau dan Kepulauan Heard (HM). McDonald Tidak ada data yang tersedia mengenai alamat IP untuk negara-negara ini.
## Negara bagian AS
Jika Anda mengonfigurasi Route 53 untuk merespons permintaan DNS berdasarkan keadaan Amerika Serikat tempat asal kueri, pilih negara dari daftar **Negara bagian AS**. Wilayah Amerika Serikat (misalnya, Puerto Riko) terdaftar sebagai negara di daftar **Lokasi**.
**penting**
Beberapa alamat IP dikaitkan dengan Amerika Serikat, tetapi tidak dengan negara bagian individual. Jika Anda membuat catatan untuk semua negara bagian di Amerika Serikat, kami menyarankan Anda juga membuat catatan untuk Amerika Serikat untuk merutekan kueri untuk alamat IP yang tidak terkait ini. Jika Anda tidak membuat catatan untuk Amerika Serikat, Route 53 merespons kueri DNS dari alamat IP Amerika Serikat yang tidak terkait dengan pengaturan dari catatan geolokasi default (jika Anda membuatnya) atau dengan respons "tidak ada jawaban".
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Mengevaluasi Kesehatan Target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias latensi, alias berbasis IP, atau catatan alias tertimbang. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama Domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama Domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
Untuk catatan geolokasi, jika titik akhir tidak sehat, Route 53 mencari catatan untuk Wilayah geografis terkait yang lebih besar. Misalnya, Anda memiliki catatan untuk negara bagian di Amerika Serikat, Amerika Serikat, Amerika Utara, dan untuk semua lokasi (**Lokasi** adalah **Default**). Jika titik akhir untuk catatan negara bagian tidak sehat, Route 53 memeriksa catatan untuk Amerika Serikat, Amerika Utara, dan untuk semua lokasi, dalam urutan itu, hingga menemukan catatan yang memiliki titik akhir yang sehat. Jika semua rekaman yang berlaku tidak sehat, termasuk catatan untuk semua lokasi, Route 53 merespons kueri DNS menggunakan nilai catatan untuk wilayah geografis terkecil.
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan ini dalam grup catatan geolokasi.
# Nilai khusus untuk catatan alias geolokasi
Saat Anda membuat catatan alias geolokasi, Anda menentukan nilai berikut.
Untuk informasi selengkapnya, lihat [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Kebijakan perutean](#rrsets-values-geo-alias-routing-policy)
+ [Nama catatan](#rrsets-values-geo-alias-name)
+ [Tipe catatan](#rrsets-values-geo-alias-type)
+ [Nilai/Rutekan lalu lintas ke](#rrsets-values-geo-alias-alias-target)
+ [Lokasi](#rrsets-values-geo-alias-location)
+ [Negara bagian AS](#rrsets-values-geo-alias-sublocation)
+ [Pemeriksaan kondisi](#rrsets-values-geo-alias-associate-with-health-check)
+ [Mengevaluasi Kondisi Target](#rrsets-values-geo-alias-evaluate-target-health)
+ [ID catatan](#rrsets-values-geo-alias-set-id)
## Kebijakan perutean
Pilih **Geolocation** (Geolokasi).
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama catatan**.
Masukkan nama yang sama untuk semua catatan dalam grup catatan geolokasi.
Untuk informasi selengkapnya tentang nama rekaman, lihat[Nama catatan](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai yang berlaku berdasarkan AWS sumber daya yang Anda rutekan lalu lintas. Pilih nilai yang sama untuk semua catatan dalam grup catatan geolokasi:
**API regional kustom API Gateway atau API yang dioptimalkan edge**
Pilih **A — IPv4 alamat**.
**Titik akhir antarmuka Amazon VPC**
Pilih **A — IPv4 alamat**.
**CloudFront distribusi**
Pilih **A — IPv4 alamat**.
Jika IPv6 diaktifkan untuk distribusi, buat dua catatan, satu dengan nilai **A — IPv4 alamat** untuk **Jenis**, dan satu dengan nilai **AAAA — IPv6 ** alamat.
**Layanan Pelari Aplikasi**
Select **A — IPv4 alamat**
**Lingkungan Elastic Beanstalk yang memiliki subdomain regional**
Select **A — IPv4 alamat**
**Penyeimbang beban ELB**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Buket Amazon S3**
Select **A — IPv4 alamat**
**OpenSearch Layanan**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Catatan lain di zona yang di-hosting ini**
Pilih jenis catatan yang Anda buatkan alias. Semua jenis didukung kecuali **NS** dan **SOA**.
Jika Anda membuat catatan alias yang memiliki nama yang sama sebagai zona yang di-hosting (dikenal sebagai *zone apex*), Anda tidak dapat merutekan lalu lintas ke catatan dengan nilai **Jenis** adalah **CNAME**. Ini karena catatan alias harus memiliki jenis yang sama dengan catatan yang Anda tuju, dan membuat catatan CNAME untuk Zone Apex tidak didukung bahkan untuk catatan alias.
## Nilai/Rutekan lalu lintas ke
Nilai yang Anda pilih dari daftar atau yang Anda ketik di bidang tergantung pada AWS sumber daya yang Anda rutekan lalu lintas.
Untuk informasi tentang AWS sumber daya apa yang dapat Anda targetkan, lihat[Menilai/Merutekan lalu lintas](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Untuk informasi selengkapnya tentang cara mengonfigurasi Route 53 untuk merutekan lalu lintas ke AWS sumber daya tertentu, lihat[Merutekan lalu lintas internet ke sumber daya Anda AWS](routing-to-aws-resources.md).
## Lokasi
Saat Anda mengonfigurasi Route 53 untuk merespons kueri DNS berdasarkan lokasi asal kueri, pilih benua atau negara yang Anda inginkan agar Route 53 merespons dengan pengaturan dalam catatan ini. Jika Anda ingin Route 53 merespons kueri DNS untuk masing-masing negara bagian di Amerika Serikat, pilih **United States** (Amerika Serikat) dari daftar **Location** (Lokasi), lalu pilih negara bagian dari daftar **U.S. states** (negara bagian AS).
Untuk zona host pribadi, pilih benua, negara, atau sub-divisi Wilayah AWS yang paling dekat dengan tempat sumber daya Anda berada. Misalnya, jika sumber daya Anda ada di us-east-1, Anda dapat menentukan Amerika Utara, Amerika Serikat, atau Virginia.
**penting**
Kami merekomendasikan agar Anda membuat satu data geolokasi yang memiliki nilai **Default** untuk **Lokasi**. Ini mencakup lokasi geografis yang catatannya belum Anda buat dan alamat IP yang lokasinya tidak dapat diidentifikasi oleh Route 53.
Anda tidak dapat membuat catatan nongeolokasi yang memiliki nilai yang sama untuk **Nama catatan** dan **Jenis catatan** sebagai catatan geolokasi.
Untuk informasi selengkapnya, lihat [Perutean geolokasi](routing-policy-geo.md).
Berikut adalah negara-negara yang Amazon Route 53 kaitkan dengan setiap benua. Kode negara berasal dari ISO 3166. Untuk informasi lebih lanjut, lihat artikel Wikipedia [ISO 3166-1 alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2):
**Afrika (AF)**
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW
**Antartika (AN)**
AQ, GS, TF
**Asia (AS)**
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE
**Eropa (Uni Eropa)**
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK
Beberapa penyedia menganggap TR berada di Asia dan alamat IP akan mencerminkan hal itu.
**Amerika Utara (NA)**
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI
**Oseania (OC)**
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS
**Amerika Selatan (SA)**
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE
**catatan**
Route 53 tidak mendukung pembuatan catatan geolokasi untuk negara-negara berikut: Pulau Bouvet (BV), Pulau Natal (CX), Sahara Barat (EH), dan Pulau dan Kepulauan Heard (HM). McDonald Tidak ada data yang tersedia mengenai alamat IP untuk negara-negara ini.
## Negara bagian AS
Jika Anda mengonfigurasi Route 53 untuk merespons permintaan DNS berdasarkan keadaan Amerika Serikat tempat asal kueri, pilih negara dari daftar **Negara bagian AS**. Wilayah Amerika Serikat (misalnya, Puerto Riko) terdaftar sebagai negara di daftar **Lokasi**.
**penting**
Beberapa alamat IP dikaitkan dengan Amerika Serikat, tetapi tidak dengan negara bagian individual. Jika Anda membuat catatan untuk semua negara bagian di Amerika Serikat, kami menyarankan Anda juga membuat catatan untuk Amerika Serikat untuk merutekan kueri untuk alamat IP yang tidak terkait ini. Jika Anda tidak membuat catatan untuk Amerika Serikat, Route 53 merespons kueri DNS dari alamat IP Amerika Serikat yang tidak terkait dengan pengaturan dari catatan geolokasi default (jika Anda membuatnya) atau dengan respons "tidak ada jawaban".
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Mengevaluasi kesehatan target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias latensi, alias berbasis IP, atau catatan alias tertimbang. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
Untuk catatan geolokasi, jika titik akhir tidak sehat, Route 53 mencari catatan untuk Wilayah geografis terkait yang lebih besar. Misalnya, Anda memiliki catatan untuk negara bagian di Amerika Serikat, Amerika Serikat, Amerika Utara, dan untuk semua lokasi (**Lokasi** adalah **Default**). Jika titik akhir untuk catatan negara bagian tidak sehat, Route 53 memeriksa catatan untuk Amerika Serikat, Amerika Utara, dan untuk semua lokasi, dalam urutan itu, hingga menemukan catatan yang memiliki titik akhir yang sehat. Jika semua rekaman yang berlaku tidak sehat, termasuk catatan untuk semua lokasi, Route 53 merespons kueri DNS menggunakan nilai catatan untuk wilayah geografis terkecil.
## Mengevaluasi Kondisi Target
Pilih **Ya** jika Anda ingin Route 53 untuk menentukan apakah untuk menanggapi permintaan DNS menggunakan catatan ini dengan memeriksa kondisi sumber daya yang ditentukan oleh **Titik akhir**.
Perhatikan hal-hal berikut:
**API Gateway khusus regional APIs dan dioptimalkan tepi APIs**
Tidak ada persyaratan khusus untuk menyetel **Evaluasi kesehatan target** ke **Ya** ketika titik akhir adalah API Regional kustom API Gateway API atau API yang dioptimalkan tepi.
**CloudFront distribusi**
Anda tidak dapat menetapkan **Evaluasi kesehatan target** ke **Ya** ketika titik akhir adalah CloudFront distribusi.
**Lingkungan Elastic Beanstalk yang memiliki subdomain regionalisasi**
Jika Anda menentukan lingkungan Elastic Beanstalk di **Titik Akhir** dan lingkungan berisi penyeimbang beban ELB, Elastic Load Balancing hanya merutekan kueri ke Instans Amazon EC2 yang sehat dan terdaftar dengan penyeimbang beban. (Lingkungan secara otomatis berisi penyeimbang beban ELB jika mencakup lebih dari satu Instans Amazon EC2.) Jika Anda mengatur **Evaluasi kondisi target** ke **Ya** dan Instans Amazon EC2 atau penyeimbang beban tidak ada yang sehat, Route 53 merutekan kueri ke sumber daya lain sehat yang tersedia, jika ada.
Jika lingkungan berisi contoh Instans Amazon EC2 tunggal, tidak ada persyaratan khusus.
**penyeimbang beban ELB**
Perilaku pemeriksaan kondisi tergantung jenis penyeimbang beban:
+ **Classic Load Balancer** – Jika Anda menentukan Classic Load Balancer ELB di **Titik akhir**, Elastic Load Balancing merutekan kueri hanya ke instans Amazon EC2 sehat yang terdaftar dengan penyeimbang beban. Jika Anda menyetel **Evaluasi kondisi target** ke **Ya** dan tidak ada instans EC2 yang sehat atau penyeimbang beban itu sendiri tidak sehat, Route 53 merutekan kueri ke sumber daya lain.
+ **Aplikasi dan Penyeimbang Beban Jaringan** – Jika Anda menentukan Aplikasi ELB atau Penyeimbang Beban Jaringan dan Anda menyetel **Evaluasi kondisi target** ke **Ya**, Route 53 merutekan kueri ke penyeimbang beban berdasarkan kondisi grup target yang terkait dengan penyeimbang beban:
+ Agar Aplikasi atau Penyeimbang Beban Jaringan dianggap sehat, setiap kelompok target yang berisi target harus berisi setidaknya satu target yang sehat. Jika setiap kelompok target hanya berisi target yang tidak sehat, penyeimbang beban dianggap tidak sehat, dan Route 53 merutekan permintaan ke sumber daya lainnya.
+ Grup target yang tidak memiliki target terdaftar dianggap tidak sehat.
Bila Anda membuat penyeimbang beban, Anda mengonfigurasi pengaturan untuk pemeriksaan kondisi Elastic Load Balancing; bukan pemeriksaan kondisi Route 53, tetapi melakukan fungsi serupa. Tidak membuat pemeriksaan kondisi Route 53 untuk Instans EC2 yang Anda daftarkan dengan penyeimbang beban ELB.
**Bucket S3**
Tidak ada persyaratan khusus untuk pengaturan **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah bucket S3.
**Titik akhir antarmuka Amazon VPC**
Tidak ada persyaratan khusus untuk pengaturan **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah antarmuka Amazon VPC.
**Catatan lain di zona yang di-hosting**
Jika AWS sumber daya yang Anda tentukan di **Endpoint** adalah rekaman atau grup catatan (misalnya, grup catatan tertimbang) tetapi bukan catatan alias lain, sebaiknya Anda mengaitkan pemeriksaan kesehatan dengan semua catatan di titik akhir. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda menghilangkan pemeriksaan kondisi?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan ini dalam grup catatan geolokasi.
# Nilai khusus untuk catatan geoproximity
Saat Anda membuat catatan geoproximity, Anda menentukan nilai berikut.
**Topics**
+ [Kebijakan perutean](#rrsets-values-geoprox-routing-policy)
+ [Nama catatan](#rrsets-values-geoprox-name)
+ [Tipe catatan](#rrsets-values-geoprox-type)
+ [TTL (detik)](#rrsets-values-geoprox-ttl)
+ [Menilai/Merutekan lalu lintas](#rrsets-values-geoprox-value)
+ [Lokasi titik akhir](#rrsets-values-geoprox-endpoint-location)
+ [Bias](#rrsets-values-geoprox-bias)
+ [Pemeriksaan kondisi](#rrsets-values-geoprox-associate-with-health-check)
+ [ID catatan](#rrsets-values-geoprox-set-id)
## Kebijakan perutean
Pilih **Geoproximity**.
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama**.
Masukkan nama yang sama untuk semua catatan dalam grup catatan geoproximity.
Untuk informasi selengkapnya tentang nama rekaman, lihat[Nama catatan](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai yang sama untuk semua catatan dalam kelompok catatan geoproximity.
## TTL (detik)
Jumlah waktu, dalam detik, yang Anda inginkan untuk resolver rekursif DNS untuk menyimpan informasi tentang catatan ini dalam cache. Jika Anda menentukan nilai yang lebih lama (misalnya, 172.800 detik, atau dua hari), Anda mengurangi jumlah panggilan yang harus dilakukan oleh resolver rekursif DNS ke Route 53 untuk mendapatkan informasi terbaru dalam catatan ini. Ini memiliki efek mengurangi latensi dan mengurangi tagihan Anda untuk layanan Route 53. Untuk informasi selengkapnya, lihat [Cara Amazon Route 53 merutekan lalu lintas untuk domain Anda](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Namun, jika Anda menentukan nilai yang lebih lama untuk TTL, diperlukan waktu lebih lama agar perubahan pada catatan (misalnya, alamat IP baru) diterapkan karena resolver rekursif menggunakan nilai dalam cache mereka untuk waktu yang lebih lama sebelum mereka meminta Route 53 untuk informasi terakhir. Jika Anda mengubah setelan untuk domain atau subdomain yang sudah digunakan, sebaiknya tentukan dulu nilai yang lebih pendek, seperti 300 detik, dan tingkatkan nilainya setelah mengonfirmasi bahwa pengaturan baru sudah benar.
Jika Anda mengaitkan catatan ini dengan pemeriksaan kondisi, sebaiknya tentukan TTL 60 detik atau kurang sehingga klien merespons dengan cepat perubahan status kondisi.
## Menilai/Merutekan lalu lintas
Pilih **IP address or another value depending on the record type** (Alamat IP atau nilai lain tergantung jenis catatan). Masukkan nilai yang sesuai untuk nilai **Jenis catatan**. Untuk semua jenis kecuali **CNAME**, Anda dapat memasukkan lebih dari satu nilai. Masukkan setiap nilai pada baris terpisah.
Anda dapat merutekan lalu lintas ke, atau menentukan nilai berikut:
+ **A — IPv4 alamat**
+ **AAAA — alamat IPv6 **
+ **CAA - Otorisasi Otoritas Sertifikat**
+ **CNAME — Nama kanonik**
+ **MX - Pertukaran surat**
+ **NAPTR - Penunjuk Otoritas Nama**
+ **PTR — Penunjuk**
+ **SPF - Kerangka Kebijakan Pengirim**
+ **SRV - Pencari lokasi layanan**
+ **TXT - Teks**
Untuk informasi selengkapnya tentang nilai di atas, lihat [nilai umum untuk Value/Route lalu lintas ke](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Lokasi titik akhir
Anda dapat menentukan lokasi titik akhir sumber daya dengan menggunakan salah satu dari berikut ini:
**Koordinat kustom**
Tentukan garis bujur dan garis lintang untuk area geopgrafi.
**Wilayah AWS**
Pilih Wilayah yang tersedia dari daftar **Lokasi**.
Untuk informasi selengkapnya tentang Wilayah, lihat [Infrastruktur AWS Global](https://aws.amazon.com/about-aws/global-infrastructure/).
**AWS Grup Zona Lokal**
Pilih Grup Zona Lokal yang tersedia dari daftar **Lokasi**.
Untuk informasi selengkapnya tentang Local Zones, lihat [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) di *Panduan Pengguna AWS Local Zones*. Grup Zona lokal biasanya adalah Zona Lokal tanpa karakter akhir. Misalnya, jika Zona Lokal adalah `us-east-1-bue-1a` Grup Zona Lokal`us-east-1-bue-1`.
Anda juga dapat mengidentifikasi Grup Local Zones untuk Zona Lokal tertentu dengan menggunakan perintah [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html)CLI:
```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```
Perintah ini mengembalikan:`"GroupName": "us-west-2-den-1"`, menentukan bahwa Zona Lokal `us-west-2-den-1a` milik Grup `us-west-2-den-1` Zona Lokal.
Anda tidak dapat membuat rekaman non-geoproximity yang memiliki nilai yang sama untuk **nama Rekam dan jenis Rekam** **sebagai catatan** geoproximity.
Anda juga tidak dapat membuat dua kumpulan rekaman sumber daya geoproximity yang menentukan lokasi yang sama untuk nama rekaman dan jenis rekaman yang sama.
## Bias
Bias memperluas atau menyusutkan wilayah geografis dari mana Rute 53 merutekan lalu lintas ke sumber daya. Bias positif memperluas area, dan bias negatif menyusutkannya. Untuk informasi selengkapnya, lihat [Bagaimana Amazon Route 53 menggunakan bias untuk merutekan lalu lintas](routing-policy-geoproximity.md#routing-policy-geoproximity-bias).
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Mengevaluasi Kesehatan Target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias geoproximity, alias latensi, alias berbasis IP, atau catatan alias tertimbang. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama Domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama Domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
Untuk catatan geoproximity, jika titik akhir tidak sehat, Route 53 mencari titik akhir terdekat yang masih sehat.
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan ini dalam kelompok catatan geoproximity.
# Nilai khusus untuk catatan alias geoproximity
Saat Anda membuat catatan alias geoproximity, Anda menentukan nilai berikut.
Untuk informasi selengkapnya, lihat [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Kebijakan perutean](#rrsets-values-geoprox-alias-routing-policy)
+ [Nama catatan](#rrsets-values-geoprox-alias-name)
+ [Tipe catatan](#rrsets-values-geoprox-alias-type)
+ [Nilai/Rutekan lalu lintas ke](#rrsets-values-geoprox-alias-alias-target)
+ [Lokasi titik akhir](#rrsets-values-geoprox-alias-endpoint-location)
+ [Bias](#rrsets-values-geoprox-alias-bias)
+ [Pemeriksaan kondisi](#rrsets-values-geoprox-alias-associate-with-health-check)
+ [Mengevaluasi Kondisi Target](#rrsets-values-geoprox-alias-evaluate-target-health)
+ [ID catatan](#rrsets-values-geoprox-alias-set-id)
## Kebijakan perutean
Pilih **Geoproximity**.
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama catatan**.
Masukkan nama yang sama untuk semua catatan dalam grup catatan geoproximity.
Untuk informasi selengkapnya tentang nama rekaman, lihat[Nama catatan](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai yang berlaku berdasarkan AWS sumber daya yang Anda rutekan lalu lintas. Pilih nilai yang sama untuk semua catatan dalam grup catatan geoproximity:
**API regional kustom API Gateway atau API yang dioptimalkan edge**
Pilih **A — IPv4 alamat**.
**Titik akhir antarmuka Amazon VPC**
Pilih **A — IPv4 alamat**.
**CloudFront distribusi**
Pilih **A — IPv4 alamat**.
Jika IPv6 diaktifkan untuk distribusi, buat dua catatan, satu dengan nilai **A — IPv4 alamat** untuk **Jenis**, dan satu dengan nilai **AAAA — IPv6 ** alamat.
**Layanan Pelari Aplikasi**
Select **A — IPv4 alamat**
**Lingkungan Elastic Beanstalk yang memiliki subdomain regional**
Select **A — IPv4 alamat**
**Penyeimbang beban ELB**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Buket Amazon S3**
Select **A — IPv4 alamat**
**OpenSearch Layanan**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Catatan lain di zona yang di-hosting ini**
Pilih jenis catatan yang Anda buatkan alias. Semua jenis didukung kecuali **NS** dan **SOA**.
Jika Anda membuat catatan alias yang memiliki nama yang sama sebagai zona yang di-hosting (dikenal sebagai *zone apex*), Anda tidak dapat merutekan lalu lintas ke catatan dengan nilai **Jenis** adalah **CNAME**. Ini karena catatan alias harus memiliki jenis yang sama dengan catatan yang Anda tuju, dan membuat catatan CNAME untuk Zone Apex tidak didukung bahkan untuk catatan alias.
## Nilai/Rutekan lalu lintas ke
Nilai yang Anda pilih dari daftar atau yang Anda ketik di bidang tergantung pada AWS sumber daya yang Anda rutekan lalu lintas.
Untuk informasi tentang AWS sumber daya apa yang dapat Anda targetkan, lihat[Menilai/Merutekan lalu lintas](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Untuk informasi selengkapnya tentang cara mengonfigurasi Route 53 untuk merutekan lalu lintas ke AWS sumber daya tertentu, lihat[Merutekan lalu lintas internet ke sumber daya Anda AWS](routing-to-aws-resources.md).
## Lokasi titik akhir
Anda dapat menentukan lokasi titik akhir sumber daya dengan menggunakan salah satu dari berikut ini:
**Koordinat kustom**
Tentukan garis bujur dan garis lintang untuk area geopgrafi.
**Wilayah AWS**
Pilih Wilayah yang tersedia dari daftar **Lokasi**.
Untuk informasi selengkapnya tentang Wilayah, lihat [Infrastruktur AWS Global](https://aws.amazon.com/about-aws/global-infrastructure/).
**AWS Grup Zona Lokal**
Pilih Wilayah Zona Lokal yang tersedia dari daftar **Lokasi**.
Untuk informasi selengkapnya tentang Local Zones, lihat [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) di *Panduan Pengguna AWS Local Zones*. Grup Zona lokal biasanya adalah Zona Lokal tanpa karakter akhir. Misalnya, jika Zona Lokal adalah `us-east-1-bue-1a` Grup Zona Lokal`us-east-1-bue-1`.
Anda juga dapat mengidentifikasi Grup Local Zones untuk Zona Lokal tertentu dengan menggunakan perintah [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html)CLI:
```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```
Perintah ini mengembalikan:`"GroupName": "us-west-2-den-1"`, menentukan bahwa Zona Lokal `us-west-2-den-1a` milik Grup `us-west-2-den-1` Zona Lokal.
Anda tidak dapat membuat rekaman non-geoproximity yang memiliki nilai yang sama untuk **nama Rekam dan jenis Rekam** **sebagai catatan** geoproximity.
Anda juga tidak dapat membuat dua kumpulan rekaman sumber daya geoproximity yang menentukan lokasi yang sama untuk nama rekaman dan jenis rekaman yang sama.
Untuk informasi lebih lanjut, available-local-zones lihat.html
## Bias
Bias memperluas atau menyusutkan wilayah geografis dari mana Rute 53 merutekan lalu lintas ke sumber daya. Bias positif memperluas area, dan bias negatif menyusutkannya. Untuk informasi selengkapnya, lihat [Bagaimana Amazon Route 53 menggunakan bias untuk merutekan lalu lintas](routing-policy-geoproximity.md#routing-policy-geoproximity-bias).
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Mengevaluasi kesehatan target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias geoproximity, alias latensi, alias berbasis IP, atau catatan alias tertimbang. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
Untuk catatan geoproximity, jika titik akhir tidak sehat, Route 53 mencari titik akhir terdekat yang masih sehat.
## Mengevaluasi Kondisi Target
Pilih **Ya** jika Anda ingin Route 53 untuk menentukan apakah untuk menanggapi permintaan DNS menggunakan catatan ini dengan memeriksa kondisi sumber daya yang ditentukan oleh **Titik akhir**.
Perhatikan hal-hal berikut:
**API Gateway khusus regional APIs dan dioptimalkan tepi APIs**
Tidak ada persyaratan khusus untuk menyetel **Evaluasi kesehatan target** ke **Ya** ketika titik akhir adalah API Regional kustom API Gateway API atau API yang dioptimalkan tepi.
**CloudFront distribusi**
Anda tidak dapat menetapkan **Evaluasi kesehatan target** ke **Ya** ketika titik akhir adalah CloudFront distribusi.
**Lingkungan Elastic Beanstalk yang memiliki subdomain regionalisasi**
Jika Anda menentukan lingkungan Elastic Beanstalk di **Titik Akhir** dan lingkungan berisi penyeimbang beban ELB, Elastic Load Balancing hanya merutekan kueri ke Instans Amazon EC2 yang sehat dan terdaftar dengan penyeimbang beban. (Lingkungan secara otomatis berisi penyeimbang beban ELB jika mencakup lebih dari satu Instans Amazon EC2.) Jika Anda mengatur **Evaluasi kondisi target** ke **Ya** dan Instans Amazon EC2 atau penyeimbang beban tidak ada yang sehat, Route 53 merutekan kueri ke sumber daya lain sehat yang tersedia, jika ada.
Jika lingkungan berisi contoh Instans Amazon EC2 tunggal, tidak ada persyaratan khusus.
**penyeimbang beban ELB**
Perilaku pemeriksaan kondisi tergantung jenis penyeimbang beban:
+ **Classic Load Balancer** – Jika Anda menentukan Classic Load Balancer ELB di **Titik akhir**, Elastic Load Balancing merutekan kueri hanya ke instans Amazon EC2 sehat yang terdaftar dengan penyeimbang beban. Jika Anda menyetel **Evaluasi kondisi target** ke **Ya** dan tidak ada instans EC2 yang sehat atau penyeimbang beban itu sendiri tidak sehat, Route 53 merutekan kueri ke sumber daya lain.
+ **Aplikasi dan Penyeimbang Beban Jaringan** – Jika Anda menentukan Aplikasi ELB atau Penyeimbang Beban Jaringan dan Anda menyetel **Evaluasi kondisi target** ke **Ya**, Route 53 merutekan kueri ke penyeimbang beban berdasarkan kondisi grup target yang terkait dengan penyeimbang beban:
+ Agar Aplikasi atau Penyeimbang Beban Jaringan dianggap sehat, setiap kelompok target yang berisi target harus berisi setidaknya satu target yang sehat. Jika setiap kelompok target hanya berisi target yang tidak sehat, penyeimbang beban dianggap tidak sehat, dan Route 53 merutekan permintaan ke sumber daya lainnya.
+ Grup target yang tidak memiliki target terdaftar dianggap tidak sehat.
Bila Anda membuat penyeimbang beban, Anda mengonfigurasi pengaturan untuk pemeriksaan kondisi Elastic Load Balancing; bukan pemeriksaan kondisi Route 53, tetapi melakukan fungsi serupa. Tidak membuat pemeriksaan kondisi Route 53 untuk Instans EC2 yang Anda daftarkan dengan penyeimbang beban ELB.
**Bucket S3**
Tidak ada persyaratan khusus untuk pengaturan **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah bucket S3.
**Titik akhir antarmuka Amazon VPC**
Tidak ada persyaratan khusus untuk pengaturan **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah antarmuka Amazon VPC.
**Catatan lain di zona yang di-hosting**
Jika AWS sumber daya yang Anda tentukan di **Endpoint** adalah rekaman atau grup catatan (misalnya, grup catatan tertimbang) tetapi bukan catatan alias lain, sebaiknya Anda mengaitkan pemeriksaan kesehatan dengan semua catatan di titik akhir. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda menghilangkan pemeriksaan kondisi?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan ini dalam kelompok catatan geoproximity.
# Nilai khusus untuk catatan latensi
Saat Anda membuat data latensi, Anda menentukan nilai berikut.
**Topics**
+ [Kebijakan perutean](#rrsets-values-latency-routing-policy)
+ [Nama catatan](#rrsets-values-latency-name)
+ [Tipe catatan](#rrsets-values-latency-type)
+ [TTL (detik)](#rrsets-values-latency-ttl)
+ [Menilai/Merutekan lalu lintas](#rrsets-values-latency-value)
+ [Region](#rrsets-values-latency-region)
+ [Pemeriksaan kondisi](#rrsets-values-latency-associate-with-health-check)
+ [ID catatan](#rrsets-values-latency-set-id)
## Kebijakan perutean
Pilih **Latency** (Latensi).
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama catatan**.
Masukkan nama yang sama untuk semua catatan dalam grup catatan latensi.
Untuk informasi selengkapnya tentang nama rekaman, lihat[Nama catatan](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai untuk **Jenis** berdasarkan bagaimana Anda ingin Route 53 untuk menanggapi permintaan DNS.
Pilih nilai yang sama untuk semua rekaman dalam grup rekaman latensi.
## TTL (detik)
Jumlah waktu, dalam detik, yang Anda inginkan untuk resolver rekursif DNS untuk menyimpan informasi tentang catatan ini dalam cache. Jika Anda menentukan nilai yang lebih lama (misalnya, 172.800 detik, atau dua hari), Anda mengurangi jumlah panggilan yang harus dilakukan oleh resolver rekursif DNS ke Route 53 untuk mendapatkan informasi terbaru dalam catatan ini. Ini memiliki efek mengurangi latensi dan mengurangi tagihan Anda untuk layanan Route 53. Untuk informasi selengkapnya, lihat [Cara Amazon Route 53 merutekan lalu lintas untuk domain Anda](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Namun, jika Anda menentukan nilai yang lebih lama untuk TTL, diperlukan waktu lebih lama agar perubahan pada catatan (misalnya, alamat IP baru) diterapkan karena resolver rekursif menggunakan nilai dalam cache mereka untuk waktu yang lebih lama sebelum mereka meminta Route 53 untuk informasi terakhir. Jika Anda mengubah setelan untuk domain atau subdomain yang sudah digunakan, sebaiknya tentukan dulu nilai yang lebih pendek, seperti 300 detik, dan tingkatkan nilainya setelah mengonfirmasi bahwa pengaturan baru sudah benar.
Jika Anda mengaitkan catatan ini dengan pemeriksaan kondisi, sebaiknya tentukan TTL 60 detik atau kurang sehingga klien merespons dengan cepat perubahan status kondisi.
## Menilai/Merutekan lalu lintas
Pilih **IP address or another value depending on the record type** (Alamat IP atau nilai lain tergantung jenis catatan). Masukkan nilai yang sesuai untuk nilai **Jenis catatan**. Untuk semua jenis kecuali **CNAME**, Anda dapat memasukkan lebih dari satu nilai. Masukkan setiap nilai pada baris terpisah.
Anda dapat merutekan lalu lintas ke, atau menentukan nilai berikut:
+ **A — IPv4 alamat**
+ **AAAA — alamat IPv6 **
+ **CAA - Otorisasi Otoritas Sertifikat**
+ **CNAME — Nama kanonik**
+ **MX - Pertukaran surat**
+ **NAPTR - Penunjuk Otoritas Nama**
+ **PTR — Penunjuk**
+ **SPF - Kerangka Kebijakan Pengirim**
+ **SRV - Pencari lokasi layanan**
+ **TXT - Teks**
Untuk informasi selengkapnya tentang nilai di atas, lihat [nilai umum untuk Value/Route lalu lintas ke](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Region
Wilayah Amazon EC2 tempat sumber daya yang Anda tentukan dalam catatan ini berada. Route 53 merekomendasikan Wilayah Amazon EC2 berdasarkan nilai lainnya yang telah Anda tentukan. Ini juga berlaku untuk zona yang dihosting pribadi. Kami menyarankan Anda untuk tidak mengubah nilai ini.
Perhatikan hal-hal berikut:
+ Anda hanya dapat membuat satu catatan latensi untuk setiap Wilayah Amazon EC2.
+ Anda tidak diharuskan membuat catatan latensi untuk semua Wilayah Amazon EC2. Route 53 memilih Wilayah dengan latensi terbaik dari berbagai Wilayah yang Anda buatkan catatan latensinya.
+ Anda tidak dapat membuat rekaman nonlatensi yang memiliki nilai yang sama untuk **Nama catatan** dan **Jenis catatan** sebagai catatan latensi.
+ Jika Anda membuat catatan yang ditandai dengan Wilayah **cn-north-1**, Route 53 akan selalu merespons kueri yang berasal dari Tiongkok menggunakan catatan ini, terlepas dari latensinya.
Untuk informasi lebih lanjut tentang penggunaan catatan latensi, lihat [Perutean berbasis latensi](routing-policy-latency.md).
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Mengevaluasi kesehatan target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias latensi, alias berbasis IP, atau catatan alias tertimbang. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan ini dalam grup catatan latensi.
# Nilai khusus untuk catatan alias latensi
Saat Anda membuat catatan alias latensi, Anda menentukan nilai berikut.
Untuk informasi selengkapnya, lihat [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Kebijakan perutean](#rrsets-values-latency-alias-routing-policy)
+ [Nama catatan](#rrsets-values-latency-alias-name)
+ [Tipe catatan](#rrsets-values-latency-alias-type)
+ [Nilai/Rutekan lalu lintas ke](#rrsets-values-latency-alias-alias-target)
+ [Region](#rrsets-values-latency-alias-region)
+ [Pemeriksaan kondisi](#rrsets-values-latency-alias-associate-with-health-check)
+ [Mengevaluasi Kondisi Target](#rrsets-values-latency-alias-evaluate-target-health)
+ [ID catatan](#rrsets-values-latency-alias-set-id)
## Kebijakan perutean
Pilih **Latency** (Latensi).
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama catatan**.
Masukkan nama yang sama untuk semua catatan dalam grup catatan latensi.
Untuk informasi selengkapnya tentang nama rekaman, lihat [Nama catatan](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name)
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai yang berlaku berdasarkan AWS sumber daya yang Anda rutekan lalu lintas ke:
**API regional kustom API Gateway atau API yang dioptimalkan edge**
Pilih **A — IPv4 alamat**.
**Titik akhir antarmuka Amazon VPC**
Pilih **A — IPv4 alamat**.
**CloudFront distribusi**
Pilih **A — IPv4 alamat**.
Jika IPv6 diaktifkan untuk distribusi, buat dua catatan, satu dengan nilai **A — IPv4 alamat** untuk **Jenis**, dan satu dengan nilai **AAAA — IPv6 ** alamat.
**Layanan Pelari Aplikasi**
Select **A — IPv4 alamat**
**Lingkungan Elastic Beanstalk yang memiliki subdomain regional**
Select **A — IPv4 alamat**
**Penyeimbang beban ELB**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Buket Amazon S3**
Select **A — IPv4 alamat**
**OpenSearch Layanan**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Catatan lain di zona yang di-hosting ini**
Pilih jenis catatan yang Anda buatkan alias. Semua jenis didukung kecuali **NS** dan **SOA**.
Jika Anda membuat catatan alias yang memiliki nama yang sama sebagai zona yang di-hosting (dikenal sebagai *zone apex*), Anda tidak dapat merutekan lalu lintas ke catatan dengan nilai **Jenis** adalah **CNAME**. Ini karena catatan alias harus memiliki jenis yang sama dengan catatan yang Anda tuju, dan membuat catatan CNAME untuk Zone Apex tidak didukung bahkan untuk catatan alias.
Pilih nilai yang sama untuk semua rekaman dalam grup rekaman latensi.
## Nilai/Rutekan lalu lintas ke
Nilai yang Anda pilih dari daftar atau yang Anda ketik di bidang tergantung pada AWS sumber daya yang Anda rutekan lalu lintas.
Untuk informasi tentang AWS sumber daya yang dapat Anda targetkan, lihat [nilai umum untuk catatan alias untuk value/route lalu lintas](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Untuk informasi selengkapnya tentang cara mengonfigurasi Route 53 untuk merutekan lalu lintas ke AWS sumber daya tertentu, lihat[Merutekan lalu lintas internet ke sumber daya Anda AWS](routing-to-aws-resources.md).
## Region
Wilayah Amazon EC2 tempat sumber daya yang Anda tentukan dalam catatan ini berada. Route 53 merekomendasikan Wilayah Amazon EC2 berdasarkan nilai lainnya yang telah Anda tentukan. Ini juga berlaku untuk zona yang dihosting pribadi. Kami menyarankan Anda untuk tidak mengubah nilai ini.
Perhatikan hal-hal berikut:
+ Anda hanya dapat membuat satu catatan latensi untuk setiap Wilayah Amazon EC2.
+ Anda tidak diharuskan membuat catatan latensi untuk semua Wilayah Amazon EC2. Route 53 memilih Wilayah dengan latensi terbaik dari berbagai Wilayah yang Anda buatkan catatan latensinya.
+ Anda tidak dapat membuat rekaman nonlatensi yang memiliki nilai yang sama untuk **Nama catatan** dan **Jenis catatan** sebagai catatan latensi.
+ Jika Anda membuat catatan yang ditandai dengan Wilayah **cn-north-1**, Route 53 akan selalu merespons kueri yang berasal dari Tiongkok menggunakan catatan ini, terlepas dari latensinya.
Untuk informasi lebih lanjut tentang penggunaan catatan latensi, lihat [Perutean berbasis latensi](routing-policy-latency.md).
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Mengevaluasi kesehatan target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias latensi, alias berbasis IP, atau catatan alias tertimbang. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama Domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
## Mengevaluasi Kondisi Target
Pilih **Ya** jika Anda ingin Route 53 untuk menentukan apakah untuk menanggapi permintaan DNS menggunakan catatan ini dengan memeriksa kondisi sumber daya yang ditentukan oleh **Titik akhir**.
Perhatikan hal-hal berikut:
**API Gateway khusus regional APIs dan dioptimalkan tepi APIs**
Tidak ada persyaratan khusus untuk menyetel **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah API regional kustom API Gateway atau API yang dioptimalkan edge.
**CloudFront distribusi**
Anda tidak dapat mengatur **Evaluasi Kesehatan Target** ke **Ya** ketika titik akhir adalah CloudFront distribusi.
**Lingkungan Elastic Beanstalk yang memiliki subdomain regionalisasi**
Jika Anda menentukan lingkungan Elastic Beanstalk di **Titik Akhir** dan lingkungan berisi penyeimbang beban ELB, Elastic Load Balancing hanya merutekan kueri ke Instans Amazon EC2 yang sehat dan terdaftar dengan penyeimbang beban. (Lingkungan secara otomatis berisi penyeimbang beban ELB jika mencakup lebih dari satu Instans Amazon EC2.) Jika Anda mengatur **Evaluasi kondisi target** ke **Ya** dan Instans Amazon EC2 atau penyeimbang beban tidak ada yang sehat, Route 53 merutekan kueri ke sumber daya lain sehat yang tersedia, jika ada.
Jika lingkungan berisi contoh Instans Amazon EC2 tunggal, tidak ada persyaratan khusus.
**penyeimbang beban ELB**
Perilaku pemeriksaan kondisi tergantung jenis penyeimbang beban:
+ **Classic Load Balancer** – Jika Anda menentukan Classic Load Balancer ELB di **Titik akhir**, Elastic Load Balancing merutekan kueri hanya ke instans Amazon EC2 sehat yang terdaftar dengan penyeimbang beban. Jika Anda menyetel **Evaluasi kondisi target** ke **Ya** dan tidak ada instans EC2 yang sehat atau penyeimbang beban itu sendiri tidak sehat, Route 53 merutekan kueri ke sumber daya lain.
+ **Aplikasi dan Penyeimbang Beban Jaringan** – Jika Anda menentukan Aplikasi ELB atau Penyeimbang Beban Jaringan dan Anda menyetel **Evaluasi kondisi target** ke **Ya**, Route 53 merutekan kueri ke penyeimbang beban berdasarkan kondisi grup target yang terkait dengan penyeimbang beban:
+ Agar Aplikasi atau Penyeimbang Beban Jaringan dianggap sehat, setiap kelompok target yang berisi target harus berisi setidaknya satu target yang sehat. Jika setiap kelompok target hanya berisi target yang tidak sehat, penyeimbang beban dianggap tidak sehat, dan Route 53 merutekan permintaan ke sumber daya lainnya.
+ Grup target yang tidak memiliki target terdaftar dianggap tidak sehat.
Bila Anda membuat penyeimbang beban, Anda mengonfigurasi pengaturan untuk pemeriksaan kondisi Elastic Load Balancing; bukan pemeriksaan kondisi Route 53, tetapi melakukan fungsi serupa. Tidak membuat pemeriksaan kondisi Route 53 untuk Instans EC2 yang Anda daftarkan dengan penyeimbang beban ELB.
**Bucket S3**
Tidak ada persyaratan khusus untuk pengaturan **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah bucket S3.
**Titik akhir antarmuka Amazon VPC**
Tidak ada persyaratan khusus untuk pengaturan **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah antarmuka Amazon VPC.
**Catatan lain di zona yang di-hosting**
Jika AWS sumber daya yang Anda tentukan di **Endpoint** adalah rekaman atau grup catatan (misalnya, grup catatan tertimbang) tetapi bukan catatan alias lain, sebaiknya Anda mengaitkan pemeriksaan kesehatan dengan semua catatan di titik akhir. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda menghilangkan pemeriksaan kondisi?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan ini dalam grup catatan latensi.
# Nilai khusus untuk catatan berbasis IP
Saat Anda membuat catatan berbasis IP, Anda menentukan nilai berikut.
**catatan**
Meskipun membuat catatan berbasis IP di zona host pribadi diperbolehkan, itu tidak didukung.
**Topics**
+ [Kebijakan perutean](#rrsets-values-ipbased-routing-policy)
+ [Nama catatan](#rrsets-values-ibased-name)
+ [Jenis catatan](#rrsets-values-ibased-type)
+ [TTL (detik)](#rrsets-values-ibased-ttl)
+ [Menilai/Merutekan lalu lintas](#rrsets-values-ibased-value)
+ [Lokasi](#rrsets-values-ibased-location)
+ [Pemeriksaan kondisi](#rrsets-values-ibased-associate-with-health-check)
+ [ID catatan](#rrsets-values-ipbased-set-id)
## Kebijakan perutean
Pilih **berbasis IP**.
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama catatan**.
Masukkan nama yang sama untuk semua catatan dalam grup catatan berbasis IP.
**Catatan CNAME**
Jika Anda membuat catatan yang memiliki nilai **CNAME** untuk **Jenis catatan**, nama catatan tidak dapat sama dengan nama zona yang di-hosting.
**Karakter-karakter khusus**
Untuk informasi tentang cara menentukan karakter selain a-z, 0-9, dan - (tanda hubung) serta cara menentukan nama domain internasional, lihat [Format nama domain DNS](DomainNameFormat.md).
**Karakter wildcard **
Anda dapat menggunakan karakter tanda bintang (\$1) dalam nama. DNS memperlakukan karakter \$1 sebagai wildcard atau sebagai karakter \$1 (ASCII 42), tergantung tempat karakter muncul dalam nama. Untuk informasi selengkapnya, lihat [Menggunakan tanda bintang (\$1) dalam nama zona yang di-hosting dan catatan](DomainNameFormat.md#domain-name-format-asterisk).
## Jenis catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai untuk **Jenis** berdasarkan bagaimana Anda ingin Route 53 untuk menanggapi permintaan DNS.
Pilih nilai yang sama untuk semua catatan dalam grup catatan berbasis IP.
## TTL (detik)
Jumlah waktu, dalam detik, yang Anda inginkan untuk resolver rekursif DNS untuk menyimpan informasi tentang catatan ini dalam cache. Jika Anda menentukan nilai yang lebih lama (misalnya, 172.800 detik, atau dua hari), Anda mengurangi jumlah panggilan yang harus dilakukan oleh resolver rekursif DNS ke Route 53 untuk mendapatkan informasi terbaru dalam catatan ini. Ini memiliki efek mengurangi latensi dan mengurangi tagihan Anda untuk layanan Route 53. Untuk informasi selengkapnya, lihat [Cara Amazon Route 53 merutekan lalu lintas untuk domain Anda](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Namun, jika Anda menentukan nilai yang lebih lama untuk TTL, diperlukan waktu lebih lama agar perubahan pada catatan (misalnya, alamat IP baru) diterapkan karena resolver rekursif menggunakan nilai dalam cache mereka untuk waktu yang lebih lama sebelum mereka meminta Route 53 untuk informasi terakhir. Jika Anda mengubah setelan untuk domain atau subdomain yang sudah digunakan, sebaiknya tentukan dulu nilai yang lebih pendek, seperti 300 detik, dan tingkatkan nilainya setelah mengonfirmasi bahwa pengaturan baru sudah benar.
Jika Anda mengaitkan catatan ini dengan pemeriksaan kondisi, sebaiknya tentukan TTL 60 detik atau kurang sehingga klien merespons dengan cepat perubahan status kondisi.
## Menilai/Merutekan lalu lintas
Pilih **IP address or another value depending on the record type** (Alamat IP atau nilai lain tergantung jenis catatan). Masukkan nilai yang sesuai untuk nilai **Jenis catatan**. Untuk semua jenis kecuali **CNAME**, Anda dapat memasukkan lebih dari satu nilai. Masukkan setiap nilai pada baris terpisah.
Anda dapat merutekan lalu lintas ke, atau menentukan nilai berikut:
+ **A — IPv4 alamat**
+ **AAAA — alamat IPv6 **
+ **CAA - Otorisasi Otoritas Sertifikat**
+ **CNAME — Nama kanonik**
+ **MX - Pertukaran surat**
+ **NAPTR - Penunjuk Otoritas Nama**
+ **PTR — Penunjuk**
+ **SPF - Kerangka Kebijakan Pengirim**
+ **SRV - Pencari lokasi layanan**
+ **TXT - Teks**
Untuk informasi selengkapnya tentang nilai di atas, lihat [nilai [Menilai/Merutekan lalu lintas](resource-record-sets-values-shared.md#rrsets-values-common-value) umum untuk lalu lintas Nilai/Rute ke](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Lokasi
Nama lokasi CIDR di mana sumber daya yang Anda tentukan dalam catatan ini ditentukan oleh nilai blok CIDR dalam lokasi CIDR.
Untuk informasi selengkapnya tentang penggunaan catatan berbasis IP, lihat[Perutean berbasis IP](routing-policy-ipbased.md).
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Mengevaluasi kesehatan target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias berbasis IP, alias latensi, atau catatan alias tertimbang. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan ini dalam kelompok catatan berbasis IP.
# Nilai khusus untuk catatan alias berbasis IP
Saat Anda membuat catatan alias berbasis IP, Anda menentukan nilai berikut.
**catatan**
Meskipun membuat catatan alias berbasis IP di zona host pribadi diizinkan, itu tidak didukung.
Untuk informasi selengkapnya, lihat [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Kebijakan perutean](#rrsets-values-ipbased-alias-routing-policy)
+ [Nama catatan](#rrsets-values-ipbased-alias-name)
+ [Jenis catatan](#rrsets-values-ipbased-alias-type)
+ [Nilai/Rutekan lalu lintas ke](#rrsets-values-ipbased-alias-alias-target)
+ [Lokasi](#rrsets-values-ipbased-alias-location)
+ [Pemeriksaan kondisi](#rrsets-values-ipbased-alias-associate-with-health-check)
+ [Mengevaluasi Kondisi Target](#rrsets-values-ipbased-alias-evaluate-target-health)
+ [ID catatan](#rrsets-values-ipbased-alias-set-id)
## Kebijakan perutean
Pilih **berbasis IP**.
**catatan**
Meskipun membuat catatan alias berbasis IP di zona host pribadi diizinkan, itu tidak didukung.
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama catatan**.
Masukkan nama yang sama untuk semua catatan dalam grup catatan berbasis IP.
**Catatan CNAME**
Jika Anda membuat catatan yang memiliki nilai **CNAME** untuk **Jenis catatan**, nama catatan tidak dapat sama dengan nama zona yang di-hosting.
**Alias untuk CloudFront distribusi dan bucket Amazon S3**
Nilai yang Anda tentukan sebagian bergantung pada AWS sumber daya yang Anda rutekan lalu lintas ke:
+ **CloudFront distribusi** — Distribusi Anda harus menyertakan nama domain alternatif yang cocok dengan nama catatan. Misalnya, jika nama catatan adalah **acme.example.com, CloudFront distribusi Anda harus menyertakan **acme.example.com**** sebagai salah satu nama domain alternatif. Untuk informasi selengkapnya, lihat [Menggunakan nama domain alternatif (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) di *Panduan CloudFront Pengembang Amazon*.
+ **Bucket Amazon S3** – Nama catatan harus sesuai dengan nama bucket Amazon S3 Anda. Misalnya, jika nama bucket Anda **acme.example.com**, nama catatan ini juga harus **acme.example.com**.
Selain itu, Anda harus mengonfigurasi bucket untuk meng-host situs web. Untuk informasi selengkapnya, lihat [Mengonfigurasi bucket untuk hosting situs web](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon*.
**Karakter-karakter khusus**
Untuk informasi tentang cara menentukan karakter selain a-z, 0-9, dan - (tanda hubung) serta cara menentukan nama domain internasional, lihat [Format nama domain DNS](DomainNameFormat.md).
**Karakter wildcard **
Anda dapat menggunakan karakter tanda bintang (\$1) dalam nama. DNS memperlakukan karakter \$1 sebagai wildcard atau sebagai karakter \$1 (ASCII 42), tergantung tempat karakter muncul dalam nama. Untuk informasi selengkapnya, lihat [Menggunakan tanda bintang (\$1) dalam nama zona yang di-hosting dan catatan](DomainNameFormat.md#domain-name-format-asterisk).
## Jenis catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai yang berlaku berdasarkan AWS sumber daya yang Anda rutekan lalu lintas. Pilih nilai yang sama untuk semua catatan dalam grup catatan berbasis IP:
**API regional kustom API Gateway atau API yang dioptimalkan edge**
Pilih **A — IPv4 alamat**.
**Titik akhir antarmuka Amazon VPC**
Pilih **A — IPv4 alamat**.
**CloudFront distribusi**
Pilih **A — IPv4 alamat**.
Jika IPv6 diaktifkan untuk distribusi, buat dua catatan, satu dengan nilai **A — IPv4 alamat** untuk **Jenis**, dan satu dengan nilai **AAAA — IPv6 ** alamat.
**Layanan App Runner**
Select **A — IPv4 alamat**
**Lingkungan Elastic Beanstalk yang memiliki subdomain regional**
Select **A — IPv4 alamat**
**Penyeimbang beban ELB**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Buket Amazon S3**
Select **A — IPv4 alamat**
**OpenSearch Layanan**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Catatan lain di zona yang di-hosting ini**
Pilih jenis catatan yang Anda buatkan alias. Semua jenis didukung kecuali **NS** dan **SOA**.
Jika Anda membuat catatan alias yang memiliki nama yang sama sebagai zona yang di-hosting (dikenal sebagai *zone apex*), Anda tidak dapat merutekan lalu lintas ke catatan dengan nilai **Jenis** adalah **CNAME**. Ini karena catatan alias harus memiliki jenis yang sama dengan catatan yang Anda tuju, dan membuat catatan CNAME untuk Zone Apex tidak didukung bahkan untuk catatan alias.
## Nilai/Rutekan lalu lintas ke
Nilai yang Anda pilih dari daftar atau yang Anda ketik di bidang tergantung pada AWS sumber daya yang Anda rutekan lalu lintas.
Untuk informasi tentang AWS sumber daya yang dapat Anda targetkan, lihat [nilai umum untuk catatan alias untuk value/route lalu lintas](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Untuk informasi selengkapnya tentang cara mengonfigurasi Route 53 untuk merutekan lalu lintas ke AWS sumber daya tertentu, lihat[Merutekan lalu lintas internet ke sumber daya Anda AWS](routing-to-aws-resources.md).
## Lokasi
Saat Anda mengonfigurasi Route 53 untuk menanggapi kueri DNS berdasarkan lokasi asal kueri, pilih lokasi CIDR yang Anda inginkan untuk merespons Route 53 dengan pengaturan dalam catatan ini.
**penting**
Sebaiknya buat satu catatan berbasis IP yang memiliki nilai **Default** untuk **Lokasi**. Ini mencakup lokasi yang belum Anda buat catatan dan alamat IP yang Route 53 tidak dapat mengidentifikasi lokasinya.
Anda tidak dapat membuat non-IP-based rekaman yang memiliki nilai yang sama untuk **nama Rekam** dan **jenis Rekam** sebagai catatan berbasis IP.
Untuk informasi selengkapnya, lihat [Perutean berbasis IP](routing-policy-ipbased.md).
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Mengevaluasi kesehatan target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias perutean berbasis IP, alias latensi, atau catatan alias tertimbang. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
Untuk catatan alias berbasis IP, jika titik akhir tidak sehat, Route 53 mencari catatan di dalam lokasi yang lebih besar dan terkait. Misalnya, Anda memiliki catatan untuk negara bagian di Amerika Serikat, Amerika Serikat, Amerika Utara, dan untuk semua lokasi (**Lokasi** adalah **Default**). Jika titik akhir untuk catatan negara bagian tidak sehat, Route 53 memeriksa catatan untuk Amerika Serikat, Amerika Utara, dan untuk semua lokasi, dalam urutan itu, hingga menemukan catatan yang memiliki titik akhir yang sehat. Jika semua rekaman yang berlaku tidak sehat, termasuk catatan untuk semua lokasi, Route 53 merespons kueri DNS menggunakan nilai catatan untuk wilayah geografis terkecil.
## Mengevaluasi Kondisi Target
Pilih **Ya** jika Anda ingin Route 53 untuk menentukan apakah untuk menanggapi permintaan DNS menggunakan catatan ini dengan memeriksa kondisi sumber daya yang ditentukan oleh **Titik akhir**.
Perhatikan hal-hal berikut:
**API Gateway khusus regional APIs dan dioptimalkan di tepi APIs**
Tidak ada persyaratan khusus untuk menyetel **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah API regional kustom API Gateway atau API yang dioptimalkan edge.
**CloudFront distribusi**
Anda tidak dapat menetapkan **Evaluasi kesehatan target** ke **Ya** ketika titik akhir adalah CloudFront distribusi.
**Lingkungan Elastic Beanstalk yang memiliki subdomain regionalisasi**
Jika Anda menentukan lingkungan Elastic Beanstalk di Endpoint dan **lingkungan** berisi penyeimbang beban ELB, Elastic Load Balancing akan merutekan kueri hanya ke instans Amazon sehat yang terdaftar dengan penyeimbang beban. EC2 (Lingkungan secara otomatis berisi penyeimbang beban ELB jika menyertakan lebih dari satu EC2 instans Amazon.) Jika Anda menetapkan **Evaluasi kesehatan target** ke **Ya** dan tidak ada EC2 instans Amazon yang sehat atau penyeimbang beban itu sendiri tidak sehat, Route 53 mengarahkan kueri ke sumber daya lain yang tersedia yang sehat, jika ada.
Jika lingkungan berisi satu EC2 instance Amazon, tidak ada persyaratan khusus.
**penyeimbang beban ELB**
Perilaku pemeriksaan kondisi tergantung pada jenis penyeimbang beban:
+ **Classic Load Balancers** — Jika Anda menentukan ELB Classic Load Balancer **di** Endpoint, Elastic Load Balancing akan merutekan kueri hanya ke instans EC2 Amazon sehat yang terdaftar dengan penyeimbang beban. Jika Anda menetapkan **Evaluasi kesehatan target** ke **Ya** dan tidak ada EC2 instance yang sehat atau penyeimbang beban itu sendiri tidak sehat, Route 53 merutekan kueri ke sumber daya lain.
+ **Aplikasi dan Penyeimbang Beban Jaringan** – Jika Anda menentukan Aplikasi ELB atau Penyeimbang Beban Jaringan dan Anda menyetel **Evaluasi kondisi target** ke **Ya**, Route 53 merutekan kueri ke penyeimbang beban berdasarkan kondisi grup target yang terkait dengan penyeimbang beban:
+ Agar Aplikasi atau Penyeimbang Beban Jaringan dianggap sehat, setiap kelompok target yang berisi target harus berisi setidaknya satu target yang sehat. Jika setiap kelompok target hanya berisi target yang tidak sehat, penyeimbang beban dianggap tidak sehat, dan Route 53 merutekan permintaan ke sumber daya lainnya.
+ Grup target yang tidak memiliki target terdaftar dianggap tidak sehat.
Bila Anda membuat penyeimbang beban, Anda mengonfigurasi pengaturan untuk pemeriksaan kondisi Elastic Load Balancing; bukan pemeriksaan kondisi Route 53, tetapi melakukan fungsi serupa. Jangan membuat pemeriksaan kesehatan Route 53 untuk EC2 kasus yang Anda daftarkan dengan penyeimbang beban ELB.
**Bucket S3**
Tidak ada persyaratan khusus untuk pengaturan **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah bucket S3.
**Titik akhir antarmuka Amazon VPC**
Tidak ada persyaratan khusus untuk pengaturan **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah antarmuka Amazon VPC.
**Catatan lain di zona yang di-hosting**
Jika AWS sumber daya yang Anda tentukan di **Endpoint** adalah rekaman atau grup catatan (misalnya, grup catatan tertimbang) tetapi bukan catatan alias lain, sebaiknya Anda mengaitkan pemeriksaan kesehatan dengan semua catatan di titik akhir. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda menghilangkan pemeriksaan kondisi?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan ini dalam kelompok catatan berbasis IP.
# Nilai khusus untuk catatan jawaban multivalue
Saat Anda membuat catatan jawaban multinilai, Anda menentukan nilai berikut.
**catatan**
Membuat catatan alias jawaban multinilai tidak didukung.
**Topics**
+ [Kebijakan perutean](#rrsets-values-multivalue-routing-policy)
+ [Nama catatan](#rrsets-values-multivalue-name)
+ [Tipe catatan](#rrsets-values-multivalue-type)
+ [TTL (detik)](#rrsets-values-multivalue-ttl)
+ [Menilai/Merutekan lalu lintas](#rrsets-values-multivalue-value)
+ [Pemeriksaan kondisi](#rrsets-values-multivalue-associate-with-health-check)
+ [ID catatan](#rrsets-values-multivalue-set-identifier)
## Kebijakan perutean
Pilih **Multivalue answer** (Jawaban multinilai).
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama catatan**.
Masukkan nama yang sama untuk semua catatan dalam kelompok catatan multivalue.
Untuk informasi selengkapnya tentang nama rekaman, lihat[Nama catatan](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai apapun kecuali **NS** atau **CNAME**.
Pilih nilai yang sama untuk semua catatan dalam grup catatan jawaban multinilai.
## TTL (detik)
Jumlah waktu, dalam detik, yang Anda inginkan untuk resolver rekursif DNS untuk menyimpan informasi tentang catatan ini dalam cache. Jika Anda menentukan nilai yang lebih lama (misalnya, 172.800 detik, atau dua hari), Anda mengurangi jumlah panggilan yang harus dilakukan oleh resolver rekursif DNS ke Route 53 untuk mendapatkan informasi terbaru dalam catatan ini. Ini memiliki efek mengurangi latensi dan mengurangi tagihan Anda untuk layanan Route 53. Untuk informasi selengkapnya, lihat [Cara Amazon Route 53 merutekan lalu lintas untuk domain Anda](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Namun, jika Anda menentukan nilai yang lebih lama untuk TTL, diperlukan waktu lebih lama agar perubahan pada catatan (misalnya, alamat IP baru) diterapkan karena resolver rekursif menggunakan nilai dalam cache mereka untuk waktu yang lebih lama sebelum mereka meminta Route 53 untuk informasi terakhir. Jika Anda mengubah setelan untuk domain atau subdomain yang sudah digunakan, sebaiknya tentukan dulu nilai yang lebih pendek, seperti 300 detik, dan tingkatkan nilainya setelah mengonfirmasi bahwa pengaturan baru sudah benar.
Jika Anda mengaitkan catatan ini dengan pemeriksaan kondisi, sebaiknya tentukan TTL 60 detik atau kurang sehingga klien merespons dengan cepat perubahan status kondisi.
**catatan**
Jika Anda membuat dua atau lebih catatan jawaban multivalue yang memiliki nama dan jenis yang sama, Anda menggunakan konsol, dan Anda menentukan nilai yang berbeda untuk **TTL**, Route 53 mengubah nilai **TTL** untuk semua catatan ke nilai terakhir yang Anda tentukan.
## Menilai/Merutekan lalu lintas
Pilih **IP address or another value depending on the record type** (Alamat IP atau nilai lain tergantung jenis catatan). Masukkan nilai yang sesuai untuk nilai **Jenis catatan**. Jika Anda memasukkan lebih dari satu nilai, masukkan setiap nilai pada baris terpisah.
Anda dapat merutekan lalu lintas ke, atau menentukan nilai berikut:
+ **A — IPv4 alamat**
+ **AAAA — alamat IPv6 **
+ **CAA - Otorisasi Otoritas Sertifikat**
+ **MX - Pertukaran surat**
+ **NAPTR - Penunjuk Otoritas Nama**
+ **PTR — Penunjuk**
+ **SPF - Kerangka Kebijakan Pengirim**
+ **SRV - Pencari lokasi layanan**
+ **TXT - Teks**
Untuk informasi selengkapnya tentang nilai di atas, lihat [nilai umum untuk Value/Route lalu lintas ke](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Evaluasi kondisi target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias latensi, atau catatan alias berbobot. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan ini dalam grup catatan jawaban multinilai.
# Nilai khusus untuk catatan tertimbang
Saat Anda membuat catatan tertimbang, Anda menentukan nilai berikut.
**Topics**
+ [Kebijakan perutean](#rrsets-values-weighted-routing-policy)
+ [Nama catatan](#rrsets-values-weighted-name)
+ [Tipe catatan](#rrsets-values-weighted-type)
+ [TTL (detik)](#rrsets-values-weighted-ttl)
+ [Menilai/Merutekan lalu lintas](#rrsets-values-weighted-value)
+ [Bobot](#rrsets-values-weighted-weight)
+ [Pemeriksaan kondisi](#rrsets-values-weighted-associate-with-health-check)
+ [ID catatan](#rrsets-values-weighted-set-identifier)
## Kebijakan perutean
Pilih **Tertimbang**.
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama catatan**.
Masukkan nama yang sama untuk semua catatan dalam grup catatan tertimbang.
Untuk informasi selengkapnya tentang nama rekaman, lihat[Nama catatan](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai yang sama untuk semua catatan dalam kelompok grup tertimbang.
## TTL (detik)
Jumlah waktu, dalam detik, yang Anda inginkan untuk resolver rekursif DNS untuk menyimpan informasi tentang catatan ini dalam cache. Jika Anda menentukan nilai yang lebih lama (misalnya, 172.800 detik, atau dua hari), Anda mengurangi jumlah panggilan yang harus dilakukan oleh resolver rekursif DNS ke Route 53 untuk mendapatkan informasi terbaru dalam catatan ini. Ini memiliki efek mengurangi latensi dan mengurangi tagihan Anda untuk layanan Route 53. Untuk informasi selengkapnya, lihat [Cara Amazon Route 53 merutekan lalu lintas untuk domain Anda](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Namun, jika Anda menentukan nilai yang lebih lama untuk TTL, diperlukan waktu lebih lama agar perubahan pada catatan (misalnya, alamat IP baru) diterapkan karena resolver rekursif menggunakan nilai dalam cache mereka untuk waktu yang lebih lama sebelum mereka meminta Route 53 untuk informasi terakhir. Jika Anda mengubah setelan untuk domain atau subdomain yang sudah digunakan, sebaiknya tentukan dulu nilai yang lebih pendek, seperti 300 detik, dan tingkatkan nilainya setelah mengonfirmasi bahwa pengaturan baru sudah benar.
Jika Anda mengaitkan catatan ini dengan pemeriksaan kondisi, sebaiknya tentukan TTL 60 detik atau kurang sehingga klien merespons dengan cepat perubahan status kondisi.
Anda harus menentukan nilai yang sama untuk **TTL** untuk semua catatan dalam grup catatan tertimbang ini.
**catatan**
Jika Anda membuat dua atau lebih catatan tertimbang yang memiliki nama dan tipe yang sama, dan Anda menentukan nilai yang berbeda untuk **TTL**, Route 53 akan mengubah nilai **TTL** untuk semua catatan ke nilai terakhir yang Anda tentukan.
Jika grup catatan tertimbang menyertakan satu atau beberapa catatan alias tertimbang yang merutekan lalu lintas ke penyeimbang beban ELB, kami menyarankan agar Anda menentukan TTL 60 detik untuk semua catatan tertimbang nonalias yang memiliki nama dan tipe yang sama. Nilai selain 60 detik (TTL untuk penyeimbang beban) akan mengubah efek nilai yang Anda tentukan untuk **Bobot**.
## Menilai/Merutekan lalu lintas
Pilih **IP address or another value depending on the record type** (Alamat IP atau nilai lain tergantung jenis catatan). Masukkan nilai yang sesuai untuk nilai **Jenis catatan**. Untuk semua jenis kecuali **CNAME**, Anda dapat memasukkan lebih dari satu nilai. Masukkan setiap nilai pada baris terpisah.
Anda dapat merutekan lalu lintas ke, atau menentukan nilai berikut:
+ **A — IPv4 alamat**
+ **AAAA — alamat IPv6 **
+ **CAA - Otorisasi Otoritas Sertifikat**
+ **CNAME — Nama kanonik**
+ **MX - Pertukaran surat**
+ **NAPTR - Penunjuk Otoritas Nama**
+ **PTR — Penunjuk**
+ **SPF - Kerangka Kebijakan Pengirim**
+ **SRV - Pencari lokasi layanan**
+ **TXT - Teks**
Untuk informasi selengkapnya tentang nilai di atas, lihat [nilai umum untuk Value/Route lalu lintas ke](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Bobot
Nilai yang menentukan proporsi kueri DNS yang direspons Route 53 menggunakan catatan saat ini. Route 53 menghitung jumlah bobot untuk catatan yang memiliki kombinasi yang sama dari nama dan tipe DNS. Route 53 kemudian merespons kueri berdasarkan rasio bobot terhadap total milik sumber daya.
Anda tidak dapat membuat catatan tidak tertimbang yang memiliki nilai yang sama untuk **Nama catatan** dan **Jenis catatan** sebagai catatan tertimbang.
Masukkan bilangan bulat antara 0 dan 255. Untuk menonaktifkan perutean ke sumber daya, atur **Bobot** ke 0. Jika Anda menetapkan **Bobot** ke 0 untuk semua catatan dalam grup, lalu lintas dirutekan ke semua sumber daya dengan probabilitas yang sama. Hal ini memastikan bahwa Anda tidak secara tidak sengaja menonaktifkan perutean untuk grup catatan tertimbang.
Efek dari pengaturan **Bobot** ke 0 berbeda ketika Anda mengasosiasikan pemeriksaan kondisi dengan catatan tertimbang. Untuk informasi selengkapnya, lihat [Cara Amazon Route 53 memilih catatan ketika pemeriksaan kondisi dikonfigurasiCara Route 53 memilih catatan ketika pemeriksaan kondisi dikonfigurasi](health-checks-how-route-53-chooses-records.md).
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Mengevaluasi kesehatan target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias latensi, alias berbasis IP, atau catatan alias tertimbang. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan ini dalam grup catatan tertimbang.
# Nilai khusus untuk catatan alias tertimbang
Ketika Anda membuat catatan alias tertimbang, Anda menentukan nilai-nilai berikut. Untuk informasi selengkapnya, lihat [Memilih antara catatan alias dan nonalias](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Kebijakan perutean](#rrsets-values-weighted-alias-routing-policy)
+ [Nama catatan](#rrsets-values-weighted-alias-name)
+ [Tipe catatan](#rrsets-values-weighted-alias-type)
+ [Nilai/Rutekan lalu lintas ke](#rrsets-values-weighted-alias-alias-target)
+ [Bobot](#rrsets-values-weighted-alias-weight)
+ [Pemeriksaan kondisi](#rrsets-values-weighted-alias-associate-with-health-check)
+ [Mengevaluasi Kondisi Target](#rrsets-values-weighted-alias-evaluate-target-health)
+ [ID catatan](#rrsets-values-weighted-alias-set-identifier)
## Kebijakan perutean
Pilih **Weighted** (Tertimbang).
## Nama catatan
Masukkan nama domain atau subdomain yang ingin Anda tuju lalu lintasnya. Nilai default adalah nama zona yang di-hosting.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang **Nama**.
Masukkan nama yang sama untuk semua catatan dalam grup catatan tertimbang.
Untuk informasi selengkapnya tentang nama rekaman, lihat [Nama catatan](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name)
## Tipe catatan
Jenis data DNS. Untuk informasi selengkapnya, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
Pilih nilai yang berlaku berdasarkan AWS sumber daya yang Anda rutekan lalu lintas ke:
**API regional kustom API Gateway atau API yang dioptimalkan edge**
Pilih **A — IPv4 alamat**.
**Titik akhir antarmuka Amazon VPC**
Pilih **A — IPv4 alamat**.
**CloudFront distribusi**
Pilih **A — IPv4 alamat**.
Jika IPv6 diaktifkan untuk distribusi, buat dua catatan, satu dengan nilai **A — IPv4 alamat** untuk **Jenis**, dan satu dengan nilai **AAAA — IPv6 ** alamat.
**Layanan Pelari Aplikasi**
Select **A — IPv4 alamat**
**Lingkungan Elastic Beanstalk yang memiliki subdomain regional**
Select **A — IPv4 alamat**
**Penyeimbang beban ELB**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Buket Amazon S3**
Select **A — IPv4 alamat**
**OpenSearch Layanan**
Select **A — IPv4 alamat** atau **AAAA** — alamat IPv6
**Catatan lain di zona yang di-hosting ini**
Pilih jenis catatan yang Anda buatkan alias. Semua jenis didukung kecuali **NS** dan **SOA**.
Jika Anda membuat catatan alias yang memiliki nama yang sama sebagai zona yang di-hosting (dikenal sebagai *zone apex*), Anda tidak dapat merutekan lalu lintas ke catatan dengan nilai **Jenis** adalah **CNAME**. Ini karena catatan alias harus memiliki jenis yang sama dengan catatan yang Anda tuju, dan membuat catatan CNAME untuk Zone Apex tidak didukung bahkan untuk catatan alias.
Pilih nilai yang sama untuk semua catatan dalam kelompok grup tertimbang.
## Nilai/Rutekan lalu lintas ke
Nilai yang Anda pilih dari daftar atau yang Anda ketik di bidang tergantung pada AWS sumber daya yang Anda rutekan lalu lintas.
Untuk informasi tentang AWS sumber daya yang dapat Anda targetkan, lihat [nilai umum untuk catatan alias untuk value/route lalu lintas](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Untuk informasi selengkapnya tentang cara mengonfigurasi Route 53 untuk merutekan lalu lintas ke AWS sumber daya tertentu, lihat[Merutekan lalu lintas internet ke sumber daya Anda AWS](routing-to-aws-resources.md).
## Bobot
Nilai yang menentukan proporsi kueri DNS yang direspons Route 53 menggunakan catatan saat ini. Route 53 menghitung jumlah bobot untuk catatan yang memiliki kombinasi yang sama dari nama dan tipe DNS. Route 53 kemudian merespons kueri berdasarkan rasio bobot terhadap total milik sumber daya.
Anda tidak dapat membuat catatan tidak tertimbang yang memiliki nilai yang sama untuk **Nama catatan** dan **Jenis catatan** sebagai catatan tertimbang.
Masukkan bilangan bulat antara 0 dan 255. Untuk menonaktifkan perutean ke sumber daya, atur **Bobot** ke 0. Jika Anda menetapkan **Bobot** ke 0 untuk semua catatan dalam grup, lalu lintas dirutekan ke semua sumber daya dengan probabilitas yang sama. Hal ini memastikan bahwa Anda tidak secara tidak sengaja menonaktifkan perutean untuk grup catatan tertimbang.
Efek dari pengaturan **Bobot** ke 0 berbeda ketika Anda mengasosiasikan pemeriksaan kondisi dengan catatan tertimbang. Untuk informasi selengkapnya, lihat [Cara Amazon Route 53 memilih catatan ketika pemeriksaan kondisi dikonfigurasiCara Route 53 memilih catatan ketika pemeriksaan kondisi dikonfigurasi](health-checks-how-route-53-chooses-records.md).
## Pemeriksaan kondisi
Pilih pemeriksaan kondisi jika Anda ingin Route 53 untuk memeriksa kondisi titik akhir tertentu dan untuk menanggapi permintaan DNS menggunakan catatan ini hanya ketika kondisi titik akhir baik.
Route 53 tidak memeriksa kondisi titik akhir yang ditentukan dalam catatan, misalnya, titik akhir yang ditentukan oleh alamat IP di bidang **Nilai**. Saat Anda memilih pemeriksaan kondisi untuk catatan, Route 53 memeriksa kondisi titik akhir yang Anda tentukan di pemeriksaan kondisi. Untuk informasi tentang bagaimana Route 53 menentukan apakah titik akhir sehat, lihat [Bagaimana Amazon Route 53 menentukan apakah pemeriksaan kondisi sehatBagaimana Route 53 menentukan apakah pemeriksaan kondisi sehat](dns-failover-determining-health-of-endpoints.md).
Mengaitkan pemeriksaan kondisi dengan catatan hanya berguna ketika Route 53 memilih di antara dua catatan atau lebih untuk merespons kueri DNS, dan Anda ingin Rute 53 mendasarkan pilihan sebagian pada status pemeriksaan kondisi. Gunakan pemeriksaan kondisi hanya dalam konfigurasi berikut:
+ Anda sedang memeriksa kesehatan semua catatan dalam grup catatan yang memiliki nama, jenis, dan kebijakan perutean yang sama (seperti failover atau catatan tertimbang), dan Anda menentukan pemeriksaan kesehatan IDs untuk semua catatan. Jika pemeriksaan kondisi untuk catatan menentukan titik akhir yang tidak sehat, Route 53 berhenti merespons kueri menggunakan nilai untuk catatan tersebut.
+ Anda memilih **Ya** untuk **Mengevaluasi kesehatan target** untuk catatan alias atau catatan dalam grup alias failover, alias geolokasi, alias latensi, alias berbasis IP, atau catatan alias tertimbang. Jika catatan alias mereferensikan catatan nonalias di zona yang dihosting yang sama, Anda juga harus menentukan pemeriksaan kesehatan untuk catatan yang direferensikan. Jika Anda mengaitkan pemeriksaan kesehatan dengan catatan alias dan juga memilih **Ya** untuk **Evaluasi Kesehatan Target**, keduanya harus mengevaluasi dengan benar. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda mengaitkan pemeriksaan kondisi dengan catatan alias?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Jika pemeriksaan kondisi Anda menentukan titik akhir hanya berdasarkan nama domain, sebaiknya buat pemeriksaan kondisi terpisah untuk setiap titik akhir. Misalnya, buat pemeriksaan kondisi untuk setiap server HTTP yang melayani konten untuk www.example.com. Untuk nilai **Nama domain**, tentukan nama domain server (seperti us-east-2-www.example.com), bukan nama catatan (example.com).
**penting**
Dalam konfigurasi ini, jika Anda membuat pemeriksaan kondisi dengan nilai **Nama domain** yang sesuai dengan nama catatan lalu mengaitkan pemeriksaan kondisi dengan catatan tersebut, hasil pemeriksaan kondisi tidak dapat diprediksi.
## Mengevaluasi Kondisi Target
Pilih **Ya** jika Anda ingin Route 53 untuk menentukan apakah untuk menanggapi permintaan DNS menggunakan catatan ini dengan memeriksa kondisi sumber daya yang ditentukan oleh **Titik akhir**.
Perhatikan hal-hal berikut:
**API Gateway khusus regional APIs dan dioptimalkan tepi APIs**
Tidak ada persyaratan khusus untuk menyetel **Evaluasi kesehatan target** ke **Ya** ketika titik akhir adalah API Regional kustom API Gateway API atau API yang dioptimalkan tepi.
**CloudFront distribusi**
Anda tidak dapat menetapkan **Evaluasi kesehatan target** ke **Ya** ketika titik akhir adalah CloudFront distribusi.
**Lingkungan Elastic Beanstalk yang memiliki subdomain regionalisasi**
Jika Anda menentukan lingkungan Elastic Beanstalk di **Titik Akhir** dan lingkungan berisi penyeimbang beban ELB, Elastic Load Balancing hanya merutekan kueri ke Instans Amazon EC2 yang sehat dan terdaftar dengan penyeimbang beban. (Lingkungan secara otomatis berisi penyeimbang beban ELB jika mencakup lebih dari satu Instans Amazon EC2.) Jika Anda mengatur **Evaluasi kondisi target** ke **Ya** dan Instans Amazon EC2 atau penyeimbang beban tidak ada yang sehat, Route 53 merutekan kueri ke sumber daya lain sehat yang tersedia, jika ada.
Jika lingkungan berisi contoh Instans Amazon EC2 tunggal, tidak ada persyaratan khusus.
**penyeimbang beban ELB**
Perilaku pemeriksaan kondisi tergantung jenis penyeimbang beban:
+ **Classic Load Balancer** – Jika Anda menentukan Classic Load Balancer ELB di **Titik akhir**, Elastic Load Balancing merutekan kueri hanya ke instans Amazon EC2 sehat yang terdaftar dengan penyeimbang beban. Jika Anda menyetel **Evaluasi Kondisi Target** ke **Ya** dan tidak ada instans EC2 yang sehat atau penyeimbang beban itu sendiri tidak sehat, Route 53 merutekan kueri ke sumber daya lain.
+ **Aplikasi dan Penyeimbang Beban Jaringan** – Jika Anda menentukan Aplikasi ELB atau Penyeimbang Beban Jaringan dan Anda menyetel **Evaluasi Kondisi Target** ke **Ya**, Route 53 merutekan kueri ke penyeimbang beban berdasarkan kondisi grup target yang terkait dengan penyeimbang beban:
+ Agar Aplikasi atau Penyeimbang Beban Jaringan dianggap sehat, setiap kelompok target yang berisi target harus berisi setidaknya satu target yang sehat. Jika setiap kelompok target hanya berisi target yang tidak sehat, penyeimbang beban dianggap tidak sehat, dan Route 53 merutekan permintaan ke sumber daya lainnya.
+ Grup target yang tidak memiliki target terdaftar dianggap tidak sehat.
Bila Anda membuat penyeimbang beban, Anda mengonfigurasi pengaturan untuk pemeriksaan kondisi Elastic Load Balancing; bukan pemeriksaan kondisi Route 53, tetapi melakukan fungsi serupa. Tidak membuat pemeriksaan kondisi Route 53 untuk Instans EC2 yang Anda daftarkan dengan penyeimbang beban ELB.
**Bucket S3**
Tidak ada persyaratan khusus untuk pengaturan **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah bucket S3.
**Titik akhir antarmuka Amazon VPC**
Tidak ada persyaratan khusus untuk pengaturan **Evaluasi kondisi target** ke **Ya** ketika titik akhir adalah antarmuka Amazon VPC.
**Catatan lain di zona yang di-hosting**
Jika AWS sumber daya yang Anda tentukan di **Endpoint** adalah rekaman atau grup catatan (misalnya, grup catatan tertimbang) tetapi bukan catatan alias lain, sebaiknya Anda mengaitkan pemeriksaan kesehatan dengan semua catatan di titik akhir. Untuk informasi selengkapnya, lihat [Apa yang terjadi jika Anda menghilangkan pemeriksaan kondisi?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## ID catatan
Masukkan nilai yang secara unik mengidentifikasi catatan ini dalam grup catatan tertimbang.
# Membuat catatan dengan mengimpor file zona
Jika Anda bermigrasi dari penyedia layanan DNS lain, dan jika penyedia layanan DNS Anda saat ini mengizinkan Anda mengekspor pengaturan DNS Anda saat ini ke file zona, Anda dapat dengan cepat membuat semua catatan untuk zona yang di-hosting Amazon Route 53 dengan mengimpor file zona.
**catatan**
File zona menggunakan format standar yang dikenal sebagai BIND untuk mewakili catatan dalam format teks. Untuk informasi tentang format file zona, lihat entri Wikipedia untuk [file Zona](https://en.wikipedia.org/wiki/Zone_file). Informasi tambahan tersedia di [RFC 1034, Nama Domain—Konsep dan Fasilitas](https://datatracker.ietf.org/doc/html/rfc1034) bagian 3.6.1, dan [RFC 1035, Nama Domain—Implementasi dan Spesifikasi](https://datatracker.ietf.org/doc/html/rfc1035) bagian 5.
Jika Anda ingin membuat catatan dengan mengimpor file zona, perhatikan hal berikut:
+ File zona harus dalam format yang sesuai dengan RFC.
+ Nama domain catatan dalam file zona harus cocok dengan nama zona yang di-hosting.
+ Route 53 mendukung kata kunci `$ORIGIN` dan `$TTL`. Jika file zona menyertakan kata kunci `$GENERATE` atau `$INCLUDE`, impor gagal dan Route 53 akan menghasilkan kesalahan.
+ Saat Anda mengimpor file zona, Route 53 mengabaikan catatan SOA di file zona. Route 53 juga mengabaikan catatan NS yang memiliki nama yang sama sebagai zona yang di-hosting.
+ Anda dapat mengimpor maksimum 1.000 catatan.
+ Jika zona yang di-hosting sudah berisi catatan yang muncul di file zona, proses impor gagal, dan tidak ada catatan yang dibuat.
+ Untuk catatan TXT yang berisi karakter garis miring terbalik, proses impor file zona menafsirkan urutan garis miring terbalik tertentu sebagai karakter kontrol. Untuk memasukkan karakter garis miring terbalik literal dalam nilai catatan TXT:
+ Gunakan garis miring terbalik ganda (`\\\\`) dalam file zona untuk mewakili garis miring terbalik literal tunggal dalam catatan TXT akhir.
+ Misalnya, jika catatan TXT Anda harus berisi `\\jYTDWqH...` (dengan garis miring terbalik literal dan j), tentukan `\\\\jYTDWqH...` dalam file zona.
Ini sangat penting untuk catatan tantangan ACME dan catatan TXT lainnya yang berisi karakter garis miring terbalik literal.
+ Untuk catatan TXT yang panjang (seperti catatan DKIM), proses impor file zona mendukung pemisahan konten menjadi beberapa string. Untuk membuat catatan TXT dengan beberapa string:
+ Gunakan baris terpisah di file zona Anda dengan nama dan jenis rekaman yang sama.
**Example**
```
example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC"
example.com. 300 IN TXT "7fCC6C13dM9tXuJmUBH7D4Vw8y1ByJ8z9QX2fvLm3pN4sR5tU6vW7xY8zA9bC0dE1f"
example.com. 300 IN TXT "G2hI3jK4lM5nO6pQ7rS8tU9vW0xY1zA2bC3dE4fG5hI6jK7lM8nO9pQ0rS1tU2vW3x"
```
Proses impor secara otomatis menggabungkan ini ke dalam satu catatan TXT dengan beberapa string. Setiap string individu dapat berisi hingga 65.535 karakter. Jangan menggabungkan string panjang menjadi satu nilai kutip.
+ Kami menyarankan Anda meninjau konten file zona untuk mengonfirmasi bahwa nama catatan menyertakan atau mengecualikan titik beruntun yang sesuai:
+ Ketika nama catatan dalam file zona menyertakan titik beruntun (`example.com.`), proses impor menginterpretasikan nama sebagai nama domain yang memenuhi syarat dan menciptakan catatan Route 53 dengan nama tersebut.
+ Saat nama rekaman dalam file zona tidak menyertakan titik beruntun (`www`), proses impor menggabungkan nama tersebut dengan nama domain di file zona (`example.com`) dan membuat catatan Route 53 dengan nama gabungan (`www.example.com`).
Jika proses ekspor tidak menambahkan titik akhir ke nama domain yang sepenuhnya memenuhi syarat dari catatan, proses impor Route 53 menambahkan nama domain ke nama catatan. Misalnya, anggap Anda mengimpor data ke zona yang di-hosting `example.com` dan nama catatan MX dalam file zona adalah `mail.example.com`, tanpa titik beruntun. Proses impor Route 53 menciptakan catatan MX bernama `mail.example.com.example.com`.
**penting**
Untuk data CNAME, MX, PTR, dan SRV, perilaku ini juga berlaku untuk nama domain yang disertakan dalam nilai RDATA. Misalnya, anggap Anda memiliki file zona untuk `example.com`. Jika data CNAME dalam file zona (`support`, tanpa titik beruntun) memiliki nilai RDATA `www.example.com` (juga tanpa titik beruntun), proses impor membuat catatan Route 53 dengan nama `support.example.com` yang merutekan lalu lintas ke `www.example.com.example.com`. Sebelum Anda mengimpor file zona Anda, tinjau nilai RDATA dan perbarui sebagaimana berlaku. Untuk catatan TXT yang berisi karakter garis miring terbalik, gunakan garis miring terbalik ganda (`\\\\`) di file zona untuk mewakili garis miring terbalik literal.
Route 53 tidak mendukung mengekspor catatan ke file zona.
**catatan**
Jika Anda membuat catatan yang memiliki nama yang sama dengan zona yang di-hosting, jangan masukkan nilai (misalnya, simbol @) di bidang Nama.
**Untuk membuat catatan dengan mengimpor file zona**
1. Dapatkan file zona dari penyedia layanan DNS yang saat ini melayani domain. Proses dan terminologi bervariasi dari satu penyedia layanan ke yang lain. Lihat antarmuka dan dokumentasi penyedia Anda untuk informasi tentang mengekspor atau menyimpan catatan Anda dalam file zona atau file BIND.
Jika prosesnya tidak jelas, coba tanyakan dukungan pelanggan penyedia DNS Anda saat ini untuk *daftar catatan* atau informasi *file zona*.
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Di panel navigasi, pilih **Hosted zones** (Zona yang di-hosting).
1. Pada halaman **Zona yang Di-hosting**, buat zona yang di-hosting baru:
1. Pilih **Create hosted zone** (Buat Zona yang Di-hosting).
1. Masukkan nama domain Anda dan, secara opsional, memberikan komentar.
1. Pilih **Buat**.
1. Pilih **Import zone file** (Impor file zona).
1. Di panel **Import zone file** (Impor file zona), tempel isi dari file zona Anda ke kotak teks **Zone file** (File zona).
1. Pilih **Import** (Impor).
**catatan**
Bergantung pada jumlah rekaman dalam file zona Anda, Anda mungkin harus menunggu beberapa menit hingga catatan dibuat.
1. Jika Anda menggunakan layanan DNS lain untuk domain tersebut (yang biasa terjadi jika Anda mendaftarkan domain dengan registrar lain), migrasikan layanan DNS ke Route 53. Ketika langkah itu selesai, pencatat Anda akan mulai mengidentifikasi Route 53 sebagai layanan DNS Anda sebagai tanggapan atas kueri DNS untuk domain Anda, dan kueri akan mulai dikirim ke server DNS Route 53. (Biasanya, ada satu atau dua hari penundaan sebelum kueri DNS mulai dirutekan ke Route 53 karena informasi tentang layanan DNS Anda sebelumnya di-cache pada DNS resolver selama itu.) Untuk informasi selengkapnya, lihat [Membuat Amazon Route 53 menjadi layanan DNS untuk domain yang adaMembuat Route 53 menjadi layanan DNS untuk domain yang ada](MigratingDNS.md).
# Mengedit catatan
Prosedur berikut menjelaskan cara mengedit catatan menggunakan konsol Amazon Route 53. Untuk informasi tentang cara mengedit rekaman menggunakan API Route 53, lihat [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)di *Referensi API Amazon Route 53*.
**catatan**
Perubahan untuk catatan membutuhkan waktu untuk menyebarkan ke server DNS Route 53. Saat ini, satu-satunya cara untuk memverifikasi bahwa perubahan telah disebarkan adalah dengan menggunakan tindakan [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. Perubahan umumnya menyebar ke semua server nama Route 53 dalam waktu 60 detik.
**Untuk mengedit catatan menggunakan konsol Route 53**
1. Jika Anda tidak mengedit catatan alias, lewati ke langkah 2.
Jika Anda mengedit catatan alias yang merutekan lalu lintas ke Elastic Load Balancing Classic Load Balancer, Application Load Balancer, atau Network Load Balancer, dan jika Anda membuat zona host Route 53 dan penyeimbang beban Anda menggunakan akun yang berbeda, [Mendapatkan nama DNS untuk penyeimbang beban Elastic Load Balancing](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure) lakukan prosedur untuk mendapatkan nama DNS untuk penyeimbang beban.
Jika Anda mengedit catatan alias untuk AWS sumber daya lain, lewati ke langkah 2.
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Di panel navigasi, pilih **Hosted zones** (Zona yang di-hosting).
1. Di halaman **Hosted Zones** (Zona yang Di-hosting), pilih baris untuk zona yang di-hosting tempat Anda ingin mengedit catatan.
1. Pilih baris untuk rekaman yang ingin Anda edit, lalu masukkan perubahan Anda di panel **Edit catatan**.
1. Masukkan nilai yang berlaku. Untuk informasi selengkapnya, lihat [Nilai yang Anda tentukan saat membuat atau mengedit catatan Amazon Route 53](resource-record-sets-values.md).
1. Pilih **Save changes** (Simpan perubahan).
1. Jika Anda mengedit beberapa catatan, ulangi langkah 5 hingga 7.
# Menghapus catatan
Prosedur berikut menjelaskan cara menghapus catatan menggunakan konsol Route 53. Untuk informasi tentang cara menghapus rekaman menggunakan API Route 53, lihat [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)di *Referensi API Amazon Route 53*.
**catatan**
Perubahan untuk catatan membutuhkan waktu untuk menyebarkan ke server DNS Route 53. Saat ini, satu-satunya cara untuk memverifikasi bahwa perubahan telah disebarkan adalah dengan menggunakan tindakan [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API. Perubahan umumnya menyebar ke semua server nama Route 53 dalam waktu 60 detik.
**Membatalkan catatan**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Di halaman Zona yang Di-hosting, pilih baris untuk zona yang di-hosting tempat Anda ingin menghapus catatan.
1. Dalam daftar catatan, pilih data yang ingin Anda hapus.
Untuk memilih beberapa catatan berturut-turut, pilih baris pertama, tahan tombol **Shift**, dan pilih baris terakhir. Untuk memilih beberapa catatan yang tidak berurutan, pilih baris pertama, tahan tombol **Ctrl**, dan pilih baris tambahan.
Anda tidak dapat menghapus catatan yang memiliki nilai **NS** atau **SOA** untuk **Jenis**.
1. Pilih **Delete** (Hapus).
1. Pilih **Delete** (Hapus) untuk menutup kotak dialog.
# Mencantumkan catatan
Prosedur berikut menjelaskan cara menggunakan konsol Amazon Route 53 untuk daftar catatan di zona yang di-hosting. Untuk informasi tentang cara mencantumkan catatan menggunakan API Route 53, lihat [ListResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListResourceRecordSets.html)di *Referensi API Amazon Route 53*.
**Untuk mencantumkan catatan**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Pada panel navigasi, pilih **Zona yang di-hosting**.
1. Pada halaman **Zona yang Di-hosting**, pilih nama zona yang di-hosting.
1. Untuk mengubah mode pencarian, pilih ikon roda gigi di kanan atas tabel **Rekaman**. Pilih salah satu dari:
+ **Otomatis**
Dalam mode ini, layanan menggunakan filter berdasarkan sejumlah catatan. Penuh kurang dari 2000 dan cepat untuk lebih dari 2000 catatan.
+ **Penuh**
Dalam mode ini, semua filter pencarian tersedia, tetapi kinerja pencarian mungkin lebih lambat.
+ **Cepat**
Dalam mode ini, beberapa fitur canggih tidak tersedia, tetapi kinerja pencarian akan lebih cepat.
Untuk hanya menampilkan catatan yang dipilih, masukkan kriteria pencarian yang berlaku di atas daftar catatan. Dalam mode otomatis, perilaku pencarian bergantung pada apakah zona yang dihosting berisi hingga 2.000 catatan atau lebih dari 2.000 catatan:
**Hingga 2.000 catatan dan mode penuh**
+ Untuk menampilkan catatan yang memiliki nilai tertentu, masukkan nilai di bilah pencarian dan tekan **Enter**. Misalnya, untuk menampilkan catatan yang memiliki alamat IP yang dimulai dengan **192.0**, masukkan nilai tersebut di bidang **Search** (Pencarian), dan tekan **Enter**.
+ Untuk menampilkan hanya catatan yang memiliki jenis data DNS yang sama, pilih **Jenis catatan** dalam daftar menurun, dan masukkan jenis catatan.
+ Untuk hanya menampilkan catatan alias, pilih **Alias** di daftar dropdown, dan masukkan. **Yes**
+ Untuk hanya menampilkan catatan tertimbang, pilih **Kebijakan perutean** dalam daftar menurun, dan masukkan **WEIGHTED**.
**Lebih dari 2.000 catatan dan mode cepat**
+ Anda dapat mencari hanya pada nama catatan, bukan pada nilai catatan. Anda juga tidak dapat memfilter berdasarkan jenis catatan, atau pada alias atau catatan tertimbang.
Untuk melakukan ini, masukkan kursor Anda ke kotak teks **Filter**, pilih **Properti** dan kemudian **Rekam** nama.
+ Untuk catatan yang memiliki tiga label (tiga bagian dipisahkan oleh titik), ketika Anda memasukkan nilai di kolom pencarian dan menekan **Enter**, konsol Route 53 secara otomatis melakukan pencarian wildcard pada label ketiga dari kanan dalam nama catatan. Misalnya, zona yang di-hosting example.com berisi 100 catatan bernama record1.example.com melalui record100.example.com. (Record1 adalah label ketiga dari kanan.) Inilah yang terjadi saat Anda mencari nilai berikut:
+ **record1** – Konsol Route 53 mencari **record1\$1.example.com**, yang akan menghasilkan **record1.example.com**, **record10.example.com** melaui **record19.example.com**, dan **record100.example.com**.
+ **record1.example.com** – Seperti pada contoh sebelumnya, konsol akan melakukan pencarian untuk **record1\$1.example.com** dan menghasilkan catatan yang sama.
+ **1** – Konsol melakukan pencarian untuk **1\$1.example.com** dan tidak menghasilkan catatan.
+ **Example** – Konsol melakukan pencarian untuk **example\$1.example.com** dan tidak menghasilkan catatan.
+ **example.com** – Dalam contoh ini, konsol tidak melakukan pencarian wildcard. Hal ini akan menghasilkan semua catatan di zona yang di-hosting.
+ **Mode pencarian otomatis** — Saat menggunakan mode pencarian ini, Anda harus terlebih dahulu menyediakan properti, seperti nama rekam, untuk dapat mencari.
**catatan**
Jika label ketiga dari kanan berisi satu atau lebih tanda hubung (seperti `third-label.example.com`), dan jika Anda mencari bagian dari label ketiga tepat sebelum tanda hubung (`third` dalam contoh ini), Route 53 tidak akan menghasilkan catatan apa pun. Sebagai gantinya, sertakan tanda hubung (cari `third-`) atau hilangkan karakter segera sebelum tanda hubung (cari `third`).
+ Untuk catatan yang memiliki empat label atau lebih, Anda harus menentukan nama yang tepat dari catatan. Tidak ada pencarian wildcard yang didukung. Sebagai contoh, jika zona yang di-hosting menyertakan catatan bernama label4.record1.example.com, Anda dapat menemukan catatan itu hanya jika Anda menentukan **label4.record1.example.com** di bidang pencarian.
# Mengonfigurasi penandatanganan DNSSEC di Amazon Route 53
Penandatanganan Domain Name System Security Extensions (DNSSEC) memungkinkan penyelesai DNS memvalidasi bahwa respons DNS berasal dari Amazon Route 53 dan belum diubah. Ketika Anda menggunakan penandatanganan DNSSEC, setiap respons untuk zona yang di-hosting ditandatangani menggunakan kriptografi kunci publik. Untuk ikhtisar DNSSEC, lihat bagian DNSSEC dari [AWS re:Invent 2021 - Amazon Route](https://www.youtube.com/watch?v=77V23phAaAE) 53: Setahun dalam peninjauan.
Dalam Bab ini, kami menjelaskan cara mengaktifkan penandatanganan DNSSEC untuk Route 53, cara bekerja dengan kunci penandatanganan kunci (KSKs), dan cara memecahkan masalah. Anda dapat bekerja dengan penandatanganan DNSSEC Konsol Manajemen AWS atau secara terprogram dengan API. Untuk informasi lebih lanjut tentang menggunakan CLI atau SDKs untuk bekerja dengan Route 53, lihat. [Siapkan Amazon Route 53](setting-up-route-53.md)
Sebelum Anda mengaktifkan penandatangan DNSSEC, perhatikan hal berikut:
+ Untuk membantu mencegah pemadaman zona dan menghindari masalah dengan domain yang menjadi tidak tersedia, Anda harus cepat mengatasi dan menyelesaikan kesalahan DNSSEC. Kami sangat menyarankan agar Anda mengatur CloudWatch alarm yang memberi tahu Anda setiap kali `DNSSECKeySigningKeysNeedingAction` kesalahan `DNSSECInternalFailure` atau terdeteksi. Untuk informasi selengkapnya, lihat [Memantau zona yang dihosting menggunakan Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
+ Ada dua jenis kunci dalam DNSSEC: kunci penandatanganan kunci (KSK) dan kunci penandatanganan zona (ZSK). Dalam penandatanganan DNSSEC Route 53, setiap KSK didasarkan pada [kunci yang dikelola pelanggan asimetris](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept) yang Anda miliki. AWS KMS Anda bertanggung jawab atas manajemen KSK, yang mencakup rotasi jika diperlukan. Manajemen ZSK dilakukan oleh Route 53.
+ Jika Anda mengaktifkan penandatanganan DNSSEC untuk zona yang di-hosting, Route 53 membatasi TTL menjadi satu minggu. Jika Anda menetapkan TTL lebih dari satu minggu untuk catatan di zona yang di-hosting, Anda tidak akan mendapatkan kesalahan. Namun, Route 53 memberlakukan TTL selama satu minggu untuk catatan. Catatan yang memiliki TTL kurang dari satu minggu dan catatan di zona yang di-hosting lain dengan penandatangan DNSSEC yang dinonktifkan tidak akan terpengaruh.
+ Ketika Anda menggunakan penandatanganan DNSSEC, konfigurasi multi-vendor tidak didukung. Jika Anda telah mengonfigurasi server nama label putih (juga dikenal sebagai server nama vanity atau server nama pribadi), pastikan server nama tersebut disediakan oleh penyedia DNS tunggal.
+ Beberapa penyedia DNS tidak mendukung catatan Delegation Signer (DS) dalam DNS otoritatif mereka. Jika zona induk Anda di-host oleh penyedia DNS yang tidak mendukung kueri DS (tidak menyetel tanda AA dalam respons kueri DS), maka saat Anda mengaktifkan DNSSEC di zona turunannya, zona anak akan menjadi tidak dapat diselesaikan. Pastikan penyedia DNS Anda mendukung catatan DS.
+ Hal ini dapat membantu untuk menyiapkan izin IAM guna mengizinkan pengguna lain, selain pemilik zona, untuk menambah atau menghapus catatan di zona. Sebagai contoh, pemilik zona dapat menambahkan KSK dan mengaktifkan penandatanganan, dan mungkin juga bertanggung jawab atas rotasi kunci. Namun, orang lain mungkin bertanggung jawab untuk bekerja dengan catatan lain pada zona yang di-hosting. Untuk contoh kebijakan IAM, lihat [Contoh izin untuk pemilik catatan domain](access-control-managing-permissions.md#example-permissions-record-owner) .
+ Untuk memeriksa apakah TLD memiliki dukungan DNSSEC, lihat. [Domain yang dapat Anda daftarkan dengan Amazon Route 53](registrar-tld-list.md)
**Topics**
+ [Mengaktifkan penandatanganan DNSSEC dan membuat rantai kepercayaan](dns-configuring-dnssec-enable-signing.md)
+ [Menonaktifkan penandatanganan DNSSEC](dns-configuring-dnssec-disable.md)
+ [Bekerja dengan kunci yang dikelola pelanggan untuk DNSSEC](dns-configuring-dnssec-cmk-requirements.md)
+ [Bekerja dengan kunci penandatanganan kunci () KSKs](dns-configuring-dnssec-ksk.md)
+ [Kunci KMS dan manajemen ZSK di Rute 53](dns-configuring-dnssec-zsk-management.md)
+ [Bukti DNSSEC tentang ketidakberadaan di Route 53](dns-configuring-dnssec-proof-of-nonexistence.md)
+ [Memecahkan masalah penandatanganan DNSSEC](dns-configuring-dnssec-troubleshoot.md)
# Mengaktifkan penandatanganan DNSSEC dan membuat rantai kepercayaan
****
Langkah-langkah tambahan berlaku untuk pemilik zona yang dihosting dan pengelola zona induk. Ini bisa menjadi orang yang sama, tetapi jika tidak, pemilik zona harus memberi tahu dan bekerja dengan pengelola zona induk.
Kami merekomendasikan mengikuti langkah-langkah dalam artikel ini agar zona Anda ditandatangani dan dimasukkan dalam rantai kepercayaan. Langkah-langkah berikut akan meminimalkan risiko orientasi ke DNSSEC.
**catatan**
Pastikan Anda membaca prasyarat sebelum memulai. [Mengonfigurasi penandatanganan DNSSEC di Amazon Route 53](dns-configuring-dnssec.md)
Ada tiga langkah yang harus diambil untuk mengaktifkan penandatanganan DNSSEC, seperti yang dijelaskan di bagian berikut.
**Topics**
+ [Langkah 1: Bersiaplah untuk mengaktifkan penandatanganan DNSSEC](#dns-configuring-dnssec-enable-signing-step-1)
+ [Langkah 2: Aktifkan penandatanganan DNSSEC dan buat KSK](#dns-configuring-dnssec-enable)
+ [Langkah 3: Membangun rantai kepercayaan](#dns-configuring-dnssec-chain-of-trust)
## Langkah 1: Bersiaplah untuk mengaktifkan penandatanganan DNSSEC
Langkah-langkah persiapan membantu Anda meminimalkan risiko orientasi ke DNSSEC dengan memantau ketersediaan zona dan menurunkan waktu tunggu antara mengaktifkan penandatanganan dan penyisipan catatan Penandatangan Delegasi (DS).
**Untuk mempersiapkan untuk mengaktifkan penandatanganan DNSSEC**
1. Pantau ketersediaan zona.
Anda dapat memantau zona untuk ketersediaan nama domain Anda. Ini dapat membantu Anda mengatasi masalah apa pun yang mungkin memerlukan mundur selangkah setelah Anda mengaktifkan penandatanganan DNSSEC. Anda dapat memantau nama domain Anda dengan sebagian besar lalu lintas dengan menggunakan pencatatan kueri. Untuk informasi selengkapnya tentang menyiapkan pencatatan kueri, lihat[Memantau Amazon Route 53](monitoring-overview.md).
Pemantauan dapat dilakukan melalui skrip shell, atau melalui layanan pihak ketiga. Namun, seharusnya tidak menjadi satu-satunya sinyal untuk menentukan apakah rollback diperlukan. Anda mungkin juga mendapatkan umpan balik dari pelanggan Anda karena domain tidak tersedia.
1. Turunkan TTL maksimum zona.
TTL maksimum zona adalah rekor TTL terpanjang di zona tersebut. Di zona contoh berikut, TTL maksimum zona adalah 1 hari (86400 detik).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)
Menurunkan TTL maksimum zona akan membantu mengurangi waktu tunggu antara mengaktifkan penandatanganan dan penyisipan catatan Penandatangan Delegasi (DS). Kami merekomendasikan untuk menurunkan TTL maksimum zona menjadi 1 jam (3600 detik). Ini memungkinkan Anda untuk memutar kembali setelah hanya satu jam jika ada penyelesai yang memiliki masalah dengan catatan yang ditandatangani caching.
**Rollback:** batalkan perubahan TTL.
1. Turunkan bidang minimum SOA TTL dan SOA.
Bidang minimum SOA adalah bidang terakhir dalam data catatan SOA. Dalam contoh berikut catatan SOA, bidang minimum memiliki nilai 5 menit (300 detik).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)
Bidang minimum SOA TTL dan SOA menentukan berapa lama resolver mengingat jawaban negatif. Setelah Anda mengaktifkan penandatanganan, server nama Route 53 mulai mengembalikan catatan NSEC untuk jawaban negatif. NSEC berisi informasi yang mungkin digunakan resolver untuk mensintesis jawaban negatif. Jika Anda harus memutar kembali karena informasi NSEC menyebabkan resolver mengasumsikan jawaban negatif untuk sebuah nama, maka Anda hanya perlu menunggu maksimum bidang minimum SOA TTL dan SOA agar resolver menghentikan asumsi.
**Rollback:** batalkan perubahan SOA.
1. Pastikan perubahan bidang minimum TTL dan SOA efektif.
Gunakan [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)untuk memastikan perubahan Anda sejauh ini telah disebarkan ke semua server DNS Route 53.
## Langkah 2: Aktifkan penandatanganan DNSSEC dan buat KSK
Anda dapat mengaktifkan penandatanganan DNSSEC dan membuat kunci penandatanganan kunci (KSK) dengan menggunakan AWS CLI atau di konsol Route 53.
+ [CLI](#dnssec_CLI)
+ [Konsol](#dnssec_console)
Saat Anda memberikan atau membuat kunci KMS, ada beberapa persyaratan. Untuk informasi selengkapnya, lihat [Bekerja dengan kunci yang dikelola pelanggan untuk DNSSEC](dns-configuring-dnssec-cmk-requirements.md).
------
#### [ CLI ]
Anda dapat menggunakan kunci yang sudah Anda miliki, atau membuatnya dengan menjalankan AWS CLI perintah seperti berikut menggunakan nilai Anda sendiri untuk`hostedzone_id`,`cmk_arn`,`ksk_name`, dan `unique_string` (untuk membuat permintaan unik):
```
aws --region us-east-1 route53 create-key-signing-key \
--hosted-zone-id $hostedzone_id \
--key-management-service-arn $cmk_arn --name $ksk_name \
--status ACTIVE \
--caller-reference $unique_string
```
Untuk informasi selengkapnya tentang kunci yang dikelola pelanggan, lihat[Bekerja dengan kunci yang dikelola pelanggan untuk DNSSEC](dns-configuring-dnssec-cmk-requirements.md). Lihat juga [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html).
Untuk mengaktifkan penandatanganan DNSSEC, jalankan AWS CLI perintah seperti berikut, menggunakan nilai Anda sendiri untuk: `hostedzone_id`
```
aws --region us-east-1 route53 enable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
```
Untuk informasi lebih lanjut, lihat [enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html)dan [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html).
------
#### [ Console ]
**Cara mengaktifkan penandatanganan DNSSEC dan membuat KSK**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Di panel navigasi, pilih **zona yang di-hosting**, lalu pilih zona yang di-hosting dengan penandatanganan DNSSEC yang ingin Anda aktifkan.
1. Di tab **Penandatanganan DNSSEC**, pilih **Aktifkan penandatanganan DNSSEC**.
**catatan**
Jika opsi di bagian ini adalah **Nonaktifkan penandatanganan DNSSEC**, Anda telah menyelesaikan langkah pertama dalam mengaktifkan penandatanganan DNSSEC. Pastikan bahwa Anda membuat, atau sudah ada, rantai kepercayaan bagi zona yang di-hosting untuk DNSSEC, lalu Anda selesai. Untuk informasi selengkapnya, lihat [Langkah 3: Membangun rantai kepercayaan](#dns-configuring-dnssec-chain-of-trust).
1. Di bagian **pembuatan Kunci Penandatanganan Kunci (KSK)**, pilih **Buat KSK baru**, dan di bawah **Berikan nama KSK, masukkan nama** untuk KSK yang akan dibuat Route 53 untuk Anda. Nama dapat mencakup angka, huruf, dan garis bawah (\$1). Nama ini harus unik.
1. Di bawah **CMK yang dikelola Pelanggan**, pilih kunci terkelola pelanggan untuk Route 53 untuk digunakan saat membuat KSK untuk Anda. Anda dapat menggunakan kunci terkelola pelanggan yang sudah ada yang berlaku untuk penandatanganan DNSSEC, atau membuat kunci terkelola pelanggan baru.
Saat Anda memberikan atau membuat kunci yang dikelola pelanggan, ada beberapa persyaratan. Untuk informasi selengkapnya, lihat [Bekerja dengan kunci yang dikelola pelanggan untuk DNSSEC](dns-configuring-dnssec-cmk-requirements.md).
1. Masukkan alias untuk kunci terkelola pelanggan yang sudah ada. Jika Anda ingin menggunakan kunci terkelola pelanggan baru, masukkan alias untuk kunci yang dikelola pelanggan, dan Route 53 akan membuatnya untuk Anda.
**catatan**
Jika Anda memilih agar Route 53 membuat kunci terkelola pelanggan, ketahuilah bahwa biaya terpisah berlaku untuk setiap kunci yang dikelola pelanggan. Untuk informasi selengkapnya, lihat [Harga Layananan Manajemen Kunci AWS](https://aws.amazon.com/kms/pricing/).
1. Pilih **Aktifkan penandatanganan DNSSEC**.
------
**Setelah Anda mengaktifkan penandatanganan zona, selesaikan langkah-langkah berikut** (apakah Anda menggunakan konsol atau CLI):
1. Pastikan penandatanganan zona efektif.
Jika digunakan AWS CLI, Anda dapat menggunakan Id operasi dari output `EnableHostedZoneDNSSEC()` panggilan untuk menjalankan [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) atau [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)untuk memastikan bahwa semua Server DNS Route 53 menandatangani tanggapan (status =). `INSYNC`
1. Tunggu setidaknya TTL maksimum zona sebelumnya.
Tunggu resolver untuk menghapus semua catatan yang tidak ditandatangani dari cache mereka. Untuk mencapai ini, Anda harus menunggu setidaknya TTL maksimum zona sebelumnya. Di `example.com` zona di atas, waktu tunggu adalah 1 hari.
1. Memantau laporan masalah pelanggan.
Setelah Anda mengaktifkan penandatanganan zona, pelanggan Anda mungkin mulai melihat masalah yang terkait dengan perangkat jaringan dan resolver. Periode pemantauan yang disarankan adalah 2 minggu.
Berikut ini adalah contoh masalah yang mungkin Anda lihat:
+ Beberapa perangkat jaringan dapat membatasi ukuran respons DNS hingga di bawah 512 byte, yang terlalu kecil untuk beberapa respons yang ditandatangani. Perangkat jaringan ini harus dikonfigurasi ulang untuk memungkinkan ukuran respons DNS yang lebih besar.
+ Beberapa perangkat jaringan melakukan inspeksi mendalam pada respons DNS dan menghapus catatan tertentu yang tidak dimengerti, seperti yang digunakan untuk DNSSEC. Perangkat ini harus dikonfigurasi ulang.
+ Beberapa resolver pelanggan mengklaim bahwa mereka dapat menerima respons UDP yang lebih besar daripada dukungan jaringan mereka. Anda dapat menguji kemampuan jaringan Anda dan mengkonfigurasi resolver Anda dengan tepat. Untuk informasi selengkapnya lihat, [DNS Reply Size Test Server](https://www.dns-oarc.net/oarc/services/replysizetest/).
**Rollback:** panggil [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) lalu kembalikan langkah-langkahnya. [Langkah 1: Bersiaplah untuk mengaktifkan penandatanganan DNSSEC](#dns-configuring-dnssec-enable-signing-step-1)
## Langkah 3: Membangun rantai kepercayaan
Setelah Anda mengaktifkan penandatanganan DNSSEC untuk zona yang di-hosting di Route 53, buat rantai kepercayaan untuk zona yang di-hosting guna menyelesaikan penyiapan penandatanganan DNSSEC. Anda melakukan ini dengan membuat catatan Delegation Signer (DS) di zona yang di-hosting *induk*, untuk zona yang di-hosting, menggunakan informasi yang disediakan Route 53. Tergantung pada tempat domain terdaftar, Anda menambahkan catatan ke zona yang di-hosting induk di Route 53 atau registrar domain lain.
**Cara membuat rantai kepercayaan untuk penandatanganan DNSSEC**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Di panel navigasi, pilih **zona yang di-hosting**, lalu pilih zona yang di-hosting yang ingin dibuatkan rantai kepercayaan DNSSEC. *Anda harus mengaktifkan penandatanganan DNSSEC terlebih dahulu.*
1. Di tab **Penandatanganan DNSSEC**, di bawah **Penandatanganan DNSSEC**, pilih **Lihat informasi untuk membuat catatan DS**.
**catatan**
Jika tidak melihat **Lihat informasi untuk membuat catatan DS** di bagian ini, Anda harus mengaktifkan penandatanganan DNSSEC sebelum membuat rantai kepercayaan. Pilih **Aktifkan penandatanganan DNSSEC** dan selesaikan langkah-langkah seperti yang dijelaskan[Langkah 2: Aktifkan penandatanganan DNSSEC dan buat KSK](#dns-configuring-dnssec-enable), lalu kembali ke langkah-langkah ini untuk membangun rantai kepercayaan.
1. Di bawah **Buat rantai kepercayaan**, pilih salah satu **Registrar Route 53** atau **Registrar domain lainnya**, tergantung tempat domain Anda terdaftar.
1. Gunakan nilai yang disediakan dari langkah 3 untuk membuat catatan DS untuk zona host induk di Route 53. Jika domain Anda tidak di-host di Route 53, gunakan nilai yang disediakan untuk membuat catatan DS di situs web registrar domain Anda.
Membangun rantai kepercayaan untuk zona induk:
+ Jika domain Anda dikelola melalui Route 53, ikuti langkah-langkah berikut:
Pastikan Anda mengonfigurasi algoritma penandatanganan yang benar (ECDSAP256SHA256 dan ketik 13) dan algoritma intisari (SHA-256 dan tipe 2).
Jika Route 53 adalah registrar Anda, lakukan hal berikut di konsol Route 53:
1. Catat nilai **Jenis kunci**, **Algoritme**, dan **Kunci publik**. Di panel navigasi, pilih **Domain terdaftar**.
1. Pilih domain, dan kemudian, dalam tab **kunci DNSSEC, pilih **Tambah** kunci**.
1. Dalam kotak dialog **Kelola kunci DNSSEC**, pilih **jenis Kunci** dan **Algoritma** yang sesuai untuk **registrar Route 53** dari menu tarik-turun.
1. Salin **Kunci publik** untuk registrar Route 53. Di kotak dialog **Kelola kunci DNSSEC**, tempelkan nilainya ke kotak **kunci Publik**.
1. Pilih **Tambahkan**.
Route 53 akan menambahkan catatan DS ke zona induk dari kunci publik. Misalnya, jika domain Anda`example.com`, catatan DS ditambahkan ke zona DNS.com.
+ Jika domain Anda dikelola di registri lain, ikuti instruksi di bagian **Registrar domain lain**.
Untuk memastikan langkah-langkah berikut berjalan lancar, perkenalkan DS TTL rendah ke zona induk. Kami merekomendasikan pengaturan DS TTL ke 5 menit (300 detik) untuk pemulihan yang lebih cepat jika Anda perlu mengembalikan perubahan Anda.
+ Membangun rantai kepercayaan untuk zona anak:
Jika zona induk Anda dikelola oleh registri lain, hubungi registrar Anda untuk memperkenalkan catatan DS untuk zona Anda. Biasanya Anda tidak akan dapat menyesuaikan TTL dari catatan DS.
+ Jika zona induk Anda di-host di Route 53, hubungi pemilik zona induk untuk memperkenalkan catatan DS untuk zona Anda.
Berikan `$ds_record_value` kepada pemilik zona induk. Anda bisa mendapatkannya dengan mengklik **Lihat Informasi untuk membuat catatan DS** di konsol dan menyalin bidang **catatan DS**, atau dengan memanggil [GetDNSSec](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) API dan mengambil nilai bidang '': DSRecord
```
aws --region us-east-1 route53 get-dnssec
--hosted-zone-id $hostedzone_id
```
Pemilik zona induk dapat memasukkan catatan melalui konsol Route 53 atau CLI.
+ Untuk menyisipkan catatan DS dengan menggunakan AWS CLI, pemilik zona induk membuat dan memberi nama file JSON yang mirip dengan contoh berikut. Pemilik zona induk mungkin memberi nama file seperti itu`inserting_ds.json`.
```
{
"HostedZoneId": "$parent_zone_id",
"ChangeBatch": {
"Comment": "Inserting DS for zone $zone_name",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "$zone_name",
"Type": "DS",
"TTL": 300,
"ResourceRecords": [
{
"Value": "$ds_record_value"
}
]
}
}
]
}
}
```
Kemudian jalankan perintah berikut:
```
aws --region us-east-1 route53 change-resource-record-sets
--cli-input-json file://inserting_ds.json
```
+ Untuk memasukkan catatan DS dengan menggunakan konsol,
Buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
Di panel navigasi, pilih Zona yang **dihosting, nama zona** yang dihosting, lalu tombol **Buat rekam**. Pastikan Anda memilih Perutean sederhana untuk kebijakan **Routing.**
Di bidang **Nama rekam** masukkan nama yang sama dengan`$zone_name`, pilih DS dari **jenis Rekam** tarik-turun, dan masukkan nilai `$ds_record_value` ke dalam bidang **Nilai**, dan pilih **Buat catatan**.
**Rollback:** hapus DS dari zona induk, tunggu DS TTL, lalu putar kembali langkah-langkah untuk membangun kepercayaan. Jika zona induk di-host di Route 53, pemilik zona induk dapat mengubah `Action` dari `UPSERT` ke `DELETE` dalam file JSON, dan menjalankan kembali contoh CLI di atas.
1. Tunggu pembaruan disebarkan, berdasarkan TTL untuk catatan domain Anda.
Jika zona induk ada di layanan DNS Route 53, pemilik zona induk dapat mengonfirmasi propagasi penuh melalui API. [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)
Jika tidak, Anda dapat secara berkala menyelidiki zona induk untuk catatan DS, dan kemudian menunggu 10 menit setelahnya untuk meningkatkan kemungkinan penyisipan catatan DS disebarkan sepenuhnya. Perhatikan bahwa beberapa pendaftar telah menjadwalkan penyisipan DS, misalnya, sekali sehari.
Saat Anda memperkenalkan catatan Penandatangan Delegasi (DS) di zona induk, resolver tervalidasi yang telah mengambil DS akan mulai memvalidasi tanggapan dari zona tersebut.
Untuk memastikan langkah-langkah membangun kepercayaan berjalan lancar, selesaikan hal-hal berikut:
1. Temukan NS TTL maksimum.
Ada 2 set catatan NS yang terkait dengan zona Anda:
+ Catatan NS delegasi — ini adalah catatan NS untuk zona Anda yang dipegang oleh zona induk. Anda dapat menemukannya dengan menjalankan perintah Unix berikut (jika zona Anda adalah example.com, zona induknya adalah com):
`dig -t NS com`
Pilih salah satu catatan NS dan kemudian jalankan yang berikut ini:
`dig @one of the NS records of your parent zone -t NS example.com`
Contoh:
`dig @b.gtld-servers.net. -t NS example.com`
+ Catatan NS dalam zona — ini adalah catatan NS di zona Anda. Anda dapat menemukan ini dengan menjalankan perintah Unix berikut:
`dig @one of the NS records of your zone -t NS example.com`
Contoh:
`dig @ns-0000.awsdns-00.co.uk. -t NS example.com`
Perhatikan TTL maksimum untuk kedua zona.
1. Tunggu NS TTL maksimum.
Sebelum penyisipan DS, resolver mendapatkan respons yang ditandatangani, tetapi tidak memvalidasi tanda tangan. Ketika catatan DS dimasukkan, resolver tidak akan melihatnya sampai catatan NS untuk zona berakhir. Ketika resolver mengambil kembali catatan NS, catatan DS kemudian akan dikembalikan.
Jika pelanggan Anda menjalankan resolver pada host dengan jam yang tidak sinkron, pastikan jam berada dalam 1 jam dari waktu yang benar.
Setelah menyelesaikan langkah ini, semua resolver yang sadar DNSSEC akan memvalidasi zona Anda.
1. Amati resolusi nama.
Anda harus memperhatikan bahwa tidak ada masalah dengan resolver yang memvalidasi zona Anda. Pastikan Anda juga memperhitungkan waktu yang dibutuhkan pelanggan Anda untuk melaporkan masalah kepada Anda.
Kami merekomendasikan pemantauan hingga 2 minggu.
1. (Opsional) Perpanjang DS dan NS TTLs.
Jika Anda puas dengan pengaturan, Anda dapat menyimpan perubahan TTL dan SOA yang Anda buat. Perhatikan bahwa Rute 53 membatasi TTL hingga 1 minggu untuk zona yang ditandatangani. Untuk informasi selengkapnya, lihat [Mengonfigurasi penandatanganan DNSSEC di Amazon Route 53](dns-configuring-dnssec.md).
Jika Anda dapat mengubah DS TTL, kami sarankan Anda mengaturnya ke 1 jam.
# Menonaktifkan penandatanganan DNSSEC
Langkah untuk menonaktifkan penandatanganan DNSSEC Route 53 dapat beragam, tergantung pada rantai kepercayaan yang menjadi bagian dari zona yang di-hosting.
Misalnya, zona yang di-hosting Anda mungkin memiliki zona induk yang memiliki catatan Delegation Signer (DS), sebagai bagian dari rantai kepercayaan. Zona yang di-hosting mungkin juga adalah zona induk untuk zona anak yang telah mengaktifkan penandatanganan DNSSEC, yang merupakan bagian lain dari rantai kepercayaan. Selidiki dan tentukan rantai kepercayaan penuh untuk zona yang di-hosting sebelum Anda mengambil langkah untuk menonaktifkan penandatanganan DNSSEC.
Rantai kepercayaan untuk zona yang di-hosting yang mengizinkan penandatanganan DNSSEC harus dibatalkan secara hati-hati saat Anda menonaktifkan penandatanganan. Untuk menghapus zona yang di-hosting dari rantai kepercayaan, Anda menghapus semua catatan DS yang ada untuk rantai kepercayaan yang mencakup zona yang di-hosting ini. Ini berarti Anda harus melakukan hal berikut, agar dapat:
1. Menghapus catatan DS yang dimiliki zona yang di-hosting untuk zona anak yang merupakan bagian dari rantai kepercayaan.
1. Hapus catatan DS dari zona induk. Lewati langkah ini jika Anda memiliki pulau kepercayaan (tidak ada catatan DS di zona induk dan tidak ada catatan DS untuk zona anak di zona ini).
1. Jika Anda tidak dapat menghapus catatan DS, untuk menghapus zona dari rantai kepercayaan, hapus catatan NS dari zona induk. Untuk informasi selengkapnya, lihat [Menambahkan atau mengubah server nama dan merekatkan catatan untuk domain](domain-name-servers-glue-records.md).
Langkah-langkah tambahan berikut memungkinkan Anda memantau efektivitas langkah-langkah individual untuk menghindari masalah ketersediaan DNS di zona Anda.
**Cara menonaktifkan penandatanganan DNSSEC**
1. Pantau ketersediaan zona.
Anda dapat memantau zona untuk ketersediaan nama domain Anda. Ini dapat membantu Anda mengatasi masalah apa pun yang mungkin memerlukan mundur selangkah setelah Anda mengaktifkan penandatanganan DNSSEC. Anda dapat memantau nama domain Anda dengan sebagian besar lalu lintas dengan menggunakan pencatatan kueri. Untuk informasi selengkapnya tentang menyiapkan pencatatan kueri, lihat[Memantau Amazon Route 53](monitoring-overview.md).
Pemantauan dapat dilakukan melalui skrip shell, atau melalui layanan berbayar. Namun, seharusnya tidak menjadi satu-satunya sinyal untuk menentukan apakah rollback diperlukan. Anda mungkin juga mendapatkan umpan balik dari pelanggan Anda karena domain tidak tersedia.
1. Temukan DS TTL saat ini.
Anda dapat menemukan DS TTL dengan menjalankan perintah Unix berikut:
`dig -t DS example.com example.com`
1. Temukan NS TTL maksimum.
Ada 2 set catatan NS yang terkait dengan zona Anda:
+ Catatan NS delegasi — ini adalah catatan NS untuk zona Anda yang dipegang oleh zona induk. Anda dapat menemukan ini dengan menjalankan perintah Unix berikut:
Pertama temukan NS zona induk Anda (jika zona Anda adalah example.com, zona induknya adalah com):
`dig -t NS com`
Pilih salah satu catatan NS dan kemudian jalankan yang berikut ini:
`dig @one of the NS records of your parent zone -t NS example.com`
Contoh:
`dig @b.gtld-servers.net. -t NS example.com`
+ Catatan NS dalam zona — ini adalah catatan NS di zona Anda. Anda dapat menemukan ini dengan menjalankan perintah Unix berikut:
`dig @one of the NS records of your zone -t NS example.com`
Contoh:
`dig @ns-0000.awsdns-00.co.uk. -t NS example.com`
Perhatikan TTL maksimum untuk kedua zona.
1. Hapus catatan DS dari zona induk.
Hubungi pemilik zona induk untuk menghapus catatan DS.
**Rollback:** masukkan kembali catatan DS, konfirmasikan penyisipan DS efektif, dan tunggu TTL NS (bukan DS) maksimum sebelum semua resolver mulai memvalidasi lagi.
1. Konfirmasikan penghapusan DS efektif.
Jika zona induk ada di layanan DNS Route 53, pemilik zona induk dapat mengonfirmasi propagasi penuh melalui API. [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)
Jika tidak, Anda dapat secara berkala menyelidiki zona induk untuk catatan DS, dan kemudian menunggu 10 menit setelahnya untuk meningkatkan kemungkinan penghapusan catatan DS disebarkan sepenuhnya. Perhatikan bahwa beberapa pendaftar telah menjadwalkan penghapusan DS, misalnya sekali sehari.
1. Tunggu DS TTL.
Tunggu sampai semua resolver telah kedaluwarsa catatan DS dari cache mereka.
1. Nonaktifkan penandatanganan DNSSEC dan nonaktifkan kunci penandatanganan kunci (KSK).
+ [CLI](#CLI_dnssec_disable)
+ [Konsol](#console_dnssec_disable)
------
#### [ CLI ]
Hubungi [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) dan. [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) APIs
Contoh:
```
aws --region us-east-1 route53 disable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
aws --region us-east-1 route53 deactivate-key-signing-key \
--hosted-zone-id $hostedzone_id --name $ksk_name
```
------
#### [ Console ]
**Untuk menonaktifkan penandatanganan DNSSEC**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Di panel navigasi, pilih **Zona yang di-hosting**, lalu pilih zona yang di-hosting dengan penandatanganan DNSSEC yang ingin Anda nonaktifkan.
1. Di tab **Penandatanganan DNSSEC**, pilih **Nonaktifkan penandatanganan DNSSEC**.
1. Di halaman **Nonaktifkan penandatanganan**, pilih salah satu opsi berikut, tergantung skenario Anda untuk zona dengan penandatangan DNSSEC yang dinonaktifkan.
+ **Zona induk saja** — Zona ini memiliki zona induk dengan catatan DS. Dalam skenario ini, Anda harus menghapus catatan DS zona induk.
+ **Zona anak saja** — Zona ini memiliki catatan DS untuk rantai kepercayaan dengan satu atau lebih zona anak. Dalam skenario ini, Anda harus menghapus catatan DS zona.
+ **Zona induk dan anak** — Zona ini memiliki catatan DS untuk rantai kepercayaan dengan satu atau lebih zona anak *dan* zona induk dengan catatan DS. Dalam skenario ini, lakukan hal-hal berikut, untuk dapat:
1. Menghapus catatan DS zona.
1. Menghapus catatan DS zona induk.
Jika Anda memiliki pulau kepercayaan, Anda dapat melewati langkah ini.
1. Tentukan apa TTL untuk setiap catatan DS yang Anda hapus di Langkah 4. , Pastikan periode TTL terpanjang telah kedaluwarsa.
1. Pilih kotak centang untuk mengonfirmasi bahwa Anda telah mengikuti langkah-langkah secara berurutan.
1. Ketik *Nonaktifkan* di bidang, seperti yang ditampilkan, lalu pilih **Nonaktifkan**.
**Untuk menonaktifkan kunci penandatanganan kunci (KSK)**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Di panel navigasi, pilih Zona yang **dihosting, lalu pilih zona** yang dihosting yang ingin Anda nonaktifkan kunci penandatanganan kunci (KSK).
1. **Di bagian **Tombol penandatanganan kunci (KSKs)**, pilih KSK yang ingin Anda nonaktifkan, dan di bawah **Tindakan**, pilih **Edit KSK, atur status KSK** **ke **Tidak Aktif**, lalu pilih Simpan KSK**.**
------
**Rollback:** [panggilan [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)dan EnableHostedZone DNSSEC.](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html) APIs
Contoh:
```
aws --region us-east-1 route53 activate-key-signing-key \
--hosted-zone-id $hostedzone_id --name $ksk_name
aws --region us-east-1 route53 enable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
```
1. Konfirmasikan penonaktifan penandatanganan zona efektif.
Gunakan Id dari `EnableHostedZoneDNSSEC()` panggilan untuk menjalankan [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)untuk memastikan bahwa semua Server DNS Route 53 telah berhenti menandatangani tanggapan (status =`INSYNC`).
1. Amati resolusi nama.
Anda harus mengamati bahwa tidak ada masalah yang mengakibatkan resolver memvalidasi zona Anda. Biarkan 1-2 minggu untuk memperhitungkan waktu yang dibutuhkan pelanggan Anda untuk melaporkan masalah kepada Anda.
1. (Opsional) Bersihkan.
Jika Anda tidak akan mengaktifkan kembali penandatanganan, Anda dapat membersihkan KSKs [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)dan menghapus kunci yang dikelola pelanggan yang sesuai untuk menghemat biaya.
# Bekerja dengan kunci yang dikelola pelanggan untuk DNSSEC
Saat Anda mengaktifkan penandatanganan DNSSEC di Amazon Route 53, Route 53 akan membuat kunci penandatanganan kunci (KSK) untuk Anda. Untuk membuat KSK, Route 53 harus menggunakan kunci yang dikelola pelanggan AWS Key Management Service yang mendukung DNSSEC. Bagian ini menjelaskan detail dan persyaratan untuk kunci yang dikelola pelanggan yang berguna untuk diketahui saat Anda bekerja dengan DNSSEC.
Ingatlah hal-hal berikut saat Anda bekerja dengan kunci yang dikelola pelanggan untuk DNSSEC:
+ Kunci terkelola pelanggan yang Anda gunakan dengan penandatanganan DNSSEC harus berada di Wilayah AS Timur (Virginia N.).
+ Kunci yang dikelola pelanggan harus berupa kunci yang [dikelola pelanggan asimetris dengan spesifikasi kunci](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks) [ECC\$1NIST\$1P256](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc). Kunci yang dikelola pelanggan ini hanya digunakan untuk penandatanganan dan verifikasi. Untuk bantuan membuat kunci terkelola pelanggan asimetris, lihat [Membuat kunci terkelola pelanggan asimetris](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk) di Panduan AWS Key Management Service Pengembang. Untuk bantuan menemukan konfigurasi kriptografi dari kunci terkelola pelanggan yang sudah ada, lihat [Melihat konfigurasi kriptografi kunci yang dikelola pelanggan di Panduan](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html) AWS Key Management Service Pengembang.
+ Jika Anda membuat sendiri kunci terkelola pelanggan untuk digunakan dengan DNSSEC di Route 53, Anda harus menyertakan pernyataan kebijakan kunci tertentu yang memberikan izin yang diperlukan kepada Route 53. Route 53 harus dapat mengakses kunci yang dikelola pelanggan Anda sehingga dapat membuat KSK untuk Anda. Untuk informasi selengkapnya, lihat [Route 53 izin kunci terkelola pelanggan yang diperlukan untuk penandatanganan DNSSEC](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC).
+ Route 53 dapat membuat kunci terkelola pelanggan untuk Anda gunakan dengan penandatanganan DNSSEC tanpa izin tambahan AWS KMS . AWS KMS Namun, Anda harus memiliki izin khusus jika ingin mengedit kunci setelah dibuat. Izin khusus yang harus Anda miliki adalah sebagai berikut: `kms:UpdateKeyDescription`, `kms:UpdateAlias`, dan `kms:PutKeyPolicy`.
+ Ketahuilah bahwa biaya terpisah berlaku untuk setiap kunci terkelola pelanggan yang Anda miliki, apakah Anda membuat kunci yang dikelola pelanggan atau Route 53 membuatnya untuk Anda. Untuk informasi selengkapnya, lihat [harga AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
# Bekerja dengan kunci penandatanganan kunci () KSKs
Jika Anda mengaktifkan pendatanganan DNSSEC, Route 53 membuat kunci penandatanganan kunci (KSK) untuk Anda. Anda dapat memiliki hingga dua KSKs per zona yang dihosting di Route 53. Setelah mengaktifkan penandatanganan DNSSEC, Anda dapat menambahkan, menghapus, atau mengedit. KSKs
Perhatikan hal berikut ketika Anda bekerja dengan Anda KSKs:
+ Sebelum dapat menghapus KSK, Anda harus mengedit KSK untuk mengatur statusnya ke **Tidak aktif**.
+ Jika penandatanganan DNSSEC diaktifkan untuk zona yang di-hosting, Route 53 membatasi TTL menjadi satu minggu. Jika Anda menetapkan TTL untuk catatan di zona yang di-hosting ke lebih dari satu minggu, Anda tidak akan mendapatkan kesalahan, namun Route 53 memberlakukan TTL selama satu minggu.
+ Untuk membantu mencegah pemadaman zona dan menghindari masalah tidak tersedianya domain Anda, Anda harus cepat mengatasi dan menyelesaikan kesalahan DNSSEC. Kami sangat menyarankan agar Anda mengatur CloudWatch alarm yang memberi tahu Anda setiap kali `DNSSECKeySigningKeysNeedingAction` kesalahan `DNSSECInternalFailure` atau terdeteksi. Untuk informasi selengkapnya, lihat [Memantau zona yang dihosting menggunakan Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
+ Operasi KSK yang dijelaskan di bagian ini memungkinkan Anda untuk memutar zona Anda. KSKs Untuk informasi selengkapnya dan step-by-step contoh, lihat *Rotasi Kunci DNSSEC* di posting blog [Mengonfigurasi penandatanganan dan validasi DNSSEC](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/) dengan Amazon Route 53.
Untuk bekerja dengan KSKs di Konsol Manajemen AWS, ikuti panduan di bagian berikut.
## Menambahkan kunci penandatanganan kunci (KSK)
Jika Anda mengaktifkan pendatanganan DNSSEC, Route 53 membuat kunci penandatanganan kunci (KSK) untuk Anda. Anda juga dapat menambahkan KSKs secara terpisah. Anda dapat memiliki hingga dua KSKs per zona yang dihosting di Route 53.
Ketika Anda membuat KSK, Anda harus menyediakan atau meminta Route 53 untuk membuat kunci yang dikelola pelanggan untuk digunakan dengan KSK. Saat Anda memberikan atau membuat kunci yang dikelola pelanggan, ada beberapa persyaratan. Untuk informasi selengkapnya, lihat [Bekerja dengan kunci yang dikelola pelanggan untuk DNSSEC](dns-configuring-dnssec-cmk-requirements.md).
Ikuti langkah-langkah berikut untuk menambahkan KSK di Konsol Manajemen AWS.
**Cara menambahkan KSK**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Di panel navigasi, pilih **Zona yang di-hosting**, lalu pilih zona yang di-hosting.
1. **Pada tab **penandatanganan DNSSEC**, di bawah **Tombol penandatanganan kunci (KSKs)**, pilih **Beralih ke tampilan lanjutan**, lalu, di bawah **Tindakan**, pilih Tambahkan KSK.**
1. Di bawah **KSK**, masukkan nama untuk KSK yang akan dibuat Route 53 untuk Anda. Nama dapat mencakup angka, huruf, dan garis bawah (\$1). Nama ini harus unik.
1. Masukkan alias untuk kunci terkelola pelanggan yang berlaku untuk penandatanganan DNSSEC, atau masukkan alias untuk kunci terkelola pelanggan baru yang akan dibuat Route 53 untuk Anda.
**catatan**
Jika Anda memilih agar Route 53 membuat kunci terkelola pelanggan, ketahuilah bahwa biaya terpisah berlaku untuk setiap kunci yang dikelola pelanggan. Untuk informasi selengkapnya, lihat [harga AWS Key Management Service](https://aws.amazon.com/kms/pricing/).
1. Pilih **Buat KSK**.
## Mengedit kunci penandatanganan kunci (KSK)
Anda dapat mengedit status KSK agar menjadi **Aktif** atau **Tidak aktif**. Ketika KSK aktif, Route 53 menggunakan KSK untuk penandatanganan DNSSEC. Sebelum dapat menghapus KSK, Anda harus mengedit KSK untuk mengatur statusnya ke **Tidak aktif**.
Ikuti langkah-langkah berikut untuk mengedit KSK di Konsol Manajemen AWS.
**Cara mengedit KSK**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Di panel navigasi, pilih **Zona yang di-hosting**, lalu pilih zona yang di-hosting.
1. **Pada tab **penandatanganan DNSSEC**, di bawah **Tombol penandatanganan kunci (KSKs)**, pilih **Beralih ke tampilan lanjutan**, lalu, di bawah **Tindakan**, pilih Edit KSK.**
1. Lakukan pembaruan yang diinginkan ke KSK, lalu pilih **Simpan**.
## Menghapus kunci penandatanganan kunci (KSK)
Sebelum dapat menghapus KSK, Anda harus mengedit KSK untuk mengatur statusnya ke **Tidak aktif**.
Salah satu alasan Anda menghapus KSK adalah sebagai bagian dari rotasi kunci rutin. Memutar kunci kriptografi secara berkala merupakan praktik terbaik. Organisasi mungkin memiliki panduan standar terkait seberapa sering Anda harus merotasi kunci.
Ikuti langkah-langkah berikut untuk menghapus KSK di Konsol Manajemen AWS.
**Cara menghapus KSK**
1. Masuk ke Konsol Manajemen AWS dan buka konsol Route 53 di [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Di panel navigasi, pilih **Zona yang di-hosting**, lalu pilih zona yang di-hosting.
1. **Pada tab **penandatanganan DNSSEC**, di bawah **Tombol penandatanganan kunci (KSKs)**, pilih **Beralih ke tampilan lanjutan**, lalu di bawah **Tindakan**, pilih Hapus KSK.**
1. Ikuti panduan untuk mengonfirmasi penghapusan KSK.
# Kunci KMS dan manajemen ZSK di Rute 53
Bagian ini menjelaskan praktik saat ini yang digunakan Route 53 untuk zona aktif penandatanganan DNSSEC Anda.
**catatan**
Route 53 menggunakan aturan berikut yang mungkin berubah. Setiap perubahan di masa depan tidak akan mengurangi postur keamanan zona atau Route 53 Anda.
**Bagaimana Route 53 menggunakan yang AWS KMS terkait dengan KSK Anda**
Dalam DNSSEC, KSK digunakan untuk menghasilkan tanda tangan catatan sumber daya (RRSIG) untuk kumpulan catatan sumber daya DNSKEY. Semua `ACTIVE` KSKs digunakan dalam generasi RRSIG. Route 53 menghasilkan RRSIG dengan memanggil `Sign` AWS KMS API pada kunci KMS terkait. Untuk informasi selengkapnya, lihat [Masuk](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html) *panduan AWS KMS API*. Ini RRSIGs tidak dihitung terhadap batas set catatan sumber daya zona.
RRSIG memiliki kedaluwarsa. Untuk RRSIGs mencegah kedaluwarsa, disegarkan RRSIGs secara teratur dengan meregenerasinya setiap satu hingga tujuh hari.
RRSIGs Ini juga disegarkan setiap kali Anda memanggil salah satu dari ini APIs:
+ [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)
+ [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html)
+ [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html)
+ [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)
+ [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)
+ [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)
Setiap kali Route 53 melakukan penyegaran, kami menghasilkan 15 RRSIGs untuk mencakup beberapa hari ke depan jika kunci KMS terkait menjadi tidak dapat diakses. Untuk estimasi biaya utama KMS, Anda dapat mengasumsikan penyegaran reguler sekali sehari. Kunci KMS mungkin menjadi tidak dapat diakses oleh perubahan yang tidak disengaja pada kebijakan kunci KMS. Kunci KMS yang tidak dapat diakses akan menyetel status KSK terkait ke. `ACTION_NEEDED` Kami sangat menyarankan Anda memantau kondisi ini dengan mengatur CloudWatch alarm setiap kali `DNSSECKeySigningKeysNeedingAction` kesalahan terdeteksi karena memvalidasi resolver akan mulai gagal pencarian setelah RRSIG terakhir kedaluwarsa. Untuk informasi selengkapnya, lihat [Memantau zona yang dihosting menggunakan Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
**Bagaimana Route 53 mengelola ZSK zona Anda**
Setiap zona host baru dengan penandatanganan DNSSEC diaktifkan akan memiliki satu kunci penandatanganan `ACTIVE` zona (ZSK). ZSK dibuat secara terpisah untuk setiap zona yang dihosting dan dimiliki oleh Route 53. Algoritma kunci saat ini adalah ECDSAP256SHA256.
Kami akan mulai melakukan rotasi ZSK reguler di zona dalam waktu 7-30 hari sejak dimulainya penandatanganan. Saat ini, Route 53 menggunakan metode Pre-Publish Key Rollover. Untuk informasi selengkapnya, lihat [Rollover Kunci Penandatanganan Zona Pra-Publikasikan](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1). Metode ini akan memperkenalkan ZSK lain ke zona tersebut. Rotasi akan diulang setiap 7-30 hari.
Route 53 akan menangguhkan rotasi ZSK jika salah satu zona KSK berada dalam `ACTION_NEEDED` status karena Route 53 tidak akan dapat meregenerasi set catatan sumber daya DNSKEY untuk memperhitungkan perubahan di ZSK zona. RRSIGs Rotasi ZSK akan secara otomatis dilanjutkan setelah kondisi dibersihkan.
# Bukti DNSSEC tentang ketidakberadaan di Route 53
**catatan**
Route 53 menggunakan aturan berikut yang mungkin berubah. Setiap perubahan di masa depan tidak akan mengurangi postur keamanan zona atau Route 53 Anda.
Ada tiga jenis bukti ketidakberadaan di DNSSEC:
+ Bukti tidak adanya catatan yang cocok dengan nama kueri.
+ Bukti tidak adanya tipe yang cocok dengan tipe kueri.
+ Bukti keberadaan catatan wildcard yang digunakan untuk menghasilkan catatan sebagai tanggapan.
Route 53 mengimplementasikan bukti tidak adanya catatan yang cocok dengan nama kueri menggunakan metode BL. Untuk informasi lebih lanjut, lihat [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00). Ini adalah metode yang menghasilkan representasi kompak dari bukti dan mencegah zona berjalan.
Dalam kasus di mana ada catatan yang cocok dengan nama kueri tetapi bukan jenis kueri (seperti kueri untuk web.example. com/AAAA but there is only web.example.com/Apresent), kami mengembalikan catatan NSEC (next secure) minimal yang berisi semua jenis catatan sumber daya yang didukung.
Ketika Route 53 mensintesis jawaban dari catatan wildcard, respons tidak akan disertai dengan catatan aman berikutnya, atau catatan NSEC untuk wildcard. Catatan NSEC semacam itu digunakan dalam beberapa implementasi, biasanya yang melakukan penandatanganan offline, untuk mencegah tanda tangan catatan sumber daya (RRSIG) dalam respons digunakan kembali untuk menipu respons yang berbeda. Route 53 menggunakan penandatanganan online untuk catatan non-DNSkey untuk menghasilkan RRSIGs spesifik untuk respons yang tidak dapat digunakan kembali untuk respons yang berbeda.
# Memecahkan masalah penandatanganan DNSSEC
Informasi di bagian ini dapat membantu Anda mengatasi masalah dengan penandatanganan DNSSEC, termasuk mengaktifkan, menonaktifkan, dan dengan kunci penandatanganan kunci (). KSKs
Mengaktifkan DNSSEC
Pastikan Anda telah membaca prasyarat [Mengonfigurasi penandatanganan DNSSEC di Amazon Route 53](dns-configuring-dnssec.md) sebelum Anda mulai mengaktifkan penandatanganan DNSSEC.
Menonaktifkan DNSSEC
Untuk menonaktifkan DNSSEC dengan aman, Route 53 akan memeriksa apakah zona target berada dalam rantai kepercayaan. Ini memeriksa apakah induk dari zona target memiliki catatan NS dari zona target dan catatan DS dari zona target. Jika zona target tidak dapat diselesaikan secara publik, misalnya, mendapatkan respons SERVFAIL saat menanyakan NS dan DS, Route 53 tidak dapat menentukan apakah aman untuk menonaktifkan DNSSEC. Anda dapat menghubungi zona induk Anda untuk memperbaiki masalah tersebut, dan coba lagi menonaktifkan DNSSEC nanti.
Status KSK adalah **Diperlukan tindakan**
KSK dapat mengubah statusnya menjadi **Tindakan yang diperlukan** (atau `ACTION_NEEDED` dalam [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)status), ketika Route 53 DNSSEC kehilangan akses ke yang sesuai AWS KMS key (karena perubahan izin atau penghapusan). AWS KMS key
Jika status KSK **diperlukan Tindakan**, itu berarti bahwa pada akhirnya itu akan menyebabkan pemadaman zona untuk klien yang menggunakan DNSSEC memvalidasi resolver dan Anda harus bertindak cepat untuk mencegah zona produksi menjadi tidak dapat diselesaikan.
Untuk memperbaiki masalah, pastikan bahwa kunci terkelola pelanggan yang menjadi dasar KSK Anda diaktifkan dan memiliki izin yang benar. Untuk informasi lebih lanjut tentang izin yang diperlukan, lihat [Route 53 izin kunci terkelola pelanggan yang diperlukan untuk penandatanganan DNSSEC](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC).
Setelah Anda memperbaiki KSK, aktifkan lagi dengan menggunakan konsol atau AWS CLI, seperti yang dijelaskan dalam[Langkah 2: Aktifkan penandatanganan DNSSEC dan buat KSK](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable).
Untuk mencegah masalah ini di masa mendatang, pertimbangkan untuk menambahkan Amazon CloudWatch metrik untuk melacak keadaan KSK seperti yang disarankan di[Mengonfigurasi penandatanganan DNSSEC di Amazon Route 53](dns-configuring-dnssec.md).
Status KSK adalah **Kegagalan internal**
Ketika KSK memiliki status **kegagalan internal** (atau `INTERNAL_FAILURE` dalam [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)status), Anda tidak dapat bekerja dengan entitas DNSSEC lainnya sampai masalah teratasi. Anda harus mengambil tindakan sebelum dapat bekerja dengan penandatanganan DNSSEC, termasuk bekerja dengan KSK ini atau KSK lainnya.
Untuk memperbaiki masalah, coba aktifkan lagi atau nonaktifkan KSK.
[Untuk memperbaiki masalah saat bekerja dengan APIs, coba aktifkan penandatanganan ([EnableHostedZoneDNSSEC) atau nonaktifkan penandatanganan (DNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)). DisableHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)
Anda harus segera memperbaiki masalah **Kegagalan internal**. Anda tidak dapat membuat perubahan lain ke zona yang di-hosting hingga masalah diperbaiki, kecuali operasi untuk memperbaiki **Kegagalan internal**.
# Menggunakan AWS Cloud Map untuk membuat catatan dan pemeriksaan kesehatan
Jika ingin merutekan lalu lintas internet atau lalu lintas dalam Amazon VPC ke komponen aplikasi atau layanan mikro, Anda dapat menggunakan AWS Cloud Map untuk membuat catatan secara otomatis dan, secara opsional, untuk membuat pemeriksaan kondisi. Lihat informasi selengkapnya di [Panduan Developer AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/).
# Kendala dan perilaku DNS
Olahpesan DNS tunduk pada faktor-faktor yang memengaruhi cara Anda membuat dan menggunakan zona serta catatan yang di-hosting. Bagian ini menjelaskan faktor-faktor tersebut.
## Ukuran respons maksimum
Untuk memenuhi standar DNS, ukuran respons yang dikirim melalui UDP tidak lebih dari 512 byte. Respons yang melebihi 512 byte akan dipotong dan penyelesai harus mengeluarkan kembali permintaan melalui TCP. Jika resolver mendukung EDNS0 (seperti yang didefinisikan dalam [RFC 2671](https://tools.ietf.org/html/rfc2671)), dan mengiklankan opsi EDNS0 ke Amazon Route 53, Route 53 mengizinkan respons hingga 4096 byte melalui UDP, tanpa pemotongan.
## Pemrosesan bagian otoritatif
Agar kueri berhasil, Route 53 menambahkan catatan nama server (NS) untuk zona yang di-hosting yang relevan ke bagian Otoritas respons DNS. Untuk nama yang tidak ditemukan (respons NXDOMAIN), Route 53 menambahkan catatan Start of Authority (SOA) (seperti yang ditentukan dalam [RFC 1035](https://tools.ietf.org/html/rfc1035)) untuk zona yang di-hosting yang relevan ke bagian Otoritas respons DNS.
## Pemrosesan bagian tambahan
Route 53 menambahkan catatan ke bagian Tambahan. Jika catatan diketahui dan sesuai, layanan menambahkan catatan A atau AAAA untuk setiap target catatan MX, CNAME, NS, atau SRV yang dikutip di bagian Jawaban. Untuk informasi selengkapnya tentang tipe catatan DNS ini, lihat [Tipe data DNS yang didukung](ResourceRecordTypes.md).
# Topik terkait
Untuk informasi tentang mentransfer pendaftaran domain (bukan hanya hosting DNS) ke Route 53, lihat topik berikut:
+ [Daftar periksa pra-transfer untuk transfer domain](domain-transfer-checklist.md)— Lengkapi daftar periksa ini sebelum mentransfer pendaftaran domain untuk menghindari kegagalan transfer umum.
+ [Mentransfer pendaftaran untuk domain ke Amazon Route 53](domain-transfer-to-route-53.md)— Step-by-step proses untuk mentransfer pendaftaran domain dari registrar lain ke Route 53.
+ [Mentransfer domain](domain-transfer.md)— Ikhtisar semua opsi transfer domain, termasuk transfer antar AWS akun.