ICANN87 Hari 4: Dari Aksara Bali sampai Root Server

Seri ICANN87. Sebelumnya: Hari 3. Berikutnya: Hari 5.

Kalau Hari 3 soal mengukur, Hari 4 soal membongkar asumsi. Dari jam sembilan pagi sampai sore aku hampir nggak keluar dari koridor Jakarta A dan Jakarta B. Empat sesi “How It Works” dalam satu hari. Kedengarannya seperti kelas pengantar, tapi justru di sesi-sesi dasar inilah aku menemukan hal-hal yang selama ini aku ajarkan dengan setengah benar.

09.00, Jakarta A: domain dalam aksara Bali

Sesi pertama hari ini, How It Works: Internationalized Domain Names, dibawakan oleh tim program IDN ICANN. Bagian akhirnya bikin aku duduk lebih tegak: ada pembahasan khusus soal Label Generation Rules (LGR) untuk aksara yang dipakai di Indonesia, yaitu aksara Bali, aksara Jawa, dan aksara Arab termasuk huruf-huruf Pegon.

Pegon, buat yang belum tahu, adalah aksara Arab yang dimodifikasi untuk menulis bahasa Jawa, Sunda, dan Madura. Selama ratusan tahun ia dipakai di pesantren. Dan sekarang ada orang yang duduk dan memikirkan, huruf Pegon mana yang aman dipakai di nama domain.

Kata kuncinya aman. Ini yang jarang dibahas di luar komunitas ICANN:

Nama domain non-Latin tidak disimpan seperti yang kamu lihat. Di DNS, música.café sebenarnya adalah xn--msica-7ua.xn--caf-dma. Bentuk yang kamu lihat disebut U-label (Unicode), bentuk yang benar-benar ada di DNS disebut A-label (ASCII, diawali xn--). Konversinya diatur standar IETF bernama IDNA2008 (RFC 5890 sampai 5894).

Lolos IDNA2008 belum tentu boleh dipakai. RFC 5892 bahkan menulis terang-terangan bahwa label yang semua karakternya valid tidak otomatis bisa dipakai di DNS. Registry wajib menambah aturan sendiri, dan aturan itulah yang disebut LGR.

Kenapa perlu aturan tambahan? Karena huruf bisa menyamar. Contoh di slide: .epic dalam huruf Latin dan .еріс dalam huruf Kiril. Di layar keduanya terlihat persis sama, tapi kode Unicode-nya berbeda total. Ini dasar dari homograph attack, dan di kerjaanku ini muncul sebagai link phishing yang “kelihatannya benar”.

Jadi LGR menentukan dua hal: karakter apa yang boleh masuk (repertoire), dan karakter mana yang dianggap “sama” (variant). Prinsip desainnya berasal dari RFC 6912, dan ada satu prinsip yang menurutku layak dicetak besar-besar di ruang kerja tim security mana pun: conservatism. Default-nya tidak boleh. Sebuah karakter baru dimasukkan kalau sudah terbukti aman dan berguna. Sekali masuk, karakter itu sangat susah dikeluarkan lagi.

Unicode 18.0 punya 175 aksara dan 172.808 karakter. ASCII untuk domain hanya mengizinkan huruf, angka, dan tanda hubung. Di antara dua angka itulah kerja LGR berada.

Coba sendiri bagaimana browser “melihat” domain IDN:

# Python: ubah U-label jadi A-label
python -c "print('música.café'.encode('idna'))"
# b'xn--msica-7ua.xn--caf-dma'

# Lihat bedanya 'e' Latin dan 'е' Kiril, yang di layar tampak sama
python -c "print([hex(ord(c)) for c in 'epic'], [hex(ord(c)) for c in 'еріс'])"

Catatan kecil: codec idna bawaan Python masih IDNA2003. Untuk kerja serius, pakai paket idna yang mengikuti IDNA2008.

10.30, Jakarta B: IETF, organisasi tanpa anggota

Sesi How It Works: The IETF menjawab pertanyaan yang sering aku dapat dari murid: “Yang bikin standar internet itu siapa sih?”

Hal paling unik tentang Internet Engineering Task Force: secara formal ia tidak punya anggota. Siapa pun bisa ikut, cukup gabung mailing list kelompok kerja. Keputusan tidak diambil lewat voting, tapi lewat rough consensus. Di rapat tatap muka, ketua kelompok kerja kadang meminta peserta humming, bergumam, alih-alih angkat tangan, supaya yang dinilai adalah suasana ruangan, bukan hitungan suara. Proses ini didokumentasikan di RFC 7282. Semboyan lamanya terkenal: “We reject kings, presidents and voting. We believe in rough consensus and running code.”

Bagian yang nyambung ke ICANN: IETF yang menulis protokolnya (DNS, DNSSEC, IDNA, dan seterusnya), sementara fungsi IANA yang dijalankan oleh PTI menyimpan registry parameter protokol yang dibutuhkan standar-standar itu. Jadi waktu kamu melihat angka “algoritma 13” di record DNSSEC, angka itu tercatat di registry IANA atas permintaan IETF.

Pelajaran buat aku: kalau aku mau thread “AI agent sebagai klien DNS” dari artikel pertamaku jadi sesuatu yang nyata, mungkin tempatnya bukan cuma paper. Bisa jadi Internet-Draft.

13.15, Jakarta A: perjalanan satu paket

