Kiell Tampubolon: tulisan dalam Bahasa Indonesia

Kunci CA eMudhra Ternyata Cuma Satu Byte. Container Kamu Masih Percaya?

Kiell Tampubolon — Sat, 24 Oct 2026 00:00:00 GMT

Versi bahasa Inggris: The eMudhra CA Keys Were One Byte Long. Does Your Container Still Trust Them?

Delapan private key milik intermediate CA eMudhra ternyata hanya angka satu byte, bisa ditebak dalam hitungan milidetik. Chrome dan Firefox memblokirnya di hari yang sama. Base image, bundle Python, dan keystore JVM kamu tidak memblokir apa pun sampai ada yang rebuild.

TL;DR (untuk pembaca non-teknis)

Sebuah certificate authority (CA), yaitu lembaga yang menjamin sebuah situs itu asli, membuat delapan kunci penandatangan yang begitu lemah sehingga siapa pun bisa menebaknya.

Browser menutup celah ini dalam hitungan jam. Tapi server, script, sistem build, dan aplikasi punya daftar “siapa yang dipercaya” sendiri, dan daftar itu tidak update otomatis.

Risiko bisnisnya: penyerang bisa menyamar sebagai layanan tepercaya di mata software kamu, bukan di mata browser pelanggan.

Tanyakan ke tim teknis: “Layanan kita ambil daftar CA tepercayanya dari mana, dan kapan terakhir di-refresh?”

Yang terjadi

Fakta dari pernyataan eMudhra, analisis Scott Helme, dan ringkasan di dev.to:

Seorang peneliti melaporkan pada 17 Oktober 2026 bahwa private key delapan intermediate CA eMudhra bocor.
Helme menemukan kunci itu bukan nilai acak 384-bit. Isinya angka kecil seperti 4, 56, dan 115, jadi “pencariannya” tinggal mencoba 1, 2, 3, dan seterusnya. Google menyebutnya “dibuat dengan randomness yang tidak memadai”. Secara teknis benar, tapi sangat meremehkan.
eMudhra menyatakan ada cacat di langkah key wrap/unwrap pada ceremony 30 April 2025. Hasilnya, muncul set kunci kedua yang lemah di samping yang kuat, dan set lemah inilah yang dikirim ke root program.
eMudhra juga menyatakan root key tidak terdampak, dan tidak ada dari delapan intermediate itu yang menerbitkan sertifikat untuk situs sungguhan. Satu berada di production tapi belum menerbitkan apa pun.
Chrome memblokir intermediate tersebut lewat CRLSet dalam hitungan jam. OneCRL milik Mozilla sampai ke Firefox standar dalam waktu kurang dari tiga jam.
Menurut blog keamanan Google, emSign ECC Root CA - G3 juga akan dihapus dari Chrome Root Store, mulai bergulir 27 Oktober 2026.

Kenapa ini relevan di Indonesia

Banyak tim di Indonesia menjalankan container di VM, cloud, atau on-prem dengan image yang di-build sekali lalu jalan berbulan-bulan. Layanan internal, integrasi antar-sistem, dan job CI sering memanggil endpoint HTTPS tanpa ada browser di antaranya.

Di jalur seperti itu, perlindungan cepat dari browser tidak ikut bekerja. Yang menentukan hanya isi trust store di image atau runtime kamu. Jadi pertanyaan “kapan terakhir image ini di-rebuild?” ikut menentukan postur keamanan, bukan sekadar urusan housekeeping.

Celahnya

Browser            -> fast distrust lane (CRLSet, OneCRL)   -> blocked in hours
Debian/Ubuntu img  -> ca-certificates package, baked in      -> stale until rebuilt
Python (certifi)   -> its own bundle                         -> stale until upgraded
Java (cacerts)     -> JDK keystore                           -> wait for JDK vendor
Vendored (Go, Node, mobile, firmware) -> frozen snapshots    -> depends on release

