ICANN87 Hari 5: Saat AI Agent Butuh Nama

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:

1. Bagaimana sebuah agent menamai dirinya?
2. Bagaimana ia menemukan agent dan layanan lain?
3. 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:

1. 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.
2. 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.
3. 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.