How the Internet Really Works dibawakan oleh tim Technical Engagement dari Office of the CTO ICANN. Salah satu pembicaranya adalah Champika Wijayatunga, yang dua tahun lalu ikut mengajar di Training of Trainer PANDI, juga di Nusa Dua. Rasanya seperti ikut kelas ulangan dengan guru yang sama, tapi kali ini aku lebih paham pertanyaan apa yang harus diajukan.

Slide pembukanya menunjukkan “pandangan umum” tentang internet: user, koneksi, “internet”, server. Lalu pertanyaannya: apakah ini gambaran lengkapnya? Jelas bukan. Internet adalah jaringan dari jaringan, tanpa kontrol terpusat. ISP saling mengumumkan blok alamat mereka lewat BGP, sering bertemu di Internet Exchange Point. Alamat IP mengalir dari IANA ke Regional Internet Registry (untuk kita, APNIC), lalu ke ISP, lalu ke rumah dan kantor.

Hal yang paling berguna buat aku sebagai trainer adalah diagram pengelolaan root zone. Perubahan root zone tidak dilakukan oleh root server. Alurnya begini: pengelola TLD mengajukan perubahan ke operator fungsi IANA (PTI), PTI meminta implementasi, Root Zone Maintainer (Verisign) membuat dan menerbitkan file root zone, lalu file itu didistribusikan ke 12 operator root server. Banyak orang, termasuk aku dulu, mengira root server itu yang “memutuskan”. Padahal mereka hanya menyajikan.

15.00, Jakarta A: tujuh mitos root server

Sesi terakhir yang aku ikuti hari ini adalah How It Works: Root Server Operations oleh RSSAC. Satu slide-nya berupa tabel “mitos vs realita”, dan aku jamin minimal satu mitosnya pernah kamu percayai:

Mitos	Realita
Root server mengontrol ke mana lalu lintas internet pergi	Router yang mengontrol itu
Sebagian besar query DNS ditangani root server	Sebagian besar query selesai tanpa perlu ke root sama sekali
Root zone diurus oleh operator root server	Root zone diurus oleh IANA
Huruf A sampai M punya arti khusus	Tidak ada identifier yang istimewa
Root server cuma ada 13	Ada 13 identifier teknis, tapi lebih dari 2.000 instance di seluruh dunia
Para operator bekerja sendiri-sendiri	Mereka berkoordinasi sebagai satu sistem
Root server menerima seluruh nama yang kamu cari	Dengan QNAME minimisation, sering yang sampai hanya bagian TLD-nya

Mitos nomor dua yang paling sering aku dengar di kelas. Jawabannya ada di caching. Record delegasi TLD di root punya TTL satu sampai dua hari, jadi resolver jarang perlu bertanya ulang ke root.

Satu fakta lagi yang jarang diketahui: alamat root server bisa berubah. Pada 27 November 2023, b.root-servers.net yang dioperasikan USC/ISI pindah ke alamat baru, 170.247.170.2. Alamat ini adalah alamat root server pertama yang dialokasikan oleh LACNIC, registry internet Amerika Latin, dengan tujuan menambah keragaman RIR di belakang sistem root. Alamat lama tetap dilayani setidaknya satu tahun, karena daftar alamat root (root hints) tertanam di software resolver di seluruh dunia dan butuh waktu untuk diperbarui. RSSAC bahkan menerbitkan pedoman khusus untuk proses seperti ini (RSSAC061).

Dan ini favoritku: kamu bisa bertanya ke root server, instance mana yang sedang menjawabmu.

# Instance root mana yang paling dekat denganmu?
dig @k.root-servers.net hostname.bind CH TXT +short
dig @f.root-servers.net hostname.bind CH TXT +short

# Lihat TTL delegasi .id langsung dari root
dig @a.root-servers.net id NS +norecurse
# Perhatikan angka 172800 (dua hari) di kolom TTL.

Jalankan dari Batam, lalu dari Manado, dan kemungkinan besar kamu akan dijawab oleh instance yang berbeda. Itu anycast: banyak server berbagi satu alamat, dan routing yang memilih yang terdekat. Efek sampingnya bagus untuk keamanan: serangan DDoS ikut tersebar ke banyak instance, bukan menumpuk di satu titik.

Pesan penutup RSSAC untuk “kamu dan jaringanmu” sederhana: pakai resolver yang memvalidasi DNSSEC, ikut komunitas teknis seperti APRICOT, IETF, atau RSSAC Caucus, dan kalau organisasimu tertarik meng-host instance root anycast, tinggal ajak bicara anggota RSSAC.

Yang aku bawa pulang dari hari keempat

1. IDN bukan cuma soal inklusi, tapi juga soal keamanan. Aksara Bali dan Jawa di nama domain adalah kabar baik untuk bahasa daerah, dan aturan LGR yang konservatif adalah alasan kenapa itu bisa aman.
2. Standar internet dibuat oleh siapa saja yang mau datang dan menulis. IETF tidak punya keanggotaan formal. Aku yang dari Batam juga bisa ikut.
3. Root server itu penyaji, bukan pengatur. Kalimat ini akan langsung masuk ke slide .id Academy berikutnya.

Besok, Hari 5, hari yang paling aku tunggu: Open Mic dengan SSAC dan RSSAC, sesi tentang bagaimana AI agent menamai dirinya sendiri, dan sepuluh tahun PTI.