Mengapa mempelajari DNS masih sulit?

• DNS telah digunakan selama lebih dari 35 tahun sejak era 1980-an dan strukturnya juga stabil, tetapi banyak programmer tetap butuh waktu lama hingga bisa men-debug masalah dasar dengan percaya diri
• Kesulitannya bukan hanya pada kompleksitas DNS itu sendiri, melainkan karena ada banyak komponen yang tidak terlihat seperti cache resolver, library DNS lokal, dan percakapan dengan authoritative nameserver
• dig memang kuat, tetapi struktur output dan istilahnya terasa asing, dan fitur seperti +norecurse tetap tidak intuitif untuk ditafsirkan hasilnya
• Jebakan umum seperti negative caching, riwayat tidak didukungnya TCP DNS di musl, resolver yang mengabaikan TTL, caching permanen oleh nginx, dan ndots di Kubernetes sulit dipelajari sebelum ada yang memberi tahu
• Bagi orang yang jarang berurusan dengan DNS, cheat sheet bisa membantu, dan masalah yang terasa berat untuk diuji bisa diringankan dengan lingkungan eksperimen aman seperti Mess With DNS

---

DNS tetap sulit meski teknologinya sudah tua

• DNS telah digunakan selama lebih dari 35 tahun sejak masa RFC 1034, dipakai di semua situs web di internet, dan dalam banyak hal masih bekerja mirip seperti 30 tahun lalu
• Meski begitu, perlu waktu lama untuk men-debug masalah dasar seperti “domain sudah dikonfigurasi dengan benar tetapi tidak ter-resolve” atau “hasil DNS dari dig berbeda dengan browser”
• Orang yang kesulitan dengan DNS biasanya tersandung di titik-titik berikut
  • Bahkan perubahan DNS sederhana untuk situs web pun tidak terasa nyaman dilakukan
  • Bingung dengan fakta bahwa record DNS tidak di-push melainkan ditarik (pull)
  • Meski memahami konsep dasarnya, tetap bingung pada detail perilaku seperti negative caching atau perbedaan kueri DNS antara dig dan browser

Resolver dan nameserver yang tidak terlihat

• Alur dasar saat mengirim permintaan DNS dari komputer tampak sederhana
  • Komputer mengirim permintaan ke server yang disebut resolver
  • Resolver memeriksa cache, lalu jika perlu meminta lagi ke authoritative nameserver
• Banyak elemen yang penting saat debugging justru tidak terlihat secara bawaan
  • Sulit mengetahui apa yang ada di dalam cache milik resolver
  • Tidak selalu jelas library DNS mana yang menangani permintaan di lokal
    • Bisa berupa libc getaddrinfo, glibc, musl, implementasi Apple, kode DNS milik browser sendiri, atau implementasi kustom terpisah
    • Masing-masing implementasi sedikit berbeda dalam konfigurasi, cara caching, dan dukungan fitur
    • DNS di musl tidak mendukung TCP hingga awal 2023
  • Percakapan antara resolver dan authoritative nameserver tidak terlihat
    • Jika bisa melacak authoritative nameserver mana yang ditanyai dan bagaimana responsnya, banyak masalah DNS akan lebih mudah dipahami

Pendekatan untuk menampakkan sistem yang tersembunyi

• Hanya dengan memberi tahu komponen tersembunyi apa saja yang ada sudah sangat membantu proses belajar
  • Jika tidak tahu bahwa dalam satu komputer pun bisa ada beberapa library DNS yang digunakan tergantung situasi, orang bisa lama kebingungan
• Mess With DNS mencoba eksperimen bergaya fishbowl yang memperlihatkan bagian yang biasanya tidak terlihat
  • Tool ini memungkinkan kita melihat sebagian percakapan antara resolver dan authoritative nameserver
• Ada juga pendekatan memasukkan informasi debugging ke dalam respons DNS
  • Fitur seperti Extended DNS Errors atau EDE sudah ada
  • Tool-tool perlahan mulai menambahkan dukungan EDE

Petunjuk yang diberikan Extended DNS Errors

• Extended DNS Errors adalah cara baru agar server DNS dapat memberikan informasi debugging tambahan di dalam respons
• Jika domain yang tidak ada xjwudh.com dikueri dengan dig @8.8.8.8 xjwudh.com, bisa muncul kesalahan tambahan berikut

; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)

