Temu duga umum: menerangkan rekod DNS SVCB dan HTTPS

Prompt dan skop

Satu pasukan mahu DNS menerbitkan data service-binding supaya klien dapat menemui hos alternatif, port, protokol, dan pembayang (hints) TLS, dengan mengutamakan HTTP/3 apabila tersedia. Terangkan rekod SVCB dan HTTPS, keutamaan, AliasMode, caching, dan sempadan keselamatan. RFC 9460 mentakrifkan SVCB dan varian HTTP-nya, tetapi pembayang DNS tidak menggantikan pengesahan sijil, semantik HTTP, atau pembenaran (authorization).

Perkara yang dinilai oleh penemu duga

• Mengetahui bahawa HTTPS ialah varian SVCB khusus untuk HTTP.
• Membezakan AliasMode dan ServiceMode serta peraturan keutamaannya.
• Memahami bahawa alpn, port, dan pembayang alamat ialah pembayang sambungan.
• Menerangkan sempadan kepercayaan DNSSEC, DoH/DoT, dan DNS biasa.
• Mereka bentuk TTL, fallback, pemantauan, dan pembatalan (revocation).

Penjelasan yang perlu ditanya terlebih dahulu

Sahkan versi klien dan resolver, sama ada matlamatnya adalah aliasing atau pemilihan protokol, penggunaan DNSSEC dan encrypted-DNS, keperluan fallback HTTP/3, serta matlamat sijil dan ketersediaan. Jika tidak dinyatakan, anggap sesetengah resolver tidak memahami rekod HTTPS.

Rangka jawapan tiga puluh saat

Anggap rekod HTTPS sebagai penemuan perkhidmatan HTTP. AliasMode keutamaan 0 menghala ke nama lain dan memerlukan carian lain; rekod ServiceMode bukan sifar menerangkan perkhidmatan. alpn dan port membantu memilih sambungan tetapi tidak memberikan pembenaran atau menggantikan pengesahan TLS. Jika carian gagal atau protokol tidak disokong, beralih (fallback) kepada A/AAAA, port lalai, dan protokol yang disokong, dengan TTL dan pemantauan mengawal pelancaran.

Huraian mendalam langkah demi langkah

1. Membezakan jenis rekod

SVCB ialah rekod service-binding generik; HTTPS ialah varian berorientasikan HTTP. Kedua-duanya membawa keutamaan, nama sasaran, dan parameter nilai-kunci. Ia tidak mencipta lapisan proksi; HTTP masih mengikut semantik RFC 9110.

2. Menerangkan AliasMode dan ServiceMode

AliasMode menggunakan keutamaan 0 untuk mengaliaskan nama semasa kepada nama sasaran, jadi klien mesti menanyakan sasaran tersebut. ServiceMode menggunakan keutamaan bukan sifar untuk menerangkan perkhidmatan. Klien mencuba keutamaan yang lebih rendah dahulu tetapi melangkau calon yang tidak disokong.

3. Membaca pembayang tanpa terlalu mempercayainya

alpn boleh mengiklankan h2 atau h3, port boleh mengiklankan port bukan lalai, dan pembayang alamat boleh mengurangkan carian tambahan. Pembayang boleh menjadi lapuk atau disekat, jadi klien masih menyelesaikan A/AAAA, melengkapkan QUIC/TLS, dan mengesahkan protokol yang dirundingkan.

4. Mereka bentuk fallback

Dalam belanjawan ralat (error budget), cuba perkhidmatan boleh guna dengan keutamaan terendah, kemudian cuba calon seterusnya selepas ralat sambungan atau masa tamat. Jika carian HTTPS gagal, gunakan A/AAAA tradisional dan port HTTPS lalai. Kunci yang tidak diketahui tidak boleh menjadi dasar pembenaran.

5. Mengurus caching dan perubahan

TTL mengawal tempoh recursive resolver dan klien mengekalkan pembayang. Sediakan hos atau port baharu sebelum melakukan perubahan TTL dan rekod secara beransur-ansur. Mengalih keluar rekod berwibawa (authoritative) tidak memadamkan jawapan yang dicache serta-merta; insiden mendesak memerlukan penyekatan bahagian pelayan atau kawalan sijil.

