Skip to content

ICANN87 Hari 3: Internet yang Diukur, Bukan Ditebak

· 5 min read

Seri ICANN87. Sebelumnya: apa yang mau aku cari di Bali. Berikutnya: Hari 4.

Senin pagi di Nusa Dua dimulai dengan antrean kopi yang lebih panjang dari antrean registrasi. Di depanku ada dua orang yang ngobrol soal TTL record NS seperti orang lain ngobrol soal bola. Aku cuma bisa senyum. Hari ketiga, dan aku mulai ngerti kenapa orang bilang ICANN Meeting itu rasanya seperti masuk ke grup WhatsApp yang semua anggotanya admin DNS.

Hari ini aku bolak-balik antara tiga tempat: Mangupura Hall untuk plenary, Nusantara 3 untuk Tech Day ccNSO, dan Jakarta A untuk sesi OCTO. Kalau harus diringkas jadi satu kalimat: komunitas DNS nggak percaya sama firasat, mereka percaya sama pengukuran.

Plenary: dari kebijakan ke praktik

Community Plenary 1 judulnya panjang: From ICANN Policy to Practice: Implementing a Secure, Stable, and Multilingual DNS. Tapi pertanyaan intinya sederhana dan, jujur, agak menampar: kebijakan sudah disepakati, lalu kenapa implementasinya sering jalan di tempat?

Yang menarik buatku adalah tiga kata yang disandingkan di judul itu: secure, stable, multilingual. Selama ini aku menganggap “multibahasa” itu urusan inklusi, dan “aman” itu urusan orang security seperti aku. Di plenary ini keduanya diperlakukan sebagai satu paket. Masuk akal juga sih. Domain dengan aksara non-Latin yang tidak diatur dengan baik adalah pintu masuk homograph attack, dan email yang menolak alamat non-ASCII adalah masalah stabilitas, bukan cuma masalah UX.

Pelajaran pertama hari ini: di ICANN, “keamanan” bukan satu departemen. Ia muncul di diskusi bahasa, di diskusi kontrak registrar, sampai di diskusi disaster recovery ccTLD.

Tech Day ccNSO: ruangan para operator

Kalau plenary itu ruang tamu, Tech Day ccNSO itu dapurnya. Diselenggarakan oleh ccNSO Technical Working Group, empat sesinya terbuka untuk siapa saja yang tertarik topik teknis, operasional, dan keamanan. Isinya operator ccTLD dari berbagai negara yang berbagi apa yang mereka kerjakan dan, yang lebih berharga, apa yang pernah rusak.

Ada satu pola yang aku tangkap dari beberapa presentasi: insiden DNS jarang terjadi karena serangan canggih. Lebih sering karena perubahan rutin yang salah urutan. Ganti provider DNS tapi lupa urusan DS record. Rotasi kunci yang jadwalnya tabrakan dengan TTL. Migrasi sistem registry yang ternyata punya ketergantungan diam-diam. Hal-hal yang di slide terlihat membosankan, tapi justru itu yang bikin satu negara “hilang” dari internet selama beberapa jam.

Buat aku yang datang dari sisi SOC, ini menenangkan sekaligus menakutkan. Menenangkan karena masalahnya bisa dicegah dengan disiplin, bukan dengan teknologi mahal. Menakutkan karena disiplin itu justru yang paling susah dijaga.

Satu hal lagi yang jarang diketahui orang: ccNSO punya DNS Abuse Standing Committee (DASC), dan survei DNS abuse untuk ccTLD mereka sudah masuk edisi ketiga. Survei ini dibahas sejak hari pertama, dan hasilnya terus muncul di sesi-sesi lain sepanjang minggu. ccTLD seperti .id tidak terikat kontrak ICANN seperti .com, jadi cara tiap negara menangani abuse bisa sangat berbeda. Survei seperti ini adalah salah satu dari sedikit cara untuk melihat gambaran globalnya.

OCTO DATA: kesehatan DNS punya angka

