Alur DNS dan TLS

Sebelum permintaan HTTP pertama dikirim, dua mekanisme jaringan bekerja lebih dahulu: DNS menerjemahkan nama domain menjadi alamat IP, dan TLS membangun kanal terenkripsi di atas koneksi TCP. Topik ini menelusuri rantai resolusi DNS dari cache browser sampai server otoritatif, menghitung biaya handshake TLS dengan angka yang dapat diperiksa ulang, dan mengulas dasar sertifikat. Biaya kedua alur ini menjadi dasar keputusan desain seperti nilai TTL, penempatan load balancer, dan penggunaan CDN.

Rantai resolusi DNS#

DNS (Domain Name System) menerjemahkan nama domain seperti catatan.example menjadi alamat IP yang dapat dituju oleh koneksi. Pencarian dimulai dari cache pada browser atau sistem operasi, lalu diteruskan ke resolver rekursif (recursive resolver) yang bertugas mengejar jawabannya. Resolver rekursif menanyakan server root, yang mengarah ke server TLD (top-level domain) untuk akhiran .example, dan server TLD mengarah ke server otoritatif yang menyimpan rekaman domain tersebut. Alamat IP akhirnya kembali menyusuri rantai yang sama dan disimpan di cache pada tiap lapisan yang dilalui.

Diagram berikut memperlihatkan rantai itu dari kiri ke kanan, dengan angka 1 sampai 4 menandai urutan kueri dan jalur putus-putus sebagai perjalanan balik jawabannya.

Setiap rekaman jawaban membawa TTL (time to live), yaitu berapa lama rekaman itu boleh disimpan oleh cache. Permintaan berikutnya selama TTL masih hidup dilayani oleh cache tanpa menyusuri rantai lagi, sehingga biaya rekursi penuh $k \times \text{RTT}$ dengan $k$ jumlah hop, yaitu lapisan yang harus ditanya, hanya dibayar ketika cache masih dingin. Pemilik domain mengendalikan TTL per rekaman, dan nilai itulah tuas utama antara beban resolver dan kecepatan perubahan alamat.

Rekaman DNS yang sering dipakai#

Zona DNS menyimpan beberapa jenis rekaman, dan lima jenis berikut muncul pada hampir setiap desain web. Rekaman A dan AAAA menjadi tujuan akhir resolusi, sedangkan CNAME dan NS mengatur ke mana sebuah nama menunjuk dan siapa yang berhak menjawabnya.

Pemilihan rekaman ikut menentukan cara trafik berpindah ketika infrastruktur berubah. Memperbarui alamat IP pada rekaman A memindahkan pengguna bertahap sesuai kedaluwarsa cache, sedangkan CNAME memindahkan seluruh subdomain sekaligus ke tujuan barunya. Rekaman TXT juga kerap menjadi tempat kebijakan pengirim surel seperti SPF, sehingga perubahannya sering menyertai integrasi layanan baru. Cache menyimpan jawaban apa adanya, sehingga perubahan DNS tidak pernah instan dan jeda terburuknya sebesar TTL terpanjang yang pernah disajikan kepada resolver.

Menghitung biaya resolusi dan handshake#

Biaya total untuk pengunjung baru adalah penjumlahan empat tahap, yaitu rekursi DNS, handshake TCP, handshake TLS, lalu permintaan dan respons HTTP. Handshake TCP tiga arah, serangkaian pesan pembuka koneksi, membayar satu RTT (round-trip time), sedangkan TLS 1.2 menambah dua RTT karena membutuhkan dua putaran pesan sebelum data aplikasi boleh dikirim. TLS 1.3 memangkasnya menjadi satu RTT, dan koneksi yang pernah dibuat dapat dilanjutkan melalui session resumption dengan 0-RTT, yaitu data aplikasi yang ikut pada putaran pertama handshake, sehingga biaya TLS tambahannya nol. Skrip berikut merangkai angka-angka itu menjadi estimasi waktu sampai byte pertama.

# Estimasi waktu sampai byte pertama pada satu permintaan HTTPS.
# Semua angka adalah asumsi yang mudah diganti: RTT jaringan seragam dan
# biaya tiap tahap dinyatakan dalam jumlah pulang-pergi plus waktu proses.

RTT = 40       # ms, waktu tempuh satu pulang-pergi
HOP_DNS = 4    # resolver rekursif, root, TLD, otoritatif (tanpa cache)
PROSES = 30    # ms, waktu server memproses permintaan HTTP

dns_baru = HOP_DNS * RTT   # rekursi penuh karena seluruh cache kosong
dns_cache = 0              # rekaman masih hidup di cache resolver
tcp = RTT                  # handshake TCP tiga arah
tls_12 = 2 * RTT           # TLS 1.2: dua pulang-pergi sebelum data aplikasi
tls_13 = RTT               # TLS 1.3: satu pulang-pergi
tls_resume = 0             # resumption TLS 1.3: data ikut handshake pertama
http = RTT + PROSES        # kirim permintaan, proses, terima respons

baris = [
    ("Pengunjung baru, DNS tanpa cache, TLS 1.2", dns_baru + tcp + tls_12 + http),
    ("Pengunjung baru, DNS tanpa cache, TLS 1.3", dns_baru + tcp + tls_13 + http),
    ("Pengunjung kembali, DNS ter-cache, resumption", dns_cache + tcp + tls_resume + http),
]
lebar = max(len(nama) for nama, _ in baris)
for nama, total in baris:
    print(f"{nama:<{lebar}} : {total} ms")