• Contoh ini tampak berkaitan dengan DNSSEC, dan yang penting adalah bahwa pesan debug tambahan ikut dimasukkan ke dalam respons
• Untuk melihat contoh di atas, diperlukan versi dig yang lebih baru

dig kuat, tetapi sulit dibaca

• dig berguna untuk memeriksa status internal DNS
• Dengan dig +norecurse, kita bisa melihat record apa yang dimiliki cache milik resolver DNS tertentu
  • 8.8.8.8 tampaknya mengembalikan SERVFAIL jika jawaban tidak ada di cache
  • google.com ada di cache sehingga mengembalikan NOERROR dan record A
  • homestarrunner.com tidak ada di cache sehingga mengembalikan SERVFAIL, tetapi ini bukan berarti record DNS-nya tidak ada
• Output dig sulit dibaca jika belum terbiasa
  • Judul seperti ->>HEADER<<-, flags:, OPT PSEUDOSECTION:, QUESTION SECTION:, ANSWER SECTION: terasa asing
  • Pemisah baris dan spasi antarbagian terasa tidak konsisten
  • Dari MSG SIZE rcvd: 47, sulit mengetahui apakah ada field lain selain rcvd
  • Kita harus tahu bahwa saat tertulis ada 1 record di bagian ADDITIONAL, peran itu sebenarnya diisi oleh OPT PSEUDOSECTION
• Output dig terlihat bukan seperti format yang sejak awal dirancang dengan sengaja, melainkan seperti skrip yang tumbuh organik seiring waktu

Cara membuat tool DNS lebih mudah dibaca

• Dokumentasi yang menjelaskan output dig itu sendiri akan membantu
  • how to use dig menjelaskan struktur output dig dan cara mengatur output dasar yang lebih ringkas
• Bisa juga membuat tool yang lebih ramah
  • Ada alternatif seperti dog, doggo, DNS lookup tool
  • Namun saat membutuhkan fitur lanjutan seperti +norecurse, mungkin lebih baik tetap memakai dig saja
  • Menggantikan cakupan fitur dig yang sangat luas adalah pekerjaan besar
• Bisa juga menambahkan opsi seperti +human pada output dig agar informasi yang sama tampil lebih terstruktur
  • Header, kueri, jawaban, bagian tambahan, waktu, server, protokol, dan ukuran respons bisa dipisahkan dengan jelas
  • Pendekatannya bukan mengurangi informasi, melainkan menyajikan informasi yang sama agar lebih mudah dibaca
• dig versi terbaru punya format output +yaml
  • Ini bisa terasa lebih jelas, tetapi untuk respons DNS sederhana pun bisa terlalu panjang sampai tidak muat di layar

Jebakan DNS yang sering ditemui tetapi sulit dipelajari

• Dalam DNS ada jebakan yang relatif sering muncul, tetapi sulit diketahui sebelum ada yang memberi tahu

• negative caching

  • Jika mengunjungi domain yang record DNS-nya belum ada, status “tidak ada” untuk record itu bisa ikut tercache
  • Jika status ini tercache selama beberapa jam, dampaknya bisa sangat merepotkan

• Perbedaan implementasi getaddrinfo

  • musl tidak mendukung TCP DNS hingga awal 2023

• Resolver yang mengabaikan TTL

  • Meski TTL record DNS diset 5 menit, beberapa resolver bisa mengabaikannya dan menyimpan cache jauh lebih lama, misalnya 24 jam

• Masalah konfigurasi nginx

  • Jika nginx dikonfigurasi dengan buruk, ia bisa menyimpan cache record DNS selamanya

• Kubernetes ndots

  • ndots dapat membuat DNS Kubernetes menjadi lambat

Cara berbagi dan mendokumentasikan jebakan

• Pengetahuan tentang jebakan aneh sulit didapat, dan tidak efisien jika orang harus terus menemukan kembali masalah yang sama
• Saat menjelaskan suatu topik, sangat membantu jika jebakan umum ikut dibahas
  • Sebagai contoh di luar DNS, pengantar Flexbox dari Josh Comeau menjelaskan minimum size gotcha
• Cara komunitas mengumpulkan jebakan umum juga berguna
  • Di Bash, shellcheck sangat berguna sebagai kumpulan jebakan bash
• Mendokumentasikan jebakan DNS juga sulit karena masalah yang ditemui tiap pengguna bisa berbeda
  • Orang yang mengatur DNS domain pribadi sekali tiap 3 tahun dan orang yang mengelola DNS domain dengan trafik tinggi akan menghadapi jebakan yang berbeda