Menurut Endor Labs, certifi 2026.10.19 dan Alpine ca-certificates 20261020-r0 sudah membawa perubahannya. Untuk Java, anggap belum terkonfirmasi sampai vendor JDK kamu menyatakan sebaliknya. Poin utama mereka: TLS stack default di Python, Go, Node, dan kebanyakan CLI tool tidak mengecek revocation, jadi satu-satunya cara menghilangkan risiko adalah update trust store.

Kata para praktisi

Kegagalan proses. Di LWN, seorang komentator bertanya bagaimana HSM bisa menghasilkan kunci satu byte, dan curiga masalahnya lebih dalam dari satu script yang bug.
Marketing versus kenyataan. Komentator lain menyoroti CA ini memakai bahasa post-quantum dan zero-trust, sementara yang dikirim setara satu byte entropi.
Keraguan soal penyimpanan. Yang ketiga menunjuk bahwa kesulitan eMudhra memverifikasi tanda tangan CRL-nya sendiri mengisyaratkan kunci tidak disimpan di HSM sebagaimana mestinya.
Usulan struktural. Satu komentator mengusulkan HSM attestation wajib untuk setiap root dan intermediate, supaya pembuatan kunci bisa dibuktikan.
Pandangan “sudah terkendali”. Tidak semua melihatnya sebagai darurat. Karena belum ada sertifikat dari enam intermediate TLS itu yang tercatat di Certificate Transparency, browser yang mewajibkan CT tetap akan menolak sertifikat palsu. Bantahan Helme: curl dan Python dengan senang hati menerima chain palsu di proof of concept-nya.

Pendapat saya

Saya setuju dengan yang bilang CA adalah ceritanya, dan dengan yang bilang trust store adalah pelajarannya. Dua-duanya benar, di lapisan yang berbeda.

Respons browser sangat baik dan saya tidak mau meremehkannya. Hitungan jam, bukan minggu. Tapi kecepatan itu hanya melindungi satu jenis client yang memang dirancang untuk itu. Gambaran jujurnya: web PKI punya jalur cepat untuk browser dan jalur lambat untuk yang lain, dan sebagian besar traffic backend ada di jalur lambat.

Soal pandangan “sudah terkendali”, saya kurang sependapat. Belum ada sertifikat yang tercatat bukan jaminan untuk masa depan. Kuncinya sudah publik, jadi yang tersisa di antara client internal kamu dan sertifikat palsu hanyalah apakah trust store masih mencantumkan parent-nya. Itu bisa diperbaiki dengan rebuild, jadi lakukan.

Untuk tim, ini mengarah ke satu kebijakan yang membosankan: base image di-rebuild terjadwal, dan versi trust store bisa di-query, bukan sekadar diharapkan aman. Ini juga mendukung diversifikasi CA dan masa berlaku sertifikat yang pendek, karena mengganti CA jauh lebih mudah kalau sudah pernah dilatih.

Coba dalam 15 menit

1. Daftar siapa saja yang melakukan panggilan TLS keluar

Service, worker, CI runner, script. Tanyakan “trust store yang mana”, bukan “versi berapa”.

2. Cek bundle OS di container yang sedang jalan

docker exec <container> sh -c 'ls -l /etc/ssl/certs/ca-certificates.crt; grep -c "BEGIN CERTIFICATE" /etc/ssl/certs/ca-certificates.crt'
docker exec <container> dpkg -l ca-certificates
docker exec <container> sh -c 'ls /etc/ssl/certs | grep -i emsign'

Bandingkan versi ca-certificates dengan yang dirilis distro kamu sekarang (Endor mencantumkan versi perbaikan untuk Debian dan Ubuntu). Tanggal file yang lebih lama dari 17 Oktober pada image yang berumur panjang berarti harus rebuild.

3. Cek bundle bahasa pemrograman

python -c "import certifi; print(certifi.__version__, certifi.where())"
pip install --upgrade certifi
keytool -list -cacerts -storepass changeit | grep -i emsign

requests memakai certifi kecuali kamu menimpa verify=, jadi satu mesin bisa punya dua “kebenaran” yang berbeda. Untuk Java, changeit adalah password default cacerts. Solusinya build JDK yang lebih baru, bukan mengedit keystore manual.

4. Lihat apa yang disajikan server

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
openssl x509 -in certificate.pem -noout -issuer -subject -fingerprint -sha256