Pengunjung baru, DNS tanpa cache, TLS 1.2     : 350 ms
Pengunjung baru, DNS tanpa cache, TLS 1.3     : 310 ms
Pengunjung kembali, DNS ter-cache, resumption : 110 ms

Selisih 240 ms antara pengunjung baru dengan TLS 1.2 dan pengunjung kembali yang memakai cache penuh memperlihatkan seberapa besar biaya yang dapat dihemat tanpa menyentuh kode aplikasi. Migrasi ke TLS 1.3 saja memangkas 40 ms bagi setiap pengunjung baru, dan penghematan itu berlipat pada pengguna jaringan RTT tinggi seperti seluler. Angka-angka ini juga menjelaskan arah optimasi yang lazim, yaitu menempatkan titik kehadiran server di dekat pengguna agar setiap RTT yang dibayar menjadi lebih kecil.

Sertifikat dan rantai kepercayaan#

Handshake TLS tidak hanya menegosiasikan kunci enkripsi, tetapi juga membuktikan identitas server melalui sertifikat digital. Sertifikat memuat nama domain, masa berlaku, dan tanda tangan dari otoritas sertifikat (certificate authority, CA). Browser memercayai sertifikat karena rantainya dapat dilacak sampai CA root yang terdaftar pada penyimpanan kepercayaan (trust store) perangkat, sehingga CA perantara menjadi mata rantai antara sertifikat server dan akarnya.

Penerbitan dan pembaruan sertifikat diotomatisasi melalui protokol ACME (Automated Certificate Management Environment), yang dipakai antara lain oleh otoritas sertifikat nirlaba Let’s Encrypt. Masa berlaku sertifikat sengaja dibuat pendek untuk membatasi jendela kerusakan ketika kunci bocor, sehingga proses pembaruan harus berjalan andal tanpa campur tangan manusia.

Satu alamat IP dapat melayani banyak domain karena browser menyertakan nama domain yang dituju pada ekstensi SNI (Server Name Indication) saat handshake, sehingga server dapat menyodorkan sertifikat yang tepat. Karena versi awal SNI dikirim tanpa enkripsi, enkripsi SNI (Encrypted Client Hello) diperkenalkan untuk menutup celahnya. Bagi desain, mekanisme ini memungkinkan TLS termination, yaitu pembongkaran enkripsi pada load balancer atau proxy, tanpa menyerahkan sertifikat ke setiap server aplikasi.

Implikasi bagi desain sistem#

Alur DNS dan TLS menjelaskan mengapa banyak keputusan arsitektur mengikuti bentuk jaringan. CDN melayani konten dari titik kehadiran yang RTT-nya kecil, sehingga biaya handshake yang sama menjadi lebih murah karena tiap pulang-perginya lebih pendek. Session resumption dan koneksi persisten mengamortisasi biaya handshake pada banyak permintaan, sehingga angka kinerja yang diukur setelah koneksi hangat menyembunyikan biaya yang sebenarnya tetap dibayar oleh setiap pengunjung baru.

TTL DNS menjadi tuas failover, yaitu perpindahan layanan ke cadangan ketika wilayah utama gagal. Saat perpindahan dilakukan, alamat pada rekaman DNS diarahkan ke wilayah lain, dan kecepatannya dibatasi oleh cache yang masih menyimpan jawaban lama. Nilai TTL yang disetel sejak desain menentukan seberapa cepat perpindahan itu, sehingga kebutuhan failover cepat menuntut TTL pendek dengan beban resolver yang lebih tinggi sebagai harganya.

Kesalahan umum#

Tiga kesalahan berikut paling sering muncul ketika alur DNS dan TLS dikelola di production.

• Menurunkan TTL pada saat failover sudah terjadi. Cache menghormati nilai TTL lama sampai rekamannya kedaluwarsa, sehingga perubahan baru terlihat setelah TTL lama berlalu. Turunkan TTL jauh sebelum jadwal perpindahan.
• Mengukur waktu resolusi dari mesin yang berbagi resolver dengan server uji. Angka yang diperoleh tidak mewakili pengguna nyata yang menumpang resolver publik dengan cache dan RTT yang berbeda.
• Menyetel kinerja hanya dari koneksi yang sudah hangat. Pengunjung baru tetap membayar rekursi DNS, handshake TCP, dan handshake TLS, sehingga angka hangat menyesatkan bila dipakai sebagai estimasi latensi ujung ke ujung.

Ringkasan#

• Resolusi DNS menyusuri rantai root, TLD, dan server otoritatif, sedangkan cache dan TTL pada tiap lapisan menentukan seberapa sering rantai itu dibayar ulang.
• TTL adalah tuas failover, yaitu makin pendek nilainya, makin cepat perubahan alamat terlihat, dengan beban resolver yang lebih tinggi sebagai harganya.
• Handshake TCP menambah satu RTT, TLS 1.2 menambah dua RTT, TLS 1.3 menambah satu RTT, dan session resumption menghilangkan biaya TLS bagi pengunjung kembali.
• Sertifikat membangun kepercayaan melalui rantai CA, dan pembaruannya wajib otomatis agar kedaluwarsa tidak menjadi titik kegagalan tunggal.

Referensi#

• Domain Names — Concepts and Facilities (RFC 1034) — IETF — Konsep hierarki domain, delegasi, dan peran resolver.
• Domain Names — Implementation and Specification (RFC 1035) — IETF — Spesifikasi jenis rekaman, TTL, dan format pesan DNS.
• The Transport Layer Security (TLS) Protocol Version 1.3 (RFC 8446) — IETF — Spesifikasi handshake TLS 1.3 dan mekanisme resumption.