An AI agent sets up DNSSEC on Google Cloud DNS, start to finish

0:00Cold open: Secure

Two brand-new domains, and one word beside every check on the screen: Secure. An AI agent put both domains on Google Cloud DNS, signed them with DNSSEC, and proved the chain of trust from the outside, with a public checker. It did nearly all of it from the command line. The steps it was not allowed to do are part of the lesson. Here is how it went, in the words I said while it was happening.

0:28The job

The job started where the last session stopped. The show's cloud project already existed, with its budget and its borrowed identity. Next came the domains. In my words at the time: we'll have to move them over to Google DNS as the authoritative name servers, and fortify them with all the resource records that are necessary. Authoritative means the servers that hold the official answer for a domain. Every other resolver on the internet asks them, or asks something that asked them.

I typed one request: we're in the middle of a project with multiple phases, check our progress in this folder, what's next? The agent read its own notes and found the phase. The zone.

1:16Two zones, signing on

First, one managed zone per domain: the dot com, and the dot tv. A managed zone is Google's copy of a domain's records, served from Google's name servers. The agent created each one with a single command, with DNSSEC switched on at creation. That one setting has Cloud DNS generate the signing keys and sign every record in the zone. Then the agent read back the name servers Google had assigned. Both zones landed on the same set of four. But nothing points at those four yet. The internet still asks the registrar's default servers, until the registrar is told otherwise.

2:01Where the agent stops

And the registrar is where this agent stops. The registrar account is personal. It holds other domains besides these two, so it never appears on screen, and by the plan it is not this agent's to touch. So the agent wrote the four name servers into a request file for a second agent, the one that works for the admin account, and it stopped. Stop reached, by design. As I said then: that's essentially the super admin for this whole organization. The agent on camera is a subset of that.

Some things have to be done at the super user level, and we don't film that part.

2:42Off camera: the name servers

Here is what happened off camera, from the other agent's own record. It drove the registrar in my browser, opened only the two show domains, and showed me the four values before every save. I said yes to each one. The first save on the dot com didn't take: the page was reloading underneath it. The agent reopened the editor, saw the old defaults still there, typed the values again, and saved. Then it checked the reopened editor, not the success message.

3:15Proof one: the delegation

Back on camera, I told the agent the other side was done, and it ran its first proof. Two questions, from two directions. Ask the public resolvers who serves these domains. Then ask one of the new Google name servers directly for the zone's start-of-authority record, the record every zone answers for itself. Both domains pointed at the four Google name servers, and both zones answered. The dot tv had caught up already, ahead of a caching warning from the other side. As I put it: the domains are working properly in their delegation.

Not too bad of a refresh on the cache time. One honest detail: the plan's proof commands used dig, which isn't installed on this Windows machine. The agent used nslookup instead, got the same facts, and logged the swap.

4:10The keys, by the numbers

Delegation says who answers. DNSSEC proves the answers weren't forged along the way. For that, the parent zone, dot com or dot tv, has to publish a fingerprint of the zone's key-signing key. That fingerprint is the DS record, short for delegation signer, and only the registrar can hand it to the registry. So the agent pulled four values per zone from Cloud DNS: the key tag, the algorithm, the digest type, and the digest itself. One catch: the command line reports the algorithm by name, and registrar forms want a number.

The agent translated both, eight and two, and wrote down both forms so the other side could check. And the request said, in so many words: enter the values themselves. Never the registrar's DNSSEC toggle.

5:04Off camera: never the toggle

There's a reason for that line. On this channel's own domains, a registrar's one-click DNSSEC switch once created a key of its own, one that matched nothing in the zone, and the domain stopped resolving for anyone whose resolver checks signatures. It was fixed by deleting that record and entering the real values by hand. So this time, the other agent entered the values as data, showed me each one before creating it, and never touched the toggle. The dot com's record was public within two minutes.

The dot tv's registry took a little longer.

5:39Proof two: the chain

When the agent picked the ticket back up, it asked a validating public resolver for each domain's DS record and its signatures. Both came back. Then it pulled up the public checker, DNSViz, and read the analysis. The records, the keys, the delegation: Secure, for both domains. The page also listed errors and warnings, and the agent read them instead of panicking. Every one was about record types that don't exist yet, like mail and web addresses. A signed zone has to prove those records are missing, and it did.

Not a chain problem. As I said then: the dot com passes muster. We've got various securities in place.

6:26The first record

With the chain proven, the zone was ready for its first real record. The show needs a mailbox, and for that the domain has to join a Google Workspace. The admin side added the domain, and came back with a verification string: publish this text on the bare domain name, to prove you control it. That half is the agent's reach, because the zone is. It checked for an existing text record there, found none, created one with a five-minute lifetime, and confirmed it publicly at Google's resolver, eight dot eight dot eight dot eight.

Then it handed the ticket back, for someone else to click Verify.

7:08Off camera: Verify

The Verify button lives in the Workspace admin console, which never films. The other agent found the record public and clicked Confirm, and the click never registered. So I pressed it by hand. Verified, nine minutes after the record went in. We made a few trips back and forth like that, to get the shared items done under the super admin account.

7:29Let it drive

That's the whole of it: two zones, signed, delegated, proven from the outside, and a first record in place, with every registrar and console step done by the other side, and a receipt for each one in DNS. While we waited on one of those trips, I said what this channel is about. We're not really writing a lot of code here. We're driving a full infrastructure build on Google Cloud, through an agent. Cloud operations have a heavy hand on security, and many, many options that are hard to find.

By hand, you spend your time hunting for the twelfth menu under some topic. It's a needle in a haystack. The agent doesn't have that loss of memory, and it seems to know where everything is. So why not let it drive? And the security was baked into the plan, so what comes out is built secure.