Kalau issuer menyebut intermediate eMudhra atau emSign, cari tahu kenapa dan kapan diperbarui.

Biar jadi kebiasaan

docker build --pull --no-cache -t myapp:$(date +%Y%m%d) .

Jalankan itu mingguan di CI. Base image yang segar membawa trust store yang segar.

Bahan belajar lanjutan

Pernyataan insiden eMudhra sendiri, untuk penyebab menurut versi CA-nya.
Tulisan Scott Helme, untuk cara kunci dipulihkan dan apa yang diterima client non-browser.
Kebijakan Chrome Root Program, untuk memahami kenapa sebuah root bisa dicabut pada tanggal tertentu.

Pertanyaan

Kalau satu CA yang kamu andalkan dicabut kepercayaannya besok, bisakah kamu menyebutkan dalam sepuluh menit layanan mana saja yang masih akan mempercayainya?

ICANN87 Hari 5: Saat AI Agent Butuh Nama

Kiell Tampubolon — Wed, 21 Oct 2026 14:00:00 GMT

Seri ICANN87. Sebelumnya: Hari 3 dan Hari 4. Artikel sebelum berangkat: apa yang mau aku cari di Bali.

Di artikel sebelum berangkat, aku menulis satu kalimat yang waktu itu terasa agak nekat: AI agent makin jadi pengguna berat DNS tanpa ada yang sengaja merancangnya begitu, dan aku penasaran apakah komunitas ICANN sudah membahasnya.

Hari kelima menjawab pertanyaan itu. Jawabannya: sudah, dan mereka bergerak lebih cepat dari dugaanku.

09.00, Jakarta B: Open Mic dengan SSAC dan RSSAC

Pagi dimulai di Jakarta B dengan sesi favoritku sepanjang minggu: RSSAC/SSAC Open Mic. Formatnya sederhana. Kedua komite memperkenalkan diri sebentar, lalu mikrofon dibuka untuk siapa saja yang mau bertanya.

Dua komite ini sering tertukar, jadi ini versi singkatnya:

SSAC (Security and Stability Advisory Committee) memberi saran ke Board dan komunitas ICANN soal keamanan dan integritas sistem penamaan dan alokasi alamat internet. Cakupannya luas.
RSSAC (Root Server System Advisory Committee) memberi saran soal operasi, administrasi, keamanan, dan integritas sistem root server. Slide mereka sendiri menulis dengan jujur: “This is a very narrow scope!” Operator root server duduk di dalamnya, tapi RSSAC tidak mengurusi operasi harian.

SSAC menyebut lima topik yang menurut mereka menjadi tumpuan otoritasnya: DNS abuse (yang mereka sebut masalah keamanan paling signifikan di komunitas), gTLD baru, DNSSEC, namespace alternatif, dan internet governance. Lalu ada daftar pekerjaan aktif mereka, dan di urutan pertama tertulis: AI Impacts on DNS SSR and Abuse. Ada satu work party khusus untuk dampak AI terhadap keamanan, stabilitas, dan ketahanan DNS, termasuk abuse.

Aku ambil antrean mikrofon dan bertanya, kurang lebih: kalau AI agent mulai mem-fetch URL dan memanggil tool tanpa manusia mengecek link-nya, apakah itu dilihat sebagai masalah DNS, masalah aplikasi, atau dua-duanya? Jawaban yang aku tangkap: dua-duanya, dan justru karena itulah topik ini sedang dipelajari. Mereka belum mau menyimpulkan sebelum work party-nya selesai. Sikap seperti ini yang aku hormati dari SSAC. Mereka tidak terburu-buru membuat headline.

Fakta kecil yang jarang diketahui: publikasi SSAC diberi nomor urut dengan kode SAC, dan semuanya bisa dibaca gratis. Beberapa yang paling relevan untuk praktisi di Indonesia:

SAC115 tentang DNS abuse, sebagai titik awal kalau kamu mau paham bagaimana komunitas mendefinisikannya
SAC109 tentang DNS over HTTPS dan DNS over TLS
SAC126v2 tentang otomasi record DS DNSSEC (ini nanti nyambung ke sore hari)
SAC135, komentar SSAC atas laporan awal proses kebijakan GNSO tentang mitigasi DNS abuse