Penggunaan yang jarang dan sulitnya bereksperimen

• Banyak orang sangat jarang berurusan dengan DNS
  • Jika hanya menyentuh DNS sekali tiap 3 tahun, wajar jika sulit dipelajari
  • Cheat sheet seperti “prosedur mengganti nameserver” bisa membantu
• DNS juga menakutkan untuk diuji coba karena ada beban bahwa kita bisa merusak domain sendiri
  • Mess With DNS dibuat untuk mengurangi beban eksperimen semacam ini

[GN⁺]

Opini Hacker News

• Saya tidak setuju dengan tulisan ini. DNS hanya jarang dipelajari orang dengan meluangkan waktu; menurut saya sebenarnya tidak sulit dipelajari
  Hal bagus dari DNS adalah sistemnya memberi tahu keadaan internalnya sendiri saat ada kueri. Mudah untuk memeriksa server DNS pada zona yang diketahui dan memahami cara kerjanya, dan alat gratis seperti dig juga tersedia luas
  Sepanjang karier, saya selalu heran bahwa orang-orang yang pernah bekerja bersama saya paling mengingat pengetahuan DNS saya, karena saya tidak merasa tahu sesuatu yang misterius atau istimewa. DNS sangat terstandarisasi, implementasi server dan klien yang umum juga mengikuti standar dengan ketat, dan mudah diamati dengan alat gratis. Memang butuh usaha dan waktu, tetapi sebenarnya tidak sulit

  • Sebagai penulis artikel itu, saya ingin mengatakan beberapa hal tentang pandangan bahwa DNS sebenarnya tidak sulit. Butuh bertahun-tahun sampai saya benar-benar nyaman men-debug masalah DNS, dan saya menulis artikel itu untuk menjelaskan mengapa hal itu sulit bagi saya
    Dulu saya mengira “Tidak, sebenarnya mudah kok!” adalah dorongan semangat untuk pernyataan “sulit dipelajari”. Saya menyukai DNS, dan dalam banyak hal menurut saya DNS sangat sederhana sampai mengejutkan. Misalnya, di https://implement-dns.wizardzines.com ditunjukkan cara mengimplementasikan resolver DNS mainan dari awal dengan kode Python sederhana
    Namun seiring waktu saya belajar bahwa “Tidak, ini mudah dipelajari!” sering diterima bukan sebagai dorongan “Kamu bisa!”, melainkan seperti “Ini bukan sulit, kamu saja yang bodoh”. Ketika ada topik yang membuat bingung selama bertahun-tahun, mendengar “sebenarnya itu mudah kok?” tidak terlalu membantu
    Jadi sekarang saya tidak lagi berkata begitu, dan saya berusaha keras memahami mengapa orang merasa hal tertentu sulit serta mengurangi hambatan itu
  • Dilihat dari alat untuk mempelajari DNS, menurut saya DNS sulit dipelajari
    BIND menjalankan perannya dengan sangat baik, tetapi berkas konfigurasinya kurang bagus, manualnya panjang dan kaku, dan kadang rumit tanpa perlu. dig memang kuat, tetapi menyingkat semuanya seperti pada era terminal 80 kolom. Saat men-debug masalah DNS, ada kalanya Wireshark menjadi alat yang lebih baik daripada dig
    Jika orang memakai PowerDNS atau server DNS modern lain, rasanya mereka bisa menyiapkan server DNS yang berfungsi dengan jauh lebih mudah. Saya tidak terlalu tahu klien DNS modern yang bagus, jadi akhirnya terbiasa dengan dig. Sebagai pengguna flag --color pada perintah ip, saya berharap alat seperti dig juga memberi keluaran yang lebih modern. Flag baris perintah akan saya bungkus dalam alias, jadi saya hanya ingin fiturnya ditambahkan
    Serius, MSG SIZE rcvd: 71 tidak perlu disingkat. flags: qr rd ra juga bisa ditulis lengkap. Saya juga tidak tahu apa yang ingin disampaikan titik koma di awal baris, dan itu malah membingungkan
    Tidak aneh jika orang bingung saat belajar DNS dari materi yang tersedia
  • Anda bilang “Saya tidak setuju dengan tulisan ini”, tetapi tampaknya hampir tidak menjawab poin tulisan itu dan hanya menolak judulnya. Selain itu, sepertinya Anda mencampuradukkan DNS itu sulit dengan DNS sulit dipelajari
    Kalau “hanya butuh sedikit usaha dan waktu”, seberapa banyak usaha dan waktu yang dibutuhkan? Beberapa orang di thread ini mengatakan mereka belajar dengan mengimplementasikan server, mengatakan butuh beberapa bulan untuk paham, lalu mengulang bahwa “setelah paham, ini cukup mudah”. Kalau begitu, bukankah kita bisa sepakat bahwa untuk sesuatu yang begitu umum dan secara konsep sederhana, DNS memang sulit dipelajari dalam praktiknya
  • Kalau membaca artikelnya, dijelaskan mengapa ini sulit dipelajari. Konsepnya mudah, tetapi saat mengajarkan konsepnya, semua detail internet modern tidak ikut dimasukkan
    Misalnya, apa aturan browser dalam menyimpan cache dan menghapus entri DNS saat kedaluwarsa? Apakah aturan itu konsisten antar-browser?
  • Menurut saya DNS adalah salah satu teknologi yang bisa dilewati sepanjang karier hanya dengan memungut potongan-potongan pengetahuan di sana-sini. Jika banyak orang harus menghadapinya secara langsung, mungkin DNS akan terasa kurang rumit daripada kenyataannya, tetapi di industri hal-hal seperti ini mendapatkan semacam aura misterius

