Belajar DNS - Sejarah, Latar Belakang & Mengapa Membutuhkan DNS

#Pendahuluan

Sebelum membuka konfigurasi, penting untuk memahami mengapa DNS ada. DNS bukan fitur tambahan — dia adalah salah satu fondasi internet yang paling tidak terlihat sekaligus paling rentan dieksploitasi. Untuk mengoperasikan PowerDNS dengan benar, kalian harus tahu masalah apa yang dia pecahkan dan mengapa desainnya seperti sekarang.

Episode ini membedah sejarah name resolution dari era ARPANET sampai protokol modern, perjalanan PowerDNS sejak 1999, dan masalah-masalah arsitektural yang membuat database-driven DNS menjadi kebutuhan. Setelah episode ini, kalian akan melihat setiap record dan setiap daemon bukan sebagai hafalan, melainkan sebagai keputusan desain.

#Evolusi Name Resolution

#Era HOSTS.TXT

Di awal ARPANET, pemetaan nama host ke alamat IP dilakukan lewat satu file bernama HOSTS.TXT yang dikelola oleh SRI. Setiap kali ada host baru, admin mengirimkan perubahan, dan SRI memperbarui file lalu mendistribusikannya ke seluruh jaringan.

Masalahnya jelas: file ini tidak bisa diskalakan. Volume host tumbuh cepat, pertengkaran soal hak edit muncul, dan setiap pembaruan butuh waktu. Satu file terpusat adalah titik kegagalan tunggal, dan latensi pembaruan membuat nama sering salah. Solusi yang lebih terdesentralisasi harus lahir.

#Kelahiran DNS: RFC 882 dan 883

Pada 1983, Paul Mockapetris merancang DNS dan mempublikasikannya dalam RFC 882 dan RFC 883. Gagasan besarnya: pisahkan pemetaan nama ke struktur hierarkis yang terdistribusi, dan biarkan setiap organisasi mengelola bagian namanya sendiri — yang kita kenal sebagai zone. Lalu di 1987, RFC 1034 dan RFC 1035 menyempurnakan spesifikasi menjadi bentuk yang kita pakai hingga hari ini.

DNS pada dasarnya adalah database terdistribusi berbentuk pohon. Karena terdesentralisasi, tidak ada satu pihak yang harus memegang seluruh data, dan kegagalan satu node tidak melumpuhkan seluruh sistem.

#Mengapa Hierarki Menyelesaikan Masalah

Kunci desain Mockapetris ada di kata delegation. Setiap level pohon menunjuk otoritas level berikutnya: root menunjuk TLD, TLD menunjuk domain, dan seterusnya. Dengan cara ini, penambahan host baru cukup dilakukan di satu zone kecil, tanpa harus memberitahu seluruh internet.

Coba lihat sendiri bagaimana perjalanan itu bekerja ketika kalian memakai dig +trace. Perintah itu menelusuri dari root servers sampai jawaban akhir, menampilkan setiap titik delegation yang menghubungkan rantai. Kalian akan melihat betapa sedikit data yang harus dimuat satu organisasi — justru karena beban disebar ke banyak zone.

#Perkembangan Protokol: Dari EDNS0 sampai Encrypted DNS

DNS awal didesain untuk dunia yang jauh lebih sederhana. Seiring waktu, kebutuhan baru memunculkan standar-standar baru:

• EDNS0 (RFC 6891): memperbesar batas payload UDP agar jawaban bisa memuat DNSSEC dan record besar.
• DNSSEC (RFC 4033-4035): menambahkan tanda tangan kriptografi agar jawaban DNS bisa diverifikasi keasliannya.
• DoT (RFC 7858), DoH (RFC 8484), dan DoQ (RFC 9250): mengenkripsi seluruh pertukaran DNS agar query tidak bisa dibaca atau dimodifikasi pihak ketiga.

dig @127.0.0.1 example.com A +edns

Pola yang perlu kalian lihat: DNS terus diperbaiki dengan menambahkan lapisan di atasnya, bukan mengganti inti protokol yang sudah dipakai di mana-mana. Ini alasan mengapa kompatibilitas mundur selalu menjadi prioritas di stack PowerDNS.

#Tiga Era Utama Protokol

Perjalanan DNS bisa diringkas dalam tiga era:

• Era klasik (1983-1999): RFC 882/883 dan 1034/1035 membangun struktur dasar yang kita pakai — hierarki, delegation, dan resource records.
• Era ekstensi (1999-2010): EDNS0 membuka ruang payload, sementara DNSSEC menambahkan integritas kriptografi di atas data.
• Era privasi (2010-sekarang): DoT, DoH, dan DoQ lahir dari kebutuhan melindungi privasi query dari pengintaian dan manipulasi di jalur jaringan.

Ketiga era ini tidak saling menghapus. Server PowerDNS yang menjalankan DoH di port 443 tetap membaca paket DNS dengan format yang sama seperti tahun 1983 — hanya dibungkus lapisan yang lebih baru.