Dan kalau kamu ahli DNS, ada jalurnya: RSSAC punya Caucus, kelompok sukarelawan dengan lebih dari 100 pakar DNS yang membantu menyusun publikasi RSSAC, lengkap dengan statement of interest publik dan kredit kerja atas nama masing-masing.

10.30, Jakarta B: Emerging Identifier Technologies

Ini sesi yang membuatku merasa artikel pertamaku tidak salah arah. Deskripsinya dibuka dengan kalimat yang bisa saja aku tulis sendiri: AI agent otonom mulai berinteraksi dengan website dan dengan sesama agent dalam skala besar.

Lalu muncul tiga pertanyaan yang jadi tulang punggung sesi:

Bagaimana sebuah agent menamai dirinya?
Bagaimana ia menemukan agent dan layanan lain?
Bagaimana ia membuktikan identitasnya ke pihak yang diajak berinteraksi?

Ada beberapa upaya yang menjawab pertanyaan ini dengan cara berbeda, dan sesi ini memetakan bagaimana proposal-proposal itu berhubungan dengan DNS. Termasuk pertanyaan yang sangat praktis: apa yang dibutuhkan supaya data agent bisa masuk ke sebuah zona DNS?

Dari sisi security, pertanyaan ketiga yang paling membuatku gelisah. Hari ini, saat aku membangun MCP server atau agent, identitas biasanya urusan token dan URL. Agent percaya pada nama domain yang dia resolve, sama seperti browser. Bedanya, browser punya manusia yang (kadang) curiga. Agent tidak.

Kalau DNS akan jadi lapisan penemuan dan identitas untuk agent, maka semua pelajaran dari Hari 3 dan Hari 4 langsung berlaku ke dunia agent: homograph di nama agent, domain lookalike untuk layanan agent palsu, dan DNSSEC sebagai satu-satunya cara memastikan jawaban DNS tidak diubah di tengah jalan. Masalah lama yang sama, hanya kliennya baru dan jauh lebih cepat.

Ini juga bukan cuma soal teknis. Di sesi yang sama, ada pertanyaan apakah teknologi identifier baru ini nantinya butuh koordinasi seperti yang ICANN lakukan untuk nama domain. Pertanyaan yang belum ada jawabannya, dan karena itulah menarik.

10.30, Nusantara 3: sepuluh tahun PTI

Di jam yang sama, di ruang ccNSO, ada sesi IANA Modernization and 10 Years of PTI. Jadwalnya bentrok, jadi aku menonton rekamannya malam harinya. Untungnya hampir semua sesi publik ICANN direkam.

Konteksnya: pada 1 Oktober 2016, pengawasan fungsi IANA berpindah dari pemerintah Amerika Serikat ke komunitas multistakeholder global. Sejak itu fungsi IANA dijalankan oleh PTI (Public Technical Identifiers), afiliasi ICANN. PTI mengurus tiga hal: root zone untuk nama domain, blok alamat IP dan nomor AS untuk para RIR, serta registry parameter protokol untuk IETF. Sesi ini sekaligus merayakan sepuluh tahun transisi itu dan memamerkan perbaikan cara fungsi-fungsi IANA dijalankan.

Fakta paling unik yang aku bawa dari sini: kunci paling penting di DNS dijaga lewat upacara. Kunci KSK root, kunci di puncak rantai kepercayaan DNSSEC, dipakai dalam key signing ceremony yang dijadwalkan rutin di dua fasilitas aman di Amerika Serikat. Upacaranya disiarkan langsung, diaudit, dan melibatkan Trusted Community Representatives, sukarelawan dari berbagai negara yang memegang bagian akses. Kunci itu juga pernah diganti: rollover KSK root pertama terjadi pada 11 Oktober 2018. Kalau kamu mengajar DNSSEC dan muridmu bertanya “siapa yang menjaga kunci paling atas?”, jawabannya ternyata jauh lebih menarik dari “ICANN”.