• Menurut saya tulisan ini tepat mengenai inti masalah. DNS itu sendiri tidak sulit, tetapi mempelajari DNS di dunia nyata itu sulit. Sebab, banyak bagian di tengah antara melakukan lookup dan mendapatkan hasil yang diniatkan serta diharapkan tersembunyi
  Dulu model koneksi internet dasar adalah satu antarmuka, satu gateway, dan satu penyedia server DNS. Sekarang perangkat bisa terhubung ke beberapa WAN sekaligus seperti LTE dan WiFi, dan pengguna sulit mengetahui jalur resolusi apa yang sebenarnya dipakai. Tidak jelas apakah itu browser, antarmuka standar dari pustaka C sistem, resolver lokal atau resolver rekursif di tengah, apakah ada cache lokal, sampai apakah opsi khusus ditambahkan secara default
  Bahkan jika semuanya berfungsi, Anda tidak bisa begitu saja percaya bahwa kueri dan respons satu aplikasi memakai jalur yang sama dengan aplikasi lain. Tiga browser masing-masing memakai cara berbeda, sistem operasi juga berperilaku lain lagi, dan mDNS bisa menambahkan pilihan kelima

• Ada lelucon bahwa dalam ilmu komputer hanya ada tiga masalah sulit: invalidasi cache dan penamaan
  Dan DNS adalah sistem caching untuk nama benda
  https://reddit.com/comments/15c2ul2/comment/jtty9dy

  • Agar adil, DNS adalah salah satu contoh penamaan yang dilakukan dengan benar
    Dikelola secara global (IANA), hierarkis, federatif, dan mudah diubah

