從 DNS 安全培訓導師到 ICANN87 Fellow：網絡安全工程師在峇裏島希望瞭解甚麼

In July 2024 I sat in a training room in Nusa Dua with a laptop and too many DNS diagrams. PANDI, the registry that runs Indonesia's .id domain, was running a Training of Trainer program, and some of the instructors came from ICANN. We started at "how does a name turn into an IP address" and ended at DNSSEC signatures and chains of trust. I went home with a notebook full of drawings and a habit I still have: I can't look at a phishing link anymore without wondering who registered that domain, and when.

Next week I'm going back to the same stretch of coast. ICANN87, ICANN's Annual General Meeting, runs from 17 to 22 October 2026 at the Bali International Convention Centre in Nusa Dua, and I'll be there as one of PANDI's fellows.

I'm excited about it, the kind of excited where you read meeting schedules for fun. So before I land, I want to write down what I hope to learn and what I want to give back, and check myself against it afterwards.

The internet's address book has a meeting

Most people in my classes have never heard of ICANN, and that's fine. Every time you open a website, send an email or let an AI agent fetch a URL, something has to turn a name into an address. That something is DNS. ICANN coordinates the top of that system: the root zone, the rules for top-level domains, and the policy work that decides how names are handed out and what happens when they're abused.

The part that surprised me when I first learned it is who writes those rules. No single company or government does. Governments, registries like PANDI, registrars, security advisors and ordinary internet users each have a seat, and they work things out in open meetings. ICANN87 is one of those meetings, and the Annual General Meeting is the biggest one of the year.

Simplified: who runs which layer of the DNS, and who shapes the rules

Where I'm coming from

I'm not a policy person. My day job is security engineering, and a lot of it happens at the receiving end of DNS problems. When a suspicious email comes in, one of the first things I look at is the sender's domain. How old is it? Does it copy a real brand with one letter swapped? Did it even exist last month? Lookalike domains are a big part of the phishing I triage, so I've spent a lot of time on the abuse side of the DNS without ever seeing how the people who run it think about the problem.

Outside work, I've been a .id Academy trainer with PANDI since 2024, running bootcamps at UNIMA in Manado and ITEBA in Batam. The rooms are a mix of students, lecturers and people who just bought a .id domain for their small business. And these days a growing part of my work is AI agent and MCP security, which brings DNS back in a way I didn't expect. An agent that browses or calls tools resolves domain names too, and it trusts the answer the same way a browser does, often with no human looking at the link first.

Two years from a DNS classroom in Nusa Dua to ICANN87 in Nusa Dua

What I'm looking for in Bali

First, DNS abuse from the policy side. I know what abuse looks like in an inbox. I know much less about how registries and registrars decide what counts as abuse, how fast they're expected to act, and where it gets hard, like false positives or taking down a domain that turns out to be legitimate. I want to hear that argument from people who deal with it every day.

Second, DNSSEC in real deployments. In the ToT we learned how DNSSEC signs DNS answers so a resolver can tell if someone tampered with them. ICANN meetings usually include a DNSSEC and security workshop, and I want operators' stories about what breaks in practice. My students ask me that question and right now I only have textbook answers.

Here's the kind of check I want every student to be able to run on their own domain:

# Is the zone signed? RRSIG records in the answer mean yes.
dig +dnssec SOA .

# Does my resolver validate? Look for the "ad" flag in the header.
dig +dnssec icann.org A

Third, AI agents as DNS clients. This one is a hunch more than a plan. Agents are turning into heavy DNS users without anyone deciding that on purpose. I'm curious whether people in the ICANN community are already talking about it, and if they aren't, whether there's a useful paper in it.

What I want to give back

PANDI asks each fellow to turn the week into a contribution, written up as a paper. I like that a lot. It gives the week a deliverable, and I work better with 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 material, and publish the open parts here.

The plan for the week, and what happens after it

I haven't locked the paper topic yet. I'm leaning toward the place where my two worlds overlap: what DNS abuse looks like from a defender's inbox, and what Indonesian domain owners and trainers can realistically do about it. If the AI agent thread turns out to have legs, that could 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 rooms with better answers, and with names of the people and processes that handle these problems, the week will have been worth it.

If you'll be there

If you're at ICANN87, in Nusa Dua or online, and you work on DNS abuse, DNSSEC or anything where AI agents meet the DNS, I'd like to talk. I'll be the one taking too many notes. I'll post what I learn after the meeting, including whatever this post got wrong.