13.15, Jakarta A: duduk di depan Board

Siangnya, peserta Fellowship dan NextGen@ICANN bertemu dengan anggota Board ICANN dan Presiden sekaligus CEO ICANN, Kurtis Lindqvist. Ruangan Jakarta A yang biasanya penuh slide teknis kali ini penuh pertanyaan dari peserta muda dari berbagai negara.

Yang aku catat bukan jawaban spesifiknya, tapi polanya. Pertanyaan yang paling didengarkan bukan yang paling pintar, tapi yang paling konkret: datang dengan masalah dari negara sendiri, lalu bertanya proses apa yang ada untuk itu. Pelajaran ini akan aku bawa ke paper untuk PANDI. Bukan “DNS abuse itu penting”, tapi “ini yang terlihat dari inbox defender di Indonesia, dan ini celah prosesnya”.

Sore, Jakarta B: workshop DNSSEC yang jujur

Sesi terakhir yang aku ikuti adalah DNSSEC and Security Workshop, tiga sesi berturut-turut yang diselenggarakan SSAC. Kalau kamu cuma bisa datang ke satu sesi teknis di ICANN Meeting, mungkin ini yang paling layak. Isinya praktisi yang berbagi praktik operasional, tantangan yang mereka temui, dan strategi pengelolaannya.

Satu benang merah yang terus muncul: DNSSEC jarang gagal karena kriptografinya. Ia gagal karena manusianya lupa satu langkah. Kasus klasiknya, pemilik domain pindah provider DNS, kunci di zona baru berganti, tapi record DS di parent masih menunjuk kunci lama. Hasilnya, setiap resolver yang memvalidasi akan menganggap domain itu palsu, dan domain itu “hilang” justru untuk pengguna yang paling aman.

Solusinya sudah ada sejak lama: record CDS dan CDNSKEY (RFC 7344 dan RFC 8078) yang membuat zona anak bisa memberi sinyal ke parent untuk memperbarui DS secara otomatis. Ini yang dibahas SSAC di SAC126v2. Masalahnya adopsi: registry, registrar, dan operator DNS harus sama-sama mendukung.

Ini cara cepat untuk memastikan domainmu tidak sedang berada dalam kondisi itu:

# Validasi penuh dari root sampai domainmu (delv ada di paket bind-utils / bind9-dnsutils)
delv contoh.id A
# "; fully validated" = rantai aman. Pesan error = ada yang putus.

# Bandingkan DS di parent dengan DNSKEY di zonamu
dig +short DS contoh.id
dig +short DNSKEY contoh.id
# Key tag di DS harus cocok dengan salah satu KSK (flag 257) di DNSKEY.

# Zonamu sudah memasang CDS untuk otomasi?
dig +short CDS contoh.id

Menengok lagi artikel pertama

Sebelum berangkat, aku menulis tiga hal yang mau aku cari di Bali. Ini hasilnya setelah lima hari:

DNS abuse dari sisi kebijakan. Aku datang dengan pandangan dari inbox. Aku pulang dengan pemahaman bahwa kata “abuse” punya definisi, ada survei untuk ccTLD, ada data terbuka seperti DAAR, dan ada perdebatan serius soal batas antara mencurigakan dan terbukti. Bagian ini akan jadi inti paperku untuk PANDI.
DNSSEC di deployment nyata. Jawabannya ternyata bukan soal kriptografi, tapi soal disiplin operasional dan otomasi DS. Akhirnya aku punya jawaban untuk murid-muridku yang bukan dari buku teks.
AI agent sebagai klien DNS. Firasatku ternyata bukan firasat sendirian. SSAC punya work party-nya, dan ada satu sesi penuh tentang identitas agent. Ini akan jadi tulisan terpisah, seperti yang aku janjikan.

Satu hari lagi tersisa di Nusa Dua. Setelah itu, bagian yang paling susah dimulai: mengubah lima hari catatan jadi paper, materi kelas, dan tulisan yang berguna buat orang yang tidak sempat datang.

Kalau kamu bekerja di titik temu AI agent dan DNS, atau sedang menyiapkan DNSSEC untuk domain .id-mu dan mentok, kabari aku. Aku masih yang paling banyak nyatet.