• DNS adalah jenis teknologi yang memiliki ketidaksesuaian antara seberapa mudah ia terlihat dan tingkat kesulitan yang sebenarnya muncul
  Kita memakai DNS setiap hari, dan kelihatannya sangat mudah. Bahasa DNS sehari-hari adalah nama domain, lookup, dan alamat IP. Bahasa ini terekspos apa adanya di browser, dan dari paparan itu kita membangun model mental tentang cara kerjanya
  Namun di dalamnya ada bahasa yang sama sekali berbeda: zone, resolver, delegated authority, dan titik aneh di belakang top-level domain

  • Titik aneh itu disebut root. Tanpa titik, sebuah nama belum lengkap; dengan titik, nama itu terdefinisi sepenuhnya. Dengan kata lain, konteks adalah segalanya. Tanpa titik, resolver bisa berulang kali menambahkan domainnya sendiri atau sebagian darinya
    Misalnya kita berdua tahu apa arti host.example.co.uk, tetapi tanpa titik di belakang, resolver bisa mencoba melakukan lookup ke host.example.co.uk.example.co.uk
    Dalam konfigurasi default Windows, pada kasus seperti ini ia bisa mencoba host.example.co.uk.example.co, host.example.co.uk.example, lalu host.example.co.uk.example lagi, dan host.example.co.uk., sampai mendapatkan hasil. Meski begitu, saya belum pernah melihat Windows benar-benar melakukan percobaan pertama itu, dan perilaku ini tampaknya dirancang agar DNS bisa menangani lingkungan perusahaan besar yang punya Active Directory federatif seperti monster
    Browser masa kini besar kemungkinan diam-diam menuju server DNS over HTTPS(DoH) tanpa persetujuan pengguna dan bergaul dengan segala macam pihak mencurigakan. Lookup DNS adalah data mendasar, jadi ISP memang suka melihat pengguna pergi ke mana. Vendor sistem operasi tentu saja juga bisa mengirim “telemetri”. Google tidak memiliki desktop, tetapi memiliki browser; jadi bagi mereka menguntungkan jika pengguna dibuat memakai server DNS “aman” alih-alih DNS yang sudah dikonfigurasi pengguna. Karena trik-trik seperti ini, pemecahan masalah IT menjadi jauh lebih seru dibanding dulu
    Titik di belakang tidak perlu terlalu dikhawatirkan. Toh kemungkinan besar Anda hampir pasti tidak sedang memakai server DNS yang Anda kira. Saya mengerti mengapa DoH dibuat, dan sebagian pengguna umum memang punya alasan untuk memakainya. Misalnya, ketika seseorang yang bukan profesional IT memakai hotspot WiFi berbahaya, browser yang pulang dengan aman ke markas untuk melakukan lookup DNS memberi perlindungan sampai batas tertentu. Namun apakah vendor browser boleh menginjak-injak pilihan keamanan endpoint pengguna adalah persoalan lain
    DNS jauh lebih rumit daripada sekadar mencari alamat. Sekarang ini soal uang, dan sebetulnya sudah begitu sejak sekitar tahun 2000. Kini ada banyak perusahaan raksasa yang sangat keras kepala dan ingin menentukan siapa yang mendapat keuntungan lewat pengguna
  • Menurut saya yang sulit adalah bagian terdistribusi. Di atas level atomik tiap node, ada banyak ilmu hitam yang luar biasa, dan itulah yang menciptakan sebagian besar kompleksitas serta sebagian besar ketidaktransparanan
    DNS itu sendiri mudah. Distribusi informasi yang tidak bergantung pada organisasi benar-benar rumit

• Beberapa tahun lalu saya menyadari bahwa pemahaman saya tentang DNS hanya berupa potongan-potongan. Saya tahu dig(1), BIND, dan konsep setingkat CS101 tentang cara kerja resolusi DNS rekursif, tetapi kurang memiliki pengetahuan praktis yang diperlukan untuk merancang dan mengimplementasikan sistem yang tidak sepele, atau men-debug sistem yang tidak berjalan
  Jadi saya membaca “DNS and BIND” hampir dari awal sampai akhir, dan juga menyiapkan server BIND sungguhan untuk beberapa situs web pribadi yang tidak terlalu penting. Itu tidak sulit, tetapi butuh investasi waktu yang cukup besar. BIND bukan jawaban yang tepat untuk banyak use case, tetapi karena banyak konsep dan istilah DNS masih berasal dari BIND, pengalaman itu sangat berharga
  Saya rasa buku diremehkan untuk mempelajari hal-hal seperti ini. Materi yang ditemukan di web biasanya berupa teori tingkat tinggi, misalnya diagram blok lookup rekursif; materi berorientasi tugas seperti cara melakukan lookup rekursif dengan dig; atau materi tingkat rendah seperti membaca source untuk memahami kebijakan retry klien DNS lokal. Untuk memahami tiap potongan dan bagaimana semuanya saling terkait, mulai dari apa yang ingin dicapai hingga implementasi seperti di mana cache berada, hampir tidak ada pengganti pendekatan menyeluruh yang lazim ditemukan di buku. Di web bukannya sama sekali tidak ada, tetapi jarang

• Semua orang IT sebaiknya memiliki pengetahuan praktis tentang debugging masalah DNS
  DNS secara historis merupakan jalur bagi kerentanan keamanan penting, dan kemungkinan besar akan terus begitu. Kerentanan semacam ini menjadi jalur serangan untuk hampir semua protokol lain seperti SMTP. Bahkan sistem certificate authority yang dipakai HTTPS pun sangat bergantung pada protokol yang pada dasarnya tidak aman. Jika bank membeli sertifikat DV alih-alih OV, apakah Anda akan menyadarinya? Mungkin tidak
  Jadi tidak selalu buruk jika DNS tampak sulit dipelajari bagi orang yang kurang berminat. Sebab bahkan sekarang masih terlihat orang yang membuat fitur terkait DNS tanpa meluangkan waktu untuk benar-benar memahami sejarah hal-hal seperti port randomization, cache poisoning, dan AXFR

  • Apa pun yang menyiarkan atau mengklaim keputusan routing di lapisan mana pun pada jaringan terasa tampak lebih sederhana daripada kenyataannya, tetapi berpotensi berbahaya