#Mengapa Standar Bertahan Lama

Ada pelajaran penting di sini: protokol yang dipakai miliaran perangkat tidak bisa diubah sembarangan. Karena itu perbaikan selalu datang sebagai standar tambahan yang bersifat opt-in. EDNS0 hanya aktif jika kedua sisi menyepakati OPT record, DNSSEC hanya berlaku untuk zone yang menandatangani, dan DoH hanya dipakai jika klien memilihnya. Pendekatan inilah yang membuat DNS tetap relevan setelah lebih dari empat dekade.

#Sejarah PowerDNS

#Lahir dari Kebutuhan Database-Driven

PowerDNS lahir pada 1999 dari tangan Bert Hubert dan Miek Gieben. Berbeda dengan BIND yang berbasis zone files, PowerDNS sejak awal mengusung arsitektur backend: data zone bisa disimpan di database relasional seperti MySQL, PostgreSQL, atau SQLite, dan diakses lewat API.

systemctl list-units --type=service | grep pdns

Dari sana PowerDNS berkembang menjadi trio: Authoritative Server (menjawab zone yang dimiliki), Recursor (menyelesaikan query untuk klien), dan dnsdist (launched 2015) yang berperan sebagai load balancer dan frontend keamanan. Ketiganya kini bisa dikonfigurasi berbasis YAML, memakai structured logging, dan mendukung OpenTelemetry — sebuah evolusi panjang sejak era pdns.conf polos.

#Mengapa Database-Driven Penting

Pendekatan backend memberi tiga keunggulan yang menentukan: API untuk otomasi penuh, autoprovisioning sehingga zone bisa dibuat oleh sistem lain tanpa SSH, dan integrasi dengan CMDB, DHCP, atau Kubernetes. Inilah alasan utama tim DevOps memilih PowerDNS dibanding alternatif klasik.

#Dari Authoritative sampai Trio Lengkap

Awalnya PowerDNS hanya berfokus pada sisi authoritative. Seiring waktu, kebutuhan ekosistem mendorong kelahiran dua saudaranya: Recursor yang andal untuk resolusi, lalu dnsdist pada 2015 sebagai lapisan depan. Ketiganya sekarang menjadi satu stack kohesif yang bisa dikonfigurasi dari satu set file dan diamati dengan alat yang sama — OpenTelemetry, Prometheus, dan structured logging.

systemctl list-units --type=service | grep pdns memperlihatkan betapa jauh ekosistem ini telah berkembang: mulai dari satu daemon bernama pdns, kini kalian bisa menjalankan pdns, pdns-recursor, dan dnsdist dalam satu host, masing-masing dengan peran dan konfigurasinya sendiri.

#Masalah yang Diselesaikan PowerDNS

#Centralized File Tidak Cukup

Zone files memang sederhana, tetapi sulit dipakai untuk ribuan zone atau perubahan yang sering. PowerDNS memindahkan kompleksitas ke database: serial dihitung otomatis, perubahan bisa via SQL, dan struktur modular backend memungkinkan pengganti tanpa mengganti engine.

#Arsitektur Modular: Backend + Engine

Konsep kuncinya adalah pemisahan backend (tempat data disimpan: bind, gsqlite3, gmysql, lmdb, geoip, remote) dan engine (logika penjawab query). Kalian bisa bertukar backend tanpa menulis ulang logika server.

query masuk -> backend lookup -> jawaban dikembalikan

Pemisahan ini juga membuat PowerDNS Authoritative bisa memakai remote backend untuk menyambung ke API sistem lain, atau geoip untuk jawaban berbasis lokasi. Kita akan membahas semua backend ini di episode 11.

#Penutup

Episode 1 menutup fondasi konseptual series ini: kalian sekarang tahu DNS lahir untuk menggantikan file HOSTS.TXT yang tidak scalable, distandarkan lewat RFC 882/883 dan disempurnakan oleh RFC 1034/1035, dan terus beradaptasi lewat EDNS0, DNSSEC, hingga encrypted DNS.

Inti yang harus dibawa pulang:

• DNS adalah database terdistribusi berbentuk pohon, bukan sekadar file pemetaan nama.
• HOSTS.TXT adalah contoh klasik titik kegagalan terpusat yang tidak bisa diskalakan.
• EDNS0, DNSSEC, DoT, DoH, dan DoQ adalah lapisan perbaikan di atas inti protokol yang stabil.
• PowerDNS lahir 1999 dengan ide database-driven DNS yang memungkinkan API dan autoprovisioning.
• Trio PowerDNS terdiri dari Authoritative, Recursor, dan dnsdist dengan peran yang saling melengkapi.

Di episode 2 selanjutnya kita akan membahas konsep dasar dan arsitektur utama — namespace hierarkis dari root sampai subdomain, anatomi pesan DNS dengan header dan flag-nya, peran authoritative versus recursor, serta katalog resource records yang akan menemani kita sepanjang series. Siapkan dig kalian, karena kita mulai membedah paket DNS di jaringan nyata!