View a markdown version of this page

Tipe data DNS yang didukung - Amazon Route 53
Jenis catatanJenis catatan AAAAJenis catatan CAAJenis catatan CNAMETipe catatan DSJenis catatan HTTPSTipe catatan MXJenis catatan NAPTRTipe catatan NSTipe catatan PTRJenis catatan SOATipe catatan SPFTipe catatan SRVJenis catatan SSHFPJenis catatan SVCBJenis catatan TLSATipe catatan TXT

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

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 memperlakukanwww.example.com(tanpa titik akhir) danwww.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.

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

<Value>192.0.2.1</Value>

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

<Value>2001:0db8:85a3:0:0:8a2e:0370:7334</Value>

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

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 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 [email protected], Anda membuat catatan CAA dengan pengaturan berikut:

0 iodef "mailto:[email protected]"

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:[email protected]"

Contoh untuk API Route 53

<ResourceRecord>
   <Value>0 issue "ca.example.net"</Value>
   <Value>0 iodef "mailto:[email protected]"</Value>
</ResourceRecord>

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.

Contoh untuk konsol Route 53

hostname.example.com

Contoh untuk API Route 53

<Value>hostname.example.com</Value>

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.

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.

Contoh untuk konsol Route 53

123 4 5 1234567890abcdef1234567890absdef

Contoh untuk API Route 53

<Value>123 4 5 1234567890abcdef1234567890absdef</Value>

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, 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

<Value>0 example.com</Value>

Contoh untuk API Route 53 untuk mode layanan

<Value>16 example.com alpn="h2,h3" port=808</Value>

Untuk informasi selengkapnya, lihat RFC 9460, Service Binding dan Spesifikasi Parameter melalui DNS (SVCB 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 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

<Value>10 mail.example.com</Value>

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 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:

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)

  • ! # $ % & ' ( ) * + , - / : ; < = > ? @ [ ] ^ _ ` { | } ~ .

  • " (tanda kutip). Untuk menyertakan kutipan literal dalam string, awali dengan \ karakter: \".

  • \ (garis miring terbalik). Untuk menyertakan garis miring terbalik dalam string, awali dengan karakter \: \\.

Tentukan semua nilai lainnya, seperti nama domain internasional, dalam format oktal.

Untuk sintaks untuk Regexp, lihat RFC 3402, bagian 3.2, Sintaks Ekspresi Substitusi

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

Contoh untuk konsol Amazon Route 53

100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\[email protected]!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:[email protected]!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:[email protected]!" .

Contoh untuk API Route 53

<ResourceRecord>
   <Value>100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\[email protected]!" .</Value>
   <Value>100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:[email protected]!" .</Value>
   <Value>100 52 "u" "E2U+email:mailto" "!^.*$!mailto:[email protected]!" .</Value>
</ResourceRecord>

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.

  • Anda juga menggunakan data NS untuk mengonfigurasi server nama label putih. Untuk informasi selengkapnya, lihat Mengonfigurasi server nama label putih.

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

Untuk informasi lebih lanjut tentang catatan NS, lihat Catatan NS dan SOA yang dibuat Amazon Route 53 untuk zona yang di-hosting publik.

Contoh untuk konsol Amazon Route 53

ns-1.example.com

Contoh untuk API Route 53

<Value>ns-1.example.com</Value>

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

<Value>hostname.example.com</Value>

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.

Contoh untuk konsol Route 53

ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60

Contoh untuk API Route 53

<Value>ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60</Value>

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.

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.

Contoh untuk konsol Amazon Route 53

"v=spf1 ip4:192.168.0.1/16 -all"

Contoh untuk API Route 53

<Value>"v=spf1 ip4:192.168.0.1/16 -all"</Value>

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

<Value>10 5 80 hostname.example.com</Value>

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

Format untuk catatan sumber daya SSHFP adalah:

[Key Algorithm] [Hash Type] Fingerprint

Parameter berikut didefinisikan dalam RFC 4255.

Algoritma Kunci

Jenis algoritma:

  • 0— Dicadangkan dan tidak digunakan.

  • 1: RSAAlgoritma Rivest—Shamir—Adleman adalah salah satu kriptosistem kunci publik pertama dan masih digunakan untuk transmisi data yang aman.

  • 2: DSAAlgoritma 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: Ed25519Algoritma 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

<Value>1 1 09F6A01D2175742B257C6B98B7C72C44C4040683</Value>

Untuk informasi selengkapnya, lihat RFC 4255: Menggunakan DNS untuk Mempublikasikan Sidik Jari Kunci Secure Shell (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, 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

<Value>0 example.com</Value>

Contoh untuk API Route 53 untuk mode layanan

<Value>16 example.com alpn="h2,h3" port=808</Value>

Untuk informasi selengkapnya, lihat RFC 9460, Service Binding dan Spesifikasi Parameter melalui DNS (SVCB 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

Format untuk catatan sumber daya TLSA adalah:

[Certificate usage] Selector [Matching type] [Certificate association data]

Parameter berikut ditentukan dalam RFC 6698, bagian 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

<Value>0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971</Value>

Untuk informasi selengkapnya, lihat RFC 6698, Protokol Transport Layer Security (TLS) Transport Layer Security (DANE) Berbasis DNS: TLSA.

Tipe catatan TXT

Catatan TXT berisi satu atau lebih string yang diapit dengan tanda petik ganda ("). Saat Anda menggunakan kebijakan perutean sederhana, sertakan semua nilai untuk domain (example.com) atau subdomain (www.example.com) dalam data TXT yang sama.

Memasukkan nilai catatan TXT

Satu string dapat berisi hingga 255 karakter, termasuk yang berikut:

  • a-z

  • A-Z

  • 0-9

  • Spasi

  • - (tanda hubung)

  • ! " # $ % & ' ( ) * + , - / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ .

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:

<Value>"String 1" "String 2" "String 3"</Value>

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.

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:

<Value>"This string includes \"quotation marks\"."</Value>
<Value>"The last character in this string is an accented e specified in octal format: \351"</Value>
<Value>"v=spf1 ip4:192.168.0.1/16 -all"</Value>