ICANN87 Hari 4: Dari Aksara Bali sampai Root Server

Kiell Tampubolon — Wed, 21 Oct 2026 13:00:00 GMT

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

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.
Standar internet dibuat oleh siapa saja yang mau datang dan menulis. IETF tidak punya keanggotaan formal. Aku yang dari Batam juga bisa ikut.
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.

ICANN87 Hari 3: Internet yang Diukur, Bukan Ditebak

Kiell Tampubolon — Wed, 21 Oct 2026 12:00:00 GMT

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

Keamanan DNS lebih sering soal disiplin operasional daripada soal penyerang canggih. Sebagian besar cerita gangguan yang aku dengar berawal dari perubahan rutin.
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.
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”.

Dari Pelatih Keamanan DNS ke Fellow ICANN87: Apa yang Dicari Seorang Insinyur Keamanan Siber di Bali

Kiell Tampubolon — Thu, 15 Oct 2026 00:00:00 GMT

Juli 2024, aku duduk di ruang training di Nusa Dua dengan laptop dan diagram DNS yang kebanyakan. PANDI, pengelola domain .id, sedang menjalankan program Training of Trainer, dan beberapa instrukturnya datang dari ICANN. Kami mulai dari “bagaimana sebuah nama berubah jadi alamat IP” dan berakhir di tanda tangan DNSSEC serta chain of trust. Aku pulang bawa satu buku catatan penuh coretan, dan satu kebiasaan yang masih nempel sampai sekarang: tiap lihat link phishing, otomatis kepikiran siapa yang daftarin domain itu, dan kapan.

Minggu depan aku balik lagi ke pantai yang sama. ICANN87, Annual General Meeting ICANN, berlangsung 17 sampai 22 Oktober 2026 di Bali International Convention Centre, Nusa Dua. Kali ini aku datang sebagai salah satu fellow PANDI.

Excited banget, sampai tingkat baca jadwal sesi buat hiburan. Jadi sebelum berangkat, aku mau tulis dulu apa yang mau aku pelajari dan apa yang mau aku kasih balik, biar nanti bisa dicek lagi setelah acara selesai.

ICANN87, 17-22 Oktober 2026, Nusa Dua, Bali

Buku alamat internet punya rapat tahunan

Kebanyakan murid di kelasku belum pernah dengar ICANN, dan itu wajar. Tiap kali buka website, kirim email, atau kasih AI agent fetch sebuah URL, ada sistem yang mengubah nama jadi alamat. Itu DNS. ICANN mengoordinasikan bagian paling atas dari sistem itu: root zone, aturan untuk top-level domain, dan kebijakan yang menentukan bagaimana nama domain dibagikan serta apa yang terjadi kalau disalahgunakan.

Bagian yang bikin aku kaget waktu pertama kali tahu adalah siapa yang nulis aturan-aturan itu. Bukan satu perusahaan atau satu pemerintah saja. Pemerintah, registry seperti PANDI, registrar, penasihat keamanan, sampai pengguna internet biasa, semuanya punya kursi, dan semuanya dibahas di rapat terbuka. ICANN87 adalah salah satu rapat itu, dan Annual General Meeting ini yang paling besar sepanjang tahun.

Disederhanakan: siapa mengurus lapisan DNS yang mana, dan siapa yang bikin aturannya

Dari mana aku berangkat

Aku bukan orang kebijakan. Kerjaan sehari-hariku security engineering, dan banyak di antaranya ada di ujung penerima masalah DNS. Kalau ada email mencurigakan masuk, hal pertama yang aku cek adalah domain pengirimnya. Umurnya berapa? Niru brand asli dengan satu huruf diganti nggak? Bulan lalu domainnya ada apa nggak? Lookalike domain itu bagian besar dari phishing yang aku triage sehari-hari, jadi aku banyak berurusan dengan sisi penyalahgunaan DNS tanpa pernah lihat langsung bagaimana orang yang mengurusnya berpikir soal masalah ini.