6. Menerangkan keselamatan DNS dan TLS

DNSSEC mengesahkan integriti rekod; DoH/DoT melindungi pengangkutan pertanyaan. Kedua-duanya tidak menggantikan pengesahan identiti TLS. RFC 9460 mengehadkan kepercayaan pada pembayang DNS kepada tidak lebih daripada isyarat HTTP 307 teks biasa. Klien masih mengesahkan sijil, SNI, ALPN, dan versi TLS, serta tidak boleh membenarkan sasaran silang asal (cross-origin) yang tidak dilindungi.

7. Mengesahkan dan membuat rollback

Uji klien lama, rantaian AliasMode, pelbagai keutamaan, kunci yang tidak diketahui, cache lapuk, kegagalan DNSSEC, h3 yang tidak tersedia, ketidakpadanan sijil, dan rangkaian IPv4/IPv6 sahaja. Pantau masa jabat tangan (handshake), kejayaan protokol, fallback, ralat, dan isyarat privasi. Buat rollback dengan memulihkan rekod lama dan menunggu TTL; gunakan penyekatan bahagian pelayan untuk kecemasan identiti.

Contoh jawapan berkualiti tinggi

Saya akan meletakkan rekod HTTPS sebagai pembayang penemuan perkhidmatan. AliasMode membuatkan klien menanyakan nama sasaran, manakala ServiceMode menyenaraikan calon mengikut keutamaan. alpn, port, dan pembayang alamat membantu pemilihan tetapi tidak memberikan akses. Jika h3 gagal, beralih (fallback) dalam belanjawan kepada h2 atau laluan A/AAAA tradisional, dan pastikan laluan lama tersedia apabila pertanyaan DNS gagal.

DNSSEC melindungi integriti rekod dan DoH/DoT melindungi pengangkutan pertanyaan, tetapi pemeriksaan sijil, SNI, ALPN, dan versi TLS kekal bebas. Gunakan pelancaran yang mengambil kira TTL dan pantau kejayaan protokol, fallback, ralat sijil, dan tingkah laku cache. Uji resolver lama, kunci yang tidak diketahui, AliasMode, kegagalan DNSSEC, dan rangkaian IPv6 sahaja. Untuk masalah identiti kecemasan, penyekatan bahagian pelayan dan kawalan sijil diperlukan; menunggu tamat tempoh cache DNS adalah tidak mencukupi.

Kesilapan lazim

• Menganggap HTTPS sebagai pengganti CNAME atau lencongan (redirect).
• Mengelirukan AliasMode, ServiceMode, dan keutamaan.
• Menganggap pembayang alamat sebagai berwibawa dan melangkau A/AAAA.
• Menganggap alpn=h3 memintas perundingan QUIC/TLS.
• Memanggil DNS biasa boleh dipercayai tanpa perlindungan integriti.
• Mengabaikan jawapan yang dicache selepas memadamkan rekod berwibawa.
• Menghala ke sasaran yang tidak dilindungi oleh sijil yang boleh disahkan.

Soalan susulan dan respons

Soalan susulan 1: Mengapakah AliasMode memerlukan carian lain?

Ia hanya menyatakan alias pada peringkat nama dan tidak membawa parameter perkhidmatan akhir, jadi klien mesti menanyakan sasaran untuk mendapatkan data ServiceMode.

Soalan susulan 2: Bolehkah rekod HTTPS memintas sijil untuk hos CDN?

Tidak. Klien masih mengesahkan sijil dan konfigurasi TLS untuk nama sambungan; CDN mesti mengemukakan sijil yang boleh disahkan.

Soalan susulan 3: Apakah perbezaan antara DNSSEC dan DoH/DoT?

DNSSEC mengesahkan punca dan integriti rekod. DoH/DoT melindungi privasi pengangkutan pertanyaan. Kedua-duanya bukan pengganti pengesahan identiti TLS.

Soalan susulan 4: Bagaimanakah anda membatalkan sasaran yang bocor?

Sekat sasaran tersebut atau batalkan sijilnya di bahagian pelayan terlebih dahulu, kemudian kemas kini rekod dan kurangkan TTL; jawapan yang dicache tidak akan hilang serta-merta.