Resolusi DNS, dari Awal hingga Akhir

Setiap kali Anda mengetik domain ke browser, serangkaian lookup dimulai sebelum satu paket pun mencapai situs yang Anda inginkan. Sebagian besar dari rantai itu tidak terlihat, dan sebagian besar penjelasan berhenti di "ini seperti buku telepon." Berikut apa yang benar-benar terjadi, langkah demi langkah, termasuk bagian yang biasanya orang lewatkan.

Stub resolver tidak cerdas

Sistem operasi Anda tidak melakukan resolusi DNS asli sendiri. Ia menjalankan stub resolver, sepotong kode tipis yang hanya meneruskan query Anda ke server DNS apa pun yang dikonfigurasi di /etc/resolv.conf di Linux atau di pengaturan adaptor jaringan Anda di Windows. Periksa milik Anda dengan:

cat /etc/resolv.conf

File itu biasanya menunjuk ke router Anda (seperti 192.168.1.1), resolver ISP Anda, atau yang publik seperti 1.1.1.1 atau 8.8.8.8. Stub resolver tidak memiliki logika cache sendiri selain dari yang diberikan OS atau daemon lokal seperti systemd-resolved.

Recursive resolver melakukan pekerjaan sebenarnya

Setelah query Anda sampai ke recursive resolver, server itu mengambil alih pekerjaan menemukan jawaban, bahkan jika harus bertanya ke beberapa server lain untuk sampai ke sana. Jika jawaban sudah di-cache dari lookup sebelumnya, Anda mendapatkannya kembali segera. Periksa TTL dengan:

dig example.com

Lihat ANSWER SECTION — angka sebelum tipe record (seperti 300 sebelum A) adalah TTL dalam detik. Itulah berapa lama resolver diizinkan untuk men-cache record sebelum bertanya lagi.

Jika tidak ada yang di-cache, recursive resolver memulai perjalanan turun hirarki DNS dari root.

Root, TLD, dan authoritative servers

Ada 13 alamat root server (a.root-servers.net hingga m.root-servers.net), masing-masing didukung oleh banyak mesin fisik melalui anycast routing. Root server tidak tahu di mana example.com berada, tetapi tahu server mana yang menangani .com, jadi ia mengembalikan referral.

Resolver kemudian bertanya ke .com TLD server, yang sekali lagi tidak tahu jawaban akhir tetapi tahu nameserver mana yang authoritative untuk example.com secara spesifik. Anda dapat melihat delegasi ini sendiri:

dig +trace example.com

Perintah itu menunjukkan setiap hop: root, kemudian TLD, kemudian nameserver authoritative untuk domain, diakhiri dengan record A atau AAAA sebenarnya. Ini adalah perintah terbaik untuk memahami DNS secara visual daripada teoritis.

Authoritative nameserver adalah pemberhentian terakhir. Ini adalah server yang benar-benar dikonfigurasi oleh pemilik domain, sering kali melalui panel DNS registrar atau layanan seperti Route 53 atau Cloudflare DNS. Ini adalah satu-satunya server dalam seluruh rantai yang memiliki jawaban asli dan kanonik daripada salinan cache atau referral.

Tipe record yang benar-benar akan Anda temui

Record A memetakan nama ke alamat IPv4, AAAA melakukan hal yang sama untuk IPv6. CNAME menunjuk satu nama ke nama lain daripada IP, yang merupakan cara CDN seperti Cloudflare atau Fastly merutekan traffic tanpa mengekspos IP mentah. Record MX menangani routing mail, dan record TXT membawa teks arbitrer, paling umum digunakan sekarang untuk SPF, DKIM, dan string verifikasi domain. Record NS memberitahu dunia server mana yang authoritative untuk zona, dan itulah tipe record yang membuat delegasi mungkin sejak awal.

Di mana caching sebenarnya tinggal

Caching terjadi di beberapa layer secara bersamaan: browser itu sendiri (Chrome memiliki DNS cache sendiri yang dapat dilihat di chrome://net-internals/#dns), cache resolver OS, router lokal, dan recursive resolver upstream. Itulah mengapa perubahan DNS dapat muncul langsung bekerja di satu perangkat dan membutuhkan waktu berjam-jam untuk muncul di perangkat lain — Anda tidak mengenai cache yang sama.

Ketika Anda menurunkan TTL record sebelum migrasi yang direncanakan, Anda tidak mempercepat apa pun segera. Anda hanya memperkecil jendela selama data usang dapat bertahan setelah perubahan benar-benar terjadi. Lakukan ini setidaknya satu siklus TTL sebelumnya, bukan lima menit sebelum cutover.

Mengapa ini penting untuk troubleshooting

Ketika situs tidak dapat dijangkau, dig +trace memberitahu Anda persis layer mana yang rusak: masalah root/TLD terlihat sangat berbeda dari server authoritative yang salah konfigurasi atau cache usang di mesin Anda sendiri. Membandingkan dig example.com dengan resolver yang diketahui baik, seperti dig example.com @1.1.1.1, mengisolasi apakah masalah ada di resolver lokal Anda atau setup DNS domain sebenarnya.

DNS terlihat sederhana dari luar karena biasanya teratasi dalam waktu kurang dari 100ms dan tidak ada yang memikirkannya. Di dalamnya, ini adalah sistem query yang terdistribusi, di-cache, dan hierarkis yang telah berjalan sebagian besar tidak berubah dalam struktur sejak tahun 1980an, yang merupakan argumen yang cukup baik untuk betapa baiknya desain asli itu bertahan.

Jika Anda ingin melanjutkan lebih jauh dengan ini, Korra Studio memiliki segmen terkait di DEFENSE_GRID yang mencakup DNS security extensions, DNS tunneling sebagai teknik exfiltration, dan membangun resolver Anda sendiri dari awal di Python.