• Sedikit promosi proyek sampingan yang memalukan: tulisan itu mengatakan alangkah baiknya jika resolusi DNS punya mode “debug”, dan ComfyDNS web UI punya fitur itu :3
  https://comfydns.com/
  Gambar di bagian atas yang bertuliskan TRACE google.com A IN adalah fitur tersebut
  ComfyDNS juga merupakan proyek untuk menggaruk rasa gatal pribadi. Saya lelah mengedit file zone bind9 dengan tangan, dan juga penasaran bagaimana DNS bekerja. Saya tahu hal-hal permukaannya, tetapi tidak tahu detailnya, jadi saya mengimplementasikan RFC “dari awal”. Saya memakai netty, tetapi tidak memakai library DNS. Cukup menyenangkan
  Mohon maaf kalau situsnya tidak tahan trafik lalu down. Ini aplikasi Rails yang berjalan di free tier Oracle Cloud

• Lelucon yang selalu saya dengar adalah bahwa DNS menggabungkan dua masalah tersulit dalam ilmu komputer: penamaan dan invalidasi cache

  • DNS memiliki counter validitas dalam satuan detik, dan penghitungan detiknya boleh cukup longgar
    Ini bukan jenis invalidasi cache yang sulit. Bahkan sebenarnya hampir tidak perlu melakukan “invalidasi”
    Di sisi server pun, mengirim campuran versi lama dan versi baru selama beberapa waktu sepenuhnya diperbolehkan
  • Itu bukan lelucon, memang benar

• Rasanya muncul lagi tulisan seperti ini. Pada 1990-an, internet lebih kecil dan komputer jauh lebih lambat serta kurang bertenaga, tetapi kami mempelajarinya dengan sangat mudah
  Saat itu, bagi ISP, hal-hal seperti DNS, LDAP, SMTP, IMAP adalah dasar dari dasar, dan orang benar-benar membaca dokumen resmi seperti RFC. Kalau ingin menjalankan server di internet, itu harus dipelajari, dan dengan sedikit investasi waktu—yakni memakai jam kerja berbayar—hal itu bisa dipelajari
  Generasi developer dan DevOps sekarang tidak punya kesabaran atau inisiatif, berharap disuapi, lalu menyalin-tempel apa saja dari StackOverflow dan blog bernilai rendah. Alih-alih mempelajari fondasi tempat internet dibangun, mereka mengambil tool wrapper tren terbaru minggu itu dan mengikuti instruksi blog yang buruk; ketika semuanya runtuh dan perusahaan kehilangan banyak uang, mereka merasa diperlakukan tidak adil. Itu karena mereka tidak meluangkan waktu untuk mempelajari dasar-dasar tentang bagaimana internet benar-benar bekerja
  Saya terus melihat hal seperti ini. Sebenarnya tidak sesulit itu. Tinggal kerjakan PR-nya

