DNS blocking, registration data and AI with Christian Dawson (i2Coalition)

You type a domain into a browser and a website loads. That is what the DNS does, and it works so well that few people ask what sits behind it: technical standards, commercial contracts, governance bodies and years of human decisions.

These decisions carry more weight every year. Governments are intervening more and more at the digital infrastructure layer. Copyright enforcement, online safety, gambling rules and cybersecurity law all arrive at the same place: a domain can be suspended or made to stop resolving, and a registrar can be ordered to act. Meanwhile, AI is changing who operates that infrastructure. Crawlers account for a large share of web traffic, and agents are starting to register domains, configure DNS records and deploy services without a human approving each step.

Christian Dawson has spent his career in this space. He is Co-Founder and Executive Director of the i2Coalition, the Internet Infrastructure Coalition, which represents hosting companies, data centers, registrars, registries and cloud providers in public policy. Before that he spent 16 years as an executive at web hosting provider ServInt, where he co-founded the Save Hosting initiative during the SOPA and PIPA debates.

Read on for our conversation with Christian on DNS blocking, registration data, AI crawlers and the policies impacting the internet infrastructure.

1. You co-founded the i2Coalition. What made you decide the industry needed a voice in policy rooms, and what surprised you most about how those rooms actually work?

I came to policy from operations. I spent 16 years helping run ServInt, a hosting company that grew up alongside the commercial internet. My world was keeping infrastructure running and serving customers. Public policy was not part of my job at that time.

That changed around 2010, when the United States began considering legislation on online copyright infringement that would have given the government new powers to act against websites. This included interventions involving domains and the DNS. For those of us operating the internet infrastructure, these were not abstract debates. We could see how the mechanisms would work technically, and we could see consequences that were not obvious from inside the policy process.

This created a structural problem: decisions about internet infrastructure were being made without involving those people who actually built it and operated it. So in 2012, I created the i2Coalition with David Snead, an attorney who worked with hosting companies, so the industry would have a permanent voice rather than assembling one every time a threat appeared.

What I know for sure is that policymakers are not trying to break the internet. They want to solve real problems: piracy, fraud, child protection, cybersecurity, illegal content. The problem is that the internet looks like a homogenous and effective place to enforce a policy solution, but it is not. Our role goes beyond simply opposing regulation. To policymakers we say: we understand the outcome you want, but now look at what happens technically if you apply this change.

2. DNS blocking was one of the mechanisms proposed with SOPA and PIPA, and the one that showed most clearly what was at stake technically. Fifteen years later, it is back in play in Europe. What did the industry win in 2012, and what is different today?

Let me broaden the premise a little. SOPA and PIPA were not only about DNS blocking, but the proposed interference with the DNS was what made the consequences clear to our community.

What we won was not a promise that governments would never touch the DNS, because that is obviously not where the world ended up. What lasted was the principle that the architecture of the internet has to matter when you design enforcement policy.

If a government decides that content is unlawful, making the domain stop working looks like a direct solution. But other questions follow. At what layer is the problem occurring, and at what layer is the intervention? What else depends on the affected infrastructure, and what happens to lawful users? Those questions matter more today, because more layers and more providers can serve as enforcement points. Any single intervention looks reasonable if you consider only the problem it is meant to solve.

The difficulty is that the internet is global in ways that law generally isn’t.

A government can regulate conduct inside its own borders, but the infrastructure carrying that policy serves users far beyond. Providers do have responsibilities, including for abuse of their services, but responsibility should match capability and remedies should fit both the harm and the layer they land on.

Internet infrastructure as an enforcement point

3. Domain registration data is another critical point: who the registrant is, which third parties can ask for data, how accurate the record has to be. Between ICANN’s disclosure processes and the pressing obligations in European law, is the current situation working for anyone?

Registration data is difficult because many legitimate objectives have to coexist. There are good reasons to want reliable information behind a domain registration, and cases where law enforcement, security researchers or rights holders need access to what is not public. There are also legitimate privacy obligations, and good reasons not to keep a public database of personal information simply because someone registered a domain.

The GDPR forced the domain community to change. Before it, much of the ecosystem assumed most registration data could be published through WHOIS. Once that assumption collapsed, we had to separate questions: what a registrar should collect, how reliable it needs to be, what stays private, and who can request what is not published.

I do not think we should recreate the old WHOIS. Nor should we accept systems where legitimate requests meet unpredictable processes, or where registrars are expected to verify more than they actually can. Here the scale matters too: a requirement designed around a very large company can mean an entire new operational system for a small registrar, and good policy should not make scale a prerequisite for compliance. There is probably no answer that will satisfy everyone.

4. The i2Coalition set up the Ethical Web Data Collection Initiative, which develops standards for large-scale collection of public web data. AI crawlers are now a big part of web traffic. Was that groundwork enough, and what is still missing between the websites being crawled and the companies doing the crawling?

We did not create the Ethical Web Data Collection initiative because we predicted the generative AI boom. It emerged because there was already a governance gap around large-scale collection of public web data. Companies were collecting enormous amounts of information for legitimate commercial and research purposes, while website operators were trying to control automated access. Abusive scraping made it harder to distinguish responsible collection from behavior that damaged websites.

