DNS HTTPS Record dan SVCB: Cara Browser Menemukan Layanan Web Modern

Ketika browser membuka sebuah situs, DNS biasanya digunakan untuk menemukan alamat server berdasarkan nama domain. Selain record A dan AAAA, ekosistem DNS modern memiliki record HTTPS dan SVCB yang dapat menyampaikan informasi tambahan tentang cara mengakses layanan. Informasi tersebut dapat mencakup protokol yang didukung, target layanan, dan parameter koneksi. Record ini bukan pengganti DNS biasa, melainkan petunjuk tambahan yang dapat dimanfaatkan klien yang kompatibel.

Apa Itu Record HTTPS dan SVCB?

SVCB adalah singkatan dari Service Binding. Record ini dirancang untuk mengumumkan parameter yang membantu klien menemukan endpoint layanan dan memahami cara terbaik untuk terhubung. Record HTTPS menggunakan format yang sama, tetapi secara khusus ditujukan untuk layanan HTTPS. Keduanya distandardisasi dalam RFC 9460.

Record ini memiliki beberapa komponen, termasuk priority, target name, dan parameter opsional. Priority membedakan mode penggunaan: nilai 0 digunakan untuk AliasMode, sedangkan nilai lebih besar digunakan untuk ServiceMode. Dalam ServiceMode, pemilik domain dapat mengumumkan parameter layanan tanpa harus mengubah nama domain yang diketik pengguna.

Mengapa Informasi Ini Berguna?

Record HTTPS dapat membantu klien mengetahui opsi koneksi sebelum membuat koneksi ke server. Salah satu parameter yang dikenal adalah alpn, yang mengumumkan protokol lapisan aplikasi seperti HTTP/2 atau HTTP/3. Parameter lain dapat menunjukkan port alternatif, nama target, atau informasi terkait Encrypted Client Hello (ECH) ketika didukung oleh klien dan infrastruktur.

• Negosiasi protokol: klien yang kompatibel dapat mengetahui protokol yang didukung layanan, misalnya HTTP/3 melalui ALPN yang sesuai.
• Penemuan endpoint: target layanan dan parameter lain dapat membantu klien memilih tujuan koneksi yang tepat.
• Optimasi koneksi: sebagian informasi dapat mengurangi percobaan koneksi yang tidak perlu, tergantung implementasi klien.
• Privasi koneksi: parameter ECH dapat menjadi bagian dari konfigurasi untuk melindungi informasi tertentu pada tahap awal koneksi, tetapi tidak otomatis aktif hanya karena record HTTPS tersedia.

Contoh Bentuk Record

Contoh berikut hanya ilustrasi sintaks, bukan konfigurasi yang harus langsung disalin ke DNS produksi:

example.com. 3600 IN HTTPS 1 . alpn="h2,h3"

Dalam contoh ini, priority 1 menunjukkan ServiceMode dan target titik (.) berarti nama pemilik record digunakan sebagai target. Parameter alpn mengiklankan protokol yang didukung. Sintaks persis yang diterima panel DNS dapat berbeda; beberapa panel menyediakan kolom terpisah untuk priority, target, dan parameter.

Record yang salah format atau bertentangan dengan infrastruktur yang sebenarnya dapat membuat klien gagal memakai opsi yang diumumkan. Karena itu, jangan menyatakan HTTP/3 atau ECH tersedia sebelum server, TLS, CDN, dan aplikasi benar-benar mendukungnya.

Perbedaan HTTPS Record dengan A dan AAAA

Record A memetakan nama ke alamat IPv4, sedangkan AAAA memetakan nama ke alamat IPv6. HTTPS dan SVCB tidak sekadar memberikan alamat IP; keduanya menyampaikan informasi tentang layanan dan opsi koneksi. Klien biasanya tetap membutuhkan resolusi alamat yang sesuai untuk benar-benar mencapai server, kecuali informasi atau alur koneksi lain menyediakannya.

Record HTTPS juga tidak sama dengan sertifikat TLS. Record DNS membantu menemukan layanan dan parameternya, sementara sertifikat serta proses TLS tetap digunakan untuk mengautentikasi server dan membangun koneksi terenkripsi. DNSSEC dapat membantu memvalidasi keaslian data DNS bila zona dan resolver mendukungnya, tetapi DNSSEC bukan pengganti TLS.

Cara Memeriksa Konfigurasi

1. Periksa dukungan penyedia DNS. Pastikan panel DNS menerima tipe record HTTPS dan format parameter yang diperlukan.
2. Mulai dari lingkungan uji. Gunakan subdomain pengujian atau lakukan perubahan saat ada rencana rollback yang jelas.
3. Periksa jawaban DNS. Gunakan alat seperti dig yang mendukung tipe record HTTPS, misalnya dig HTTPS example.com. Untuk SVCB, kueri tipe record SVCB secara eksplisit jika diperlukan.
4. Uji dari klien kompatibel. Pastikan browser atau aplikasi benar-benar memahami record tersebut. Hasil kueri DNS saja tidak membuktikan bahwa klien memakai setiap parameter.
5. Pantau dan siapkan rollback. Amati error koneksi, negosiasi protokol, dan log server. Jika muncul masalah, kembalikan record ke konfigurasi sebelumnya sambil menyelidiki parameter yang keliru.

Kesalahan yang Perlu Dihindari

Jangan menyalin record dari domain lain tanpa memahami target dan infrastrukturnya. Hindari mengiklankan protokol yang belum aktif di server, dan perhatikan TTL saat merencanakan perubahan. Ingat pula bahwa resolver, cache, browser, dan jaringan perantara bisa memiliki perilaku berbeda; perubahan DNS mungkin tidak terlihat serentak oleh semua pengguna.

Memahami Perbedaan Resolver dan Browser

Ketika memeriksa hasil, bedakan jawaban dari server DNS otoritatif, jawaban resolver rekursif, dan perilaku browser. Server otoritatif menunjukkan record yang sudah dipublikasikan, sedangkan resolver dapat masih menyimpan jawaban lama sesuai TTL. Browser juga dapat memiliki kebijakan implementasi sendiri dan tidak selalu menggunakan setiap parameter yang diumumkan. Karena itu, satu hasil dari dig belum cukup untuk menyimpulkan pengalaman semua pengunjung.

Baca juga: QUIC Connection Migration: Koneksi Tetap Aktif saat Berpindah Jaringan.

Referensi resmi: RFC 9460 tentang DNS SVCB dan HTTPS Records.

Untuk perubahan penting, catat jawaban DNS sebelum dan sesudah penerapan, periksa TTL, dan uji dari beberapa resolver serta jaringan. Pastikan fallback tersedia jika klien atau resolver tidak memahami record HTTPS/SVCB.

Kesimpulan

Record HTTPS dan SVCB memungkinkan DNS mengumumkan parameter layanan yang membantu klien menemukan cara terhubung yang sesuai. Penerapannya perlu mempertimbangkan kompatibilitas, prioritas record, parameter, dan fallback. Validasi konfigurasi bertahap serta gunakan RFC 9460 sebagai rujukan.