From DNS Security Trainer to ICANN87 Fellow: A Security Engineer's Bali Agenda

The Internet's Address Book Is About to Convene

Most people have never heard of ICANN. Every time you open a website, send an email, or let an AI agent fetch a URL, a name has to be translated into an address first—and that system is DNS. ICANN coordinates the topmost layer of this system: the root zone, the rules for top-level domains, and the policy-making work that determines how names are allocated and how abuse is dealt with.

What really surprised me is who writes these rules. It isn't a single company or government calling the shots—governments, registries like PANDI, registrars, security consultants, and ordinary internet users each hold a seat, negotiating in public meetings. ICANN87 is one of those meetings, and the Annual General Meeting is the largest of the year.

According to a cybersecurity engineer who has long served as a trainer at PANDI's (the registry operating Indonesia's .id domain) .id Academy, he will attend ICANN87 as a PANDI Fellow at the Bali International Convention Center in Nusa Dua.

DNS (Domain Name System) is essentially a distributed, hierarchical database that translates human-readable domain names (like example.com) into machine-routable IP addresses. It starts from the root zone and descends through top-level domains (TLDs like .com, .id), second-level domains, and finer subdomains, with each layer independently managed by different organizations—forming what's called a "delegation" structure. Because of this layered design, DNS has no single point of control, which means no single company or government can dictate it alone. Founded in 1998, ICANN operates as a nonprofit that plays a "coordination" rather than "control" role—it doesn't own DNS, but maintains authoritative root zone data, sets TLD policy, and hosts multistakeholder consultation processes. ICANN's Annual General Meeting is usually held alongside a policy forum or community week, making it the most concentrated venue for global domain policy discussions.

My Starting Point: A Defender's Inbox

I'm not a policy person. My day job is security engineering, and most of my time is spent on the receiving end of DNS problems. When a suspicious email comes in, the first thing I look at is the sender's domain: how long has it been registered? Is it a real brand with one letter swapped? Did it exist last month? Lookalike domains are a major part of how I handle phishing attacks, so I've spent a lot of time on the abuse side of DNS—yet I've never seen how the operators think about the problem.

Outside of work, I've been a trainer at PANDI's .id Academy since 2024, running bootcamps at UNIMA in Manado and ITEBA in Batam. My students include students, lecturers, and people who just bought a .id domain for a small business. Lately, a growing part of my job is AI agents and MCP security, which has brought DNS back in a way I didn't anticipate. An agent that browses the web or calls tools also resolves domain names, trusts answers the same way a browser does, and often has no human glancing at the link first.

MCP (Model Context Protocol) is a relatively recent open protocol for letting AI models connect to external tools, data sources, or services in a standardized way. Think of it as a "plug standard for AI agents": through MCP servers, agents can call search, databases, file systems, and other capabilities without writing separate integration code for each tool. From a security perspective, MCP introduces a new class of problems—agents make network requests in pathways the user can't see, including DNS resolution. Attackers could return tampered results through a malicious MCP server, or lure an agent to a lookalike domain. Since agents typically don't "glance at the link first" the way humans do, DNS-level phishing and domain impersonation may be more insidious threats to agents than to human users—one reason the author focuses on the intersection of AI agents and DNS.

What I Want to Find in Bali

DNS abuse from the policy side. I know what abuse looks like in an inbox, but I know very little about how registries and registrars define abuse, how quickly they must respond, and where things get thorny (false positives, or taking down a domain that's actually legitimate). I want to hear how the people who deal with this daily argue about it.

DNSSEC in real deployment. In train-the-trainer sessions we learned how DNSSEC signs DNS responses so resolvers can tell if someone tampered with them. ICANN meetings usually have DNSSEC and security workshops, and I want to hear operators talk about where things break in practice. My students have asked me this, and right now I only have textbook answers.

I've prepared a set of check commands students can run against their own domains:

DNSSEC solves a fundamental DNS flaw through digital signatures: traditional DNS responses have no integrity verification whatsoever, so a man-in-the-middle can forge responses and steer users to malicious addresses (cache poisoning). With DNSSEC enabled, a zone generates an RRSIG signature for each record, and resolvers verify signatures along the chain of trust (from the root zone's trust anchor downward step by step), only setting the AD (Authenticated Data) flag in the response header if verification passes. However, DNSSEC has quite a few pain points in real deployment: complex key rotation operations, expired algorithms (like early SHA-1 signing schemes), DS record synchronization delays between some registrars and registries, and older resolvers that don't support validation—all of which can cause a domain to be "signed but not working" or falsely flagged as insecure. For this reason, operators' frontline experience is often more valuable than textbooks.
# Is the zone signed? An RRSIG record in the response means it is.
dig +dnssec SOA .

# Will my resolver validate? Check the header for the "ad" flag.
dig +dnssec icann.org A

AI agents as DNS clients. This is more of a hunch than a plan. Agents are becoming heavy DNS users, and nobody decided this on purpose. I'm curious whether the ICANN community is already discussing it; if not, whether this could make a useful paper.

What I Want to Bring Back

PANDI requires each Fellow to turn the week into a contribution, written up as a paper. I really like this arrangement—it gives the week a deliverable, and I function better when I have one. My rough plan is a loop: listen, connect what I hear to what I see at work, write it up for PANDI, turn it into .id Academy teaching materials, and publish whatever can be made public.

The paper title isn't decided yet. I lean toward where the two worlds overlap: what DNS abuse looks like from a defender's inbox, and what Indonesian domain holders and trainers can realistically do. If the AI agent thread holds up, it might become its own piece.

The classroom part matters most to me. When I teach in Manado or Batam, students rarely ask about root servers. They ask how to tell if a link is safe, or what to do when someone makes a fake copy of their campus website. If I can walk back into those classrooms with better answers—and can name the people and processes that handle these problems—the week will have been worth it.

PANDI (Pengelola Nama Domain Internet Indonesia) is the registry for Indonesia's country-code top-level domain .id, responsible for allocating .id and its subdomains, making policy, and building the local internet community. It also runs .id Academy, which offers public training on domains, DNS, and cybersecurity, and partners with universities and regional institutions to hold bootcamps. Being a .id Academy trainer means the author sits at the intersection of "technology—education—policy": he must understand the operational details of the domain name system and translate that knowledge into language students and small business owners can use. This dual role lets him observe issues from both a policy participant's and a local trainer's perspective when attending ICANN meetings, and turn meeting content into practical teaching materials.

If You'll Be There Too

If you'll be at ICANN87 in person or online, and you work on DNS abuse, DNSSEC, or anything at the intersection of AI agents and DNS, I'd like to talk. I'll be the one taking too many notes. After the meeting I'll publish what I learned, including where this post got things wrong.

One-line Summary

A DNS security engineer attends ICANN87 as a PANDI Fellow, focusing on abuse policy, DNSSEC deployment, and AI agents' DNS security issues.

Paragraph Summary

Writing in first person as an Indonesian DNS security engineer, the author recounts attending the ICANN87 Annual General Meeting as a PANDI Fellow. His day job involves handling phishing emails and lookalike domains—he sits on the "abuse receiving end" of DNS—and he hopes to understand from the policy and operational side how abuse is defined and handled. He focuses on three areas: how registries and registrars define and respond to DNS abuse, problems with DNSSEC in real deployment, and the security blind spots created by AI agents as a new kind of DNS client. PANDI requires Fellows to write up their meeting takeaways as a paper, and the author plans a loop of "listen—connect—write—teach—publish," ultimately bringing answers back to classrooms in Manado and Batam.