Generative AI made that problem bigger and much more visible. The idea behind the initiative has held up: information being public does not mean there are no rules about how you collect and use it. We are now moving from principles to verification, because a trust framework only works if it can show that participants really follow the rules they agreed to.

The technical gap is still there. A website can see heavy automated traffic and have no reliable way of knowing who runs the crawler or what it is collecting. For the crawler operator the problem is reversed: a responsible collector looks much like a malicious bot. Neither side has good tools for proving anything to the other.

What this work needs next is better machine-readable communication on both sides. Website operators need a way to state what they allow, and collectors need a reliable way to identify themselves and say what they are collecting the data for. On the other side of that gap is an opportunity for domains and DNS to become important signals that AI systems can use in determining what to trust.

At the moment the only real options are to trust every crawler or to block all automated access. The web needs something better than that. AI did not create this problem. It made leaving it unsolved more expensive.

5. Agentic AI now acts on infrastructure, registering domains, and configuring DNS without a human approving each step. What does accountability look like when the responsible person is several steps away from the action?

I would frame this less around whether software becomes the registrant and more around what happens when software starts making decisions for a person or a company. An AI agent can register a domain, set up DNS, buy infrastructure, deploy an application and pay for things. Software could already do most of that.

What really changes with agentic systems is the scale, how little supervision there is, and how far the action sits from whoever is answerable for it.

That leads to one question: on whose authority is the agent acting? Most accountability on the internet assumes that behind any action there is a person or a company you can identify and hold responsible. Agentic systems put several layers between the two. So other systems need a way to work out who an agent represents, what it has been authorized to do, whether that authorization is real and still valid, and who answers if it goes wrong.

We need lasting ways to handle identity, permission and delegation that hold up between different companies and different technical systems. The DNS is interesting here because it already connects a domain, anywhere in the world, to the party that administers it. That does not make it an identity system for AI agents, but it could be one piece of the puzzle, alongside cryptographic identity and verifiable credentials. The open question is how those pieces fit together, so that an AI agent can show who it represents and what it is allowed to do.

Neither the policy world nor the technical one has a full answer yet. Once autonomous systems are running infrastructure at scale, adding accountability afterwards will be far harder than building it in now.

See also: the domain name’s new role in the AI web, on how domains could become part of the identity and trust layer of an AI-mediated internet.

6. Your members span hosting, registrars, registries and cloud. Where do they agree on what needs to change in internet governance, and where do they disagree?

One problem that keeps coming back in internet policy is the habit of treating “internet company” as though it described something exclusively technical. It does not.

A registrar, a registry, a hosting provider, a cloud platform and a data center may all play a part in delivering the same service, but they sit at different points in the chain. They see different information, control different systems, and may not even know who else is involved. So when a policy says that “internet companies” should do something, the first question is which of them is actually in a position to do it, and what else happens when they do.

Among our members at the i2Coalition there is wide agreement on a few things: that responsibility should sit with whoever can actually act, that due process matters, that remedies should be proportionate, and that internet infrastructure should not become the default place to enforce a rule simply because it is easy to reach.

The differences show up when those principles turn into concrete obligations. A registrar may see one part of an abuse problem and a hosting provider another. A very large cloud provider may be able to do things that are out of reach for a small regional one.

What problem are we actually solving? Where is the harm happening, and who at that point can do something about it? What response is proportionate, and what happens to legitimate users when it is applied? For example, the NIS2 Directive is built on important goals around security and resilience, but the same obligation lands very differently depending on the size and resources of the company that has to meet it.

So what we agree on is usually a way of working rather than a single rule.

7. Looking three to five years ahead, what shift in DNS and domain governance should people be watching, and for a business without a policy team, where should it start?

Two things are happening at the same time. Governments are getting more comfortable stepping in at the infrastructure layer, and software is starting to act on that same infrastructure. Over the next few years the two will meet. Autonomous systems will register domains and set up infrastructure on a much larger scale, while governments ask providers to take on more responsibility for spotting bad actors and enforcing public policy.

There is a second change specific to this industry. You can no longer follow internet governance by watching ICANN alone. ICANN still matters enormously, and companies here need someone paying attention to its work. But decisions that affect how domains and the DNS actually run are now also made in European institutions, national parliaments, courts, cybersecurity authorities and data protection offices.

For most companies, the advice is far simpler: know who really controls your domains. Organizations are often surprised, usually in the middle of an emergency, to find that a former employee, an outside developer or a supplier nobody remembers still holds the keys to a critical domain account. Treat domains and DNS the way you treat any other security infrastructure: strong authentication, account and recovery details kept current, and a clear picture of who runs the services you depend on. Then make it someone’s job to monitor domains and see what is happening around those services. That does not mean hiring a policy team, but the company should know which providers, trade associations and experts to listen to when something changes.

Internet infrastructure has the odd quality that it becomes invisible when it works. You type a domain, a page appears, and you never think about the standards, the commercial agreements, the governance bodies and the human decisions that made it happen. I have spent most of my career inside that invisible layer, and the clearest lesson it has taught me is that we should not wait for infrastructure to stop working before we decide it matters.