Tanggal 1 Februari nanti akan ada perubahan bersangkutan dengan DNS (Domain Name System). Secara singkat: berbagai domain yang terdaftar di berbagai DNS server yang tidak compliant dengan standar EDNS akan bermasalah sejak tanggal itu. Sebagai user: kemungkinan beberapa domain menjadi tidak bisa diakses sejak tanggal tersebut (atau beberapa hari/minggu setelahnya).
Sayangnya penjelasan singkat tersebuttidak cukup dan bikin penasaran banyak orang: sebenarnya apa sih yang akan terjadi? Saya coba cari sekilas belum ada penjelasan dalam bahasa Indonesia yang mudah dimengerti, jadi saya akan mencoba menjelaskannya di sini. Sebelum masuk ke penjelasan flag day ini, saya akan mulai dulu dengan penjelasan singkat tentang DNS dan sedikit sejarahnya karena ini ada hubungannya dengan masalah saat ini.
Contents
Apa itu DNS?
Pada Internet Protocol (IP) ketika sebuah program melakukan koneksi ke sebuah server berdasarkan nama, maka diperlukan proses translasi dari nama menjadi alamat IP. Proses translasi ini dulunya hanya memakai file teks (hosts.txt) ketika internet belum besar. Sampai sekarang pun ini masih didukung berbagai sistem operasi dengan file hosts.
Ketika jumlah domain makin banyak, maka diperlukan sistem baru. Mulai tahun 1983 sudah dibuat standar DNS (RFC 882 dan RFC 883), dan pada tahun 1984 software berdasarkan standar tersebut sudah mulai dibuat (namanya BIND). Kemudian pada tahun 1987 dibuat standar baru (RFC 1034 dan RFC 1035) menggantikan standar pertama.
Sebenarnya cara kerja DNS cukup sederhana: daripada semua nama dikelola satu pihak, biarlah dikelola masing-masing pihak dengan hierarki tertentu. Kenapa bentuknya hierarki seperti ini? Setiap level dari hierarki ini bisa diatur oleh sebuah otoritas untuk nama tersebut. Saya ambil contoh sebuah universitas ITB yang memiliki banyak jurusan.
- Tiap jurusan bisa punya subdomain sendiri (misalnya if.itb.ac.id untuk informatika)
- Tiap jurusan bisa memiliki DNS server sendiri, supaya bisa menambah/mengubah subdomainnya sendiri (tidak perlu repot lapor ke universitas)
- Di level itb.ac.id perlu diset, bahwa NS record untuk if.itb.ac.id ditangani oleh server tertentu di jurusan informatika
Ini berlaku untuk semua domain, bukan hanya domain organisasi seperti itu. Ketika kita mencari apakah IP untuk sebuah domain blog.compactbyte.com, maka pertama yang dilakukan adalah:
- Mencari tahu server mana yang menangani .com. Untuk pertanyaan paling atas ini bisa ditanyakan ke root name server (ada beberapa di dunia ini). Kita akan mendapatkan daftar server-server (bisa lebih dari satu) yang menangani domain .com
- Kita bisa bertanya ke salah satu server tersebut: mana server yang menangani compactbyte.com?
- Kita bisa bertanya ke server yang menangani compactbyte.com: apa alamat untuk blog.compactbyte.com
Proses di atas dinamakan resolving, dan proses selangkah demi selangkah dari titik atas itu disebut recursive resolving. Tentunya kalau saya membuat program, saya tidak akan menulis sendiri kode untuk melakukan resolving. Sudah ada library resolver yang akan melakukan semua proses di atas.
Sebenarnya dalam dunia nyata, proses seperti itu tidak benar-benar dilakukan karena lambat, tiap kali ingin pergi ke facebook, harus mencari dulu di root server mana yang menangani .com, lalu mana yang menangani facebook.com dst. Dalam praktiknya: kalau sudah tahu nama domainnya, hasilnya akan dicache. Jadi setiap kali proses tidak perlu lagi bertanya ke root server untuk .com karena jawaban sudah dicache.
Supaya lebih efektif biasanya kita memakai sebuah server DNS publik. Ini biasanya dari ISP tapi bisa juga memakai milik Google (8.8.8.8), Cloudflare (1.1.1.1), dan masih banyak lagi. Ketika kita bertanya ke DNS milik ISP kita, maka biasanya jawaban bisa instan karena banyak orang mengakses situs yang sama dan jawabannya masih diingat (dicache). DNS server semacam ini disebut sebagai “caching server“.
Artikel di Wikipedia memberikan gambar yang lebih real mengenai proses ini. Ketika kita bertanya ke DNS milik ISP, maka server tersebut bisa bertanya ke server DNS lain, atau melakukan sendiri proses rekursif yang saya jelaskan di atas untuk mencari IP sebuah domain.
Di dalam server DNS, catatan pemetaan nama ke IP disimpan sebagai sebuah record. Tepatnya lagi ini disebut sebagai address record (singkatnya satu huruf: A). DNS juga memiliki berbagai record lain. Contoh record lain adalah mail exchanger (singkatnya MX) untuk mengetahui server mana yang digunakan untuk menangani email. Kenapa harus ada banyak record? karena kegunaannya berbeda-beda. Contohnya dengan adanya record MX yang terpisah dari record address (A) maka kita bisa punya email yang dihosting di server lain (misalnya Google) dan tidak harus di server kita sendiri.
Saya juga akan menjelaskan sedikit apa yang terjadi waktu kita membeli domain. Domain kita akan didaftarkan di server TLD. Lalu biasanya tempat kita membeli domain akan mengeset otomatis name server ke server milik registar tempat kita membeli. Ini bisa kita ubah agar memakai server lain, misalnya server sendiri atau Cloudflare
Beberapa hal yang perlu diketahui adalah:
- Di dalam mesin (PC/Mobile) ada software resolver
- Dalam server DNS juga ada resolver untuk bertanya pada server DNS lain
- Software di berbagai server ini bisa berbeda (tidak hanya ada satu software server DNS, ada banyak, dan masing-masing ada banyak versi)
- Satu server DNS bisa menangani banyak domain
Extension Mechanism for DNS (EDNS)
Spesifikasi awal DNS kurang fleksibel sedangkan diperlukan banyak fitur baru untuk DNS baik itu untuk meningkatkan performance maupun security. Contoh masalah performance: pada sistem DNS lama ukuran paket yang bisa ditransfer maksimum hanya 512 byte via UDP. Dalam hal security: sebuah DNS server bisa dibajak dengan relatif mudah karena tidak ada signature atau tanda tangan digital yang menyatakan bahwa record yang terdaftar adalah benar adanya.
Pada tahun 1999 diperkenalkanlah Extension Mechanism for DNS. Kemudian standar ini diperbaiki lagi tahun 2013. Jadi EDNS ini sudah dicetuskan 20 tahun yang lalu. Mekanisme EDNS ini backward compatible dengan DNS. Di atas EDNS ini dibangunlah berbagai teknologi baru seperti DNSSEC (Domain Name System Security Extensions).
Untuk mengetahui apakah sebuah server DNS kompatibel dengan EDNS, maka ini yang dilakukan:
- Resolver akan menanyakan record OPT yang tidak dikenali oleh DNS server lama
- Server lama (tidak mendukung EDNS) akan mengabaikan OPT, dan menjawab record yang bisa dijawab
- Server yang baru (mendukung EDNS) akan menjawab bahwa OPT didukung
Sejak diciptakannya, DNS sudah menjadi sistem yang sangat kompleks, dengan 185 RFC yang total halamannya lebih dari 2000 halaman jika dicetak. Ini membuat detail DNS sulit dipahami, dan banyak orang tidak mau pusing memakai software baru yang mendukung berbagai fitur DNS, selama semuanya masih berjalan normal. Ini salah satu alasan kenapa orang tidak mengupdate semua ke server versi terbaru.
Masalah EDNS
Sekarang masalahnya adalah: ada server yang tidak menjawab jika ditanya dengan record OPT, atau jawabannya tidak benar (silakan lihat presentasi ini untuk berbagai jawaban yang salah). Sebenarnya yang diharapkan cuma ini:
- Kalo kamu mendukung EDNS, jawab yang tegas dengan benar
- Kalo kamu tidak mendukung EDNS, jawablah bahwa tidak mendukung EDNS
Banyak server yang jawabannya tidak jelas, atau bahkan tidak menjawab. Untuk mengatasi ini, resolver DNS harus bekerja ekstra (istilahnya untuk akal-akalan ini adalah workaround): Jika server ditanya dengan protokol EDNS dan menjawab dengan sempurna, maka diasumsikan server tersebut memang mendukung EDNS. Tapi jika ternyata tidak mendukung, maka ditunggu dulu sampai timeout, terus dicoba lagi ditanya pakai protokol DNS lama (dan kadang tidak menjawab juga, tunggu lagi sampai timeout).
Proses ini tentunya membuat lambat proses resolving. Karena sudah lama sekali standar ini diperkenalkan, maka diputuskan begini:
- Mari kita stop workaroundnya: kalau jawaban server nggak standar, ya sudah ignore aja servernya (anggap sudah mati)
- Mari kita buat internet lebih aman dengan mengadopsi standar baru
Kapan ini harus dilakukan? setelah dilihat bahwa sebagian besar (>90% server) sudah mendukung EDNS, maka diputuskan bahwa tanggal 1 Februari 2019 merupakan saat yang tepat. Berbagai DNS publik dunia akan menghentikan workaround yang dilakukan dan berbagai software yang tadinya mendukung workaround juga akan diupdate.
Flag Day
Kenapa namanya flag day? nama ini sifatnya historis. Dulu ada perubahan definisi ASCII di sistem operasi Multics yang dilakukan di Flag Day (hari bendera amerika). Sejak itu istilah ini digunakan untuk perubahan besar pada sistem komputer.
Seperti dijelaskan di atas: software resolver ini ada di device (PC/mobile) kita, dan juga ada di DNS publik seperti ISP dan Google). Biasanya resolver di mesin (komputer/ponsel) kita hanya akan bertanya ke caching server lain di ISP atau DNS publik lain.
Pada flag day, resolver publik yang besar (seperti Google, Quad9, CloudFlare) akan mematikan support untuk workaround. Server DNS untuk domain tertentu yang tidak menjawab dengan benar akan dianggap mati. Sebenarnya yang diharapkan bukan semua server harus support EDNS, tapi harus menjawab dengan jujur dan benar support atau tidak support. Jika kita memakai salah satu server DNS publik tersebut (baik langsung maupun tidak langsung), maka kita akan gagal mengakses domain-domain tertentu.
Untuk sementara waktu, ketika ISP belum mengupdate softwarenya, mungkin situs tersebut masih bisa diakses, tapi setelah beberapa waktu, berbagai ISP di dunia akan mengupdate server/resolver mereka dengan versi terbaru dan akhirnya domain-domain tersebut akan tidak bisa diakses sama sekali jika software DNS pada server yang tercantum di nama domain tidak diupdate.
Sebagai catatan: bukan pemilik domain yang harus mengupdate software, tapi pemilik server DNS yang dipakai di domain tersebut. Jadi misalnya Anda membeli domain dari sebuah registrar dan memakai nameserver registrar, maka registrar tersebut yang harus mengupdate software DNS-nya. Alternatif lain adalah: pemilik domain bisa memakai server DNS lain yang sudah memakai software DNS terbaru.
Selain perubahan di DNS publik, ada juga perubahan kode pada berbagai library resolver dan server DNS, misalnya BIND supaya mendrop workaround. Contoh realnya perubahan kode yang dilakukan di BIND bisa dilihat di URL ini:
https://gitlab.isc.org/isc-projects/bind9/commit/615ebc39e39abd06e97131339cb508a8651ac65c
Apakah domain saya akan baik-baik saja?
Domain yang Anda miliki bisa dicek di situs https://dnsflagday.net. Jika hasilnya OK, maka sudah aman. Jika hasilnya STOP, maka ini sangat berbahaya, dan jika hasilnya SLOW maka sebaiknya setting server diperbaiki atau versinya diupdate. Sebelum panik, cobalah testnya sekali lagi, karena jika server sedang sibuk, kadang hasilnya bisa salah. Jika mengerti penggunaan dig, maka sebaiknya cek juga secara manual dari jaringan yang dekat dengan server (misalnya jika server di Indonesia, cek dari ISP Indonesia).
Ketika hasilnya SLOW atau STOP akan muncul link yang menjelaskan masalah detail eksaknya untuk domain tersebut. Jika situs Anda cuma diakses puluhan atau ratusan orang, response “SLOW” mungkin tidak apa-apa, tapi jika situs Anda sangat ramai, ya sebaiknya diperbaiki.
Seperti yang sudah saya sebutkan sebelumnya, sebagai pemilik domain, yang bisa dilakukan adalah:
- Pindah name server ke yang sudah mendukung software terbaru
- Menghubungi pemilik server DNS untuk mengupdate softwarenya
Jika Anda sekedar pemakai sebuah situs, Anda bisa juga memeriksa situs tersebut dan memberi tahu adminnya, supaya dia bisa melakukan perubahan yang perlu. Ini terutama untuk situs yang kecil/kurang populer karena situs besar biasanya sudah menangani ini.
Penutup
Kadang masalah tertentu sulit dijelaskan tanpa mengetahui detail teknis, dan DNS Flag Day ini merupakan salah satu contohnya. Semoga artikel ini cukup bisa menjelaskan. Secara umum: tidak perlu panik. Para admin mungkin harus bekerja ekstra keras, tapi persiapan DNS Flag Day ini sudah cukup lama, jadi harapannya semua akan berjalan lancar pada tanggal yang ditentukan nanti.