• Tidak sulit. DNS adalah salah satu dari sedikit teknologi yang tidak banyak berubah, dan cara kerjanya juga cukup intuitif
  dig memang bisa agak membingungkan. Fiturnya lebih banyak daripada nslookup yang lama, tetapi kurang intuitif. Sebagai catatan, nslookup masih berfungsi dengan baik
  Menurut saya, salah satu alasan orang-orang muda di industri ini bingung dengan DNS dan protokol inti adalah karena sekarang terlalu banyak hal yang “langsung berjalan”
  Misalnya, router WiFi sekarang “langsung berjalan” begitu dikeluarkan dari kotak. Pada awal 2000-an, untuk mengatur hal semacam itu dibutuhkan network engineer yang memahami DNS, IP, Ethernet, RFC1918, protokol routing nyata, dan banyak hal lain, serta kemungkinan besar tahu betul mengapa pengaturannya dibuat seperti itu
  Kalau menurut Anda DNS dari sudut pandang klien membingungkan, coba konfigurasi BIND ;-)
  /gerutuan si tua berjanggut leher

  • Saat berusia 14 tahun, saya mengelola dengan asal-asalan lingkungan Active Directory milik sebuah restoran—termasuk mail, web, dan CIFS—tanpa memahami DNS atau DHCP
    Seharusnya server DHCP di WRT54G membagikan IP statis domain controller sebagai server DNS agar resolusi nama berjalan benar, tetapi saya membuat semuanya berjalan hanya dengan alamat IP dan entri file hosts. Saya juga mengatur record MX domain ke IP WAN router, tanpa record PTR. Kalau dipikir-pikir, kelancaran pengiriman email waktu itu benar-benar ajaib
    Beberapa tahun kemudian saya baru memahami bagaimana DNS sebenarnya bekerja, dan pada awal usia 20-an saya mewarisi intranet internal yang memakai BIND sebagai nameserver untuk semua zona domain perusahaan yang eksternal. Saat memindahkan konfigurasi ini ke VPS demi meningkatkan keandalan, saya belajar sangat banyak tentang zone transfer, SOA, dan sebagainya. Saya bersyukur atas pengalaman itu, tetapi sekarang hampir semuanya ditangani untuk kita, sehingga menjadi aktivitas bernilai rendah. Baik atau buruk, “IT” tidak dinilai dengan cara yang sama seperti “software engineering”
  • Memang cara kerjanya relatif intuitif, tetapi itu hanya jika kita mengabaikan segala kemungkinan perilaku aneh seperti server yang mengabaikan TTL
    Saya tidak bisa melupakan saat Firefox merilis update yang mengaktifkan DNS-over-HTTPS secara default. Kami membagikan server DNS internal ke workstation lewat DHCP, lalu tiba-tiba bermunculan keluhan “email saya hilang! semuanya rusak!” Webmail internal dan server web intranet seolah-olah menghilang begitu saja
    Butuh waktu lebih lama dari semestinya untuk memahami apa yang terjadi. Sebagian karena pikiran “ini kan DNS, kenapa tiba-tiba rusak?” Namun cukup jelas bahwa Mozilla tidak mengantisipasi masalah yang sebenarnya mudah diprediksi ini
  • Hal-hal yang dibicarakan di sini hanyalah sebagian kecil dari DNS
    Misalnya, ketika melakukan lookup thing.behind.cdn.it, saya mendapat satu jawaban, sementara orang lain mendapat jawaban berbeda untuk nama yang sama. Itu sendiri cukup jelas, tetapi menjadi rumit ketika seseorang secara masuk akal bertanya, “bisakah Anda membuka celah firewall untuk thing.behind.cdn.it?”
    Ada server yang meneruskan request, ada server yang melakukan delegasi, ada server yang melakukan lookup atas nama kita dan ada yang tidak. Ada juga keajaiban search domain di sisi klien, dan belum tentu klien atau library resolver internal akan mematuhi TTL
    Jenis record juga sangat banyak, dan kadang server meminta klien menyambung ulang lewat TCP alih-alih UDP
    Jadi DNS cukup kompleks. Ia bekerja sangat baik, dan sebagian besar bagian yang rumit diabstraksikan menjadi hal-hal yang “umumnya langsung berjalan”, sehingga muncul ilusi bahwa DNS itu sederhana
  • Terkait memahami protokol lama, selama beberapa minggu terakhir saya membaca Networking for System Administrators dan membuat serta meninjau banyak catatan kartu Anki
    Mengejutkan betapa jauh lebih percaya diri saya dalam memahami networking pada level tinggi, termasuk DNS dan hal-hal di bawahnya seperti ethtool serta frame Ethernet
    Saya suka memahami sesuatu dari dasar, jadi saya memilih teknik elektro alih-alih ilmu komputer di universitas; mungkin itu sebenarnya tidak terlalu mengejutkan
  • Benar, konfigurasi BIND memang sulit. Unbound/nsd jauh lebih mudah ditangani. Namun proses menemukan dokumentasi yang tepat itu sendiri adalah latihan yang menyebalkan
    Prinsip DNS tidak terlalu sulit jika Anda memahami bahwa ia bersifat rekursif. Namun jika ingin mengonfigurasinya dengan mempertimbangkan keamanan, memiliki infrastruktur yang tepat, dan menyetel sampai detail terakhir, ada banyak hal yang harus dipelajari. Kalau tidak memasukkan BIND, sebenarnya tidak terlalu sulit