Sore harinya di Jakarta A, ada sesi yang paling aku tunggu hari ini: OCTO DATA. OCTO adalah Office of the Chief Technology Officer di ICANN, dan sesi ini membahas bagaimana mereka terus menyediakan data tentang kesehatan dan keamanan, stabilitas, serta ketahanan (SSR) DNS.

Ini bagian yang menurutku paling jarang diketahui orang di luar komunitas ICANN, padahal datanya terbuka. Dua yang paling relevan buat praktisi security:

  • DAAR (Domain Abuse Activity Reporting). Sistem yang menghitung domain yang terlibat phishing, malware, botnet command-and-control, dan spam di tiap TLD, berdasarkan feed reputasi yang dipakai industri. Laporannya terbit rutin. Kalau kamu pernah penasaran “TLD mana yang paling sering dipakai phishing?”, jawabannya nggak perlu ditebak. Ada datanya.
  • ITHI (Identifier Technologies Health Indicators). Kumpulan metrik untuk memantau kesehatan sistem identifier internet secara keseluruhan, bukan cuma abuse. Contohnya seberapa banyak query yang sampai ke root server sebenarnya untuk nama yang tidak ada.

Yang bikin aku berpikir: di kerjaan, aku sering memutuskan “domain ini mencurigakan” dari intuisi plus beberapa sinyal seperti umur domain dan kemiripan nama. Di sini aku melihat orang-orang yang mencoba mengukur masalah yang sama di skala seluruh internet, dan mereka jauh lebih berhati-hati soal klaim. Mereka sangat jelas membedakan “terdeteksi di feed reputasi” dengan “terbukti abuse”. Pembedaan itu penting, karena kebijakan yang dibangun di atas angka yang salah bisa menjatuhkan domain yang sah.

Coba sendiri: ukur DNS-mu, jangan ditebak

Semangat hari ini adalah “ukur, jangan tebak”. Jadi ini tiga pengecekan yang bisa kamu jalankan di domain sendiri dalam lima menit:

# 1. Siapa nameserver domainmu, dan apakah jawabannya konsisten?
dig +short NS contoh.id
dig @<nameserver-1> contoh.id SOA +short
dig @<nameserver-2> contoh.id SOA +short
# Nomor serial SOA harus sama. Kalau beda, ada nameserver yang ketinggalan update.

# 2. DNSSEC: ada DS record di parent?
dig +short DS contoh.id
# Kosong = domainmu belum ditandatangani (atau rantainya putus).

# 3. Resolver-mu memvalidasi?
dig +dnssec contoh.id A | grep flags
# Cari flag "ad". Kalau tidak ada, resolver-mu tidak memvalidasi DNSSEC.

Dan kalau mau lebih jauh, ICANN punya inisiatif bernama KINDNS (Knowledge-sharing and Instantiating Norms for DNS and Naming Security): daftar praktik terbaik yang dipecah per peran, misalnya operator resolver, operator zona authoritative, sampai jaringan perusahaan. Ini salah satu sumber yang paling berguna dan paling jarang disebut di kelas-kelas keamanan siber di Indonesia. Aku sudah catat buat jadi materi .id Academy.

Yang aku bawa pulang dari hari ketiga

  1. Keamanan DNS lebih sering soal disiplin operasional daripada soal penyerang canggih. Sebagian besar cerita gangguan yang aku dengar berawal dari perubahan rutin.
  2. Data abuse itu ada dan terbuka. DAAR dan ITHI bisa jadi bahan riset, bahan ajar, bahkan bahan paper. Aku mulai melihat arah paper untuk PANDI: membandingkan apa yang aku lihat di inbox defender dengan apa yang diukur di level TLD.
  3. Hati-hati dengan kata “abuse”. Terdeteksi dan terbukti itu dua hal berbeda. Defender, termasuk aku, sering lupa bedanya.

Besok, Hari 4, jadwalku padat: IDN dengan aksara Bali dan Jawa, cara kerja IETF, sampai tutorial root server. Ternyata itu hari yang paling banyak mengubah cara aku melihat “internet”.

All writing | RSS