Di luar kerjaan, aku jadi trainer .id Academy PANDI sejak 2024, ngajar bootcamp di UNIMA Manado dan ITEBA Batam. Isi kelasnya campuran: mahasiswa, dosen, sampai orang yang baru beli domain .id buat usaha kecilnya. Dan belakangan, bagian yang makin besar dari kerjaanku adalah keamanan AI agent dan MCP, yang ternyata balik lagi ke DNS dengan cara yang nggak aku duga. Agent yang browsing atau manggil tool juga resolve nama domain, dan dia percaya jawabannya persis seperti browser, seringkali tanpa ada manusia yang ngecek link-nya dulu.

Dua tahun dari kelas DNS di Nusa Dua ke ICANN87 di Nusa Dua

Apa yang aku cari di Bali

Pertama, DNS abuse dari sisi kebijakan. Aku tahu bentuk abuse di inbox. Tapi aku belum terlalu paham bagaimana registry dan registrar memutuskan sesuatu dianggap abuse, seberapa cepat mereka diharapkan bertindak, dan di mana letak susahnya, misalnya soal false positive atau nge-takedown domain yang ternyata sah. Aku mau dengar langsung argumen itu dari orang yang menghadapinya tiap hari.

Kedua, DNSSEC di deployment nyata. Waktu ToT dulu kami belajar bagaimana DNSSEC menandatangani jawaban DNS supaya resolver bisa tahu kalau ada yang mengutak-atik di tengah jalan. Pertemuan ICANN biasanya ada workshop DNSSEC dan security, dan aku mau dengar cerita dari operator soal apa yang rusak di lapangan. Muridku suka nanya hal ini, dan sejauh ini aku cuma punya jawaban dari buku teks.

Ini jenis pengecekan yang aku mau setiap murid bisa jalankan sendiri di domainnya:

# Zonenya sudah ditandatangani? Kalau ada record RRSIG di jawabannya, berarti sudah.
dig +dnssec SOA .

# Resolver-ku validasi nggak? Cek flag "ad" di header-nya.
dig +dnssec icann.org A

Ketiga, AI agent sebagai klien DNS. Yang ini lebih ke firasat daripada rencana. Agent makin jadi pengguna berat DNS tanpa ada yang sengaja merancangnya begitu. Aku penasaran apakah komunitas ICANN sudah membahas ini, dan kalau belum, apakah ada paper yang bisa ditulis dari situ.

Apa yang mau aku kasih balik

PANDI minta setiap fellow mengubah pengalaman seminggu ini jadi kontribusi, ditulis sebagai paper. Aku suka format ini. Ada deliverable yang jelas di ujung minggu, dan aku kerja lebih bagus kalau ada target konkret. Rencana kasarnya berbentuk loop: dengerin, hubungkan sama apa yang aku lihat di kerjaan, tulis buat PANDI, ubah jadi materi .id Academy, lalu publikasikan bagian terbukanya di sini.

Rencana untuk satu minggu ini, dan apa yang terjadi setelahnya

Topik papernya belum final. Aku condong ke titik temu dua duniaku: bentuk DNS abuse dari sudut pandang inbox seorang defender, dan apa yang realistis bisa dilakukan pemilik domain serta trainer Indonesia soal itu. Kalau thread AI agent ternyata cukup kuat, itu bisa jadi tulisan terpisah.

Bagian kelas yang paling penting buatku. Waktu ngajar di Manado atau Batam, murid jarang nanya soal root server. Mereka nanya cara mengenali link aman, atau harus gimana kalau ada yang bikin tiruan website kampusnya. Kalau aku bisa balik ke kelas-kelas itu dengan jawaban yang lebih baik, lengkap dengan nama orang dan proses yang menangani masalah ini, minggu ini sudah sepadan.

Kalau kamu juga di sana

Kalau kamu ada di ICANN87, baik di Nusa Dua atau online, dan kerjaanmu soal DNS abuse, DNSSEC, atau apa pun titik temu AI agent dengan DNS, aku mau ngobrol. Aku bakal jadi yang paling banyak nyatet. Nanti aku tulis lagi apa yang aku pelajari setelah acaranya selesai, termasuk kalau ternyata ada yang salah di tulisan ini.