DNS-AID: the new standard for making your AI agent discoverable

AI agents are beginning to talk to one another. A customer's assistant wants to check your availability, a supplier's agent wants to confirm an order, a partner's tool wants to reach your support agent – but first it has to find the right one. Today that discovery is largely guesswork, and guesswork is exactly where impersonation and mistakes creep in. DNS-AID is the emerging standard that fixes this, letting an organization publish its official AI agent through the one system that already proves who owns a domain: DNS.

What DNS-AID Is

DNS-AID applies a very old idea to a very new problem. For decades, DNS has told the internet where to send things: an A record points to your website, an MX record points to your mail server. DNS-AID adds the equivalent for AI – a small DNS record (for example, under a name like _agent.yourcompany.co.il) that advertises where your agent lives and which protocol it speaks, such as MCP or A2A. Any compliant assistant can look up that record and connect to your real agent, the same way a mail server looks up your MX record before delivering email.

Why It Matters as Customers Adopt AI Assistants

The way people reach businesses is shifting. Increasingly a customer will ask their own AI assistant to book the appointment, get the quote, or open the support ticket – and that assistant needs to find your business's agent to do it. If you have published a DNS-AID record, you are discoverable and reachable in this new channel. If you have not, the assistant either cannot find you or, worse, settles for whatever unofficial endpoint it can dig up. For an Israeli SMB, being present and authoritative here is becoming as basic as having a website was twenty years ago.

DNS as a Trust Anchor Against Impersonation

The reason DNS is the right place for this is trust. Only the organization that controls a domain can publish records under it, so a DNS-AID entry is a verifiable claim that 'this is our official agent' – not an address someone scraped or invented. It is the same principle that makes SPF, DKIM, and DMARC effective against email spoofing. Pairing your records with DNSSEC, which cryptographically signs DNS answers, raises the bar further and makes it much harder for an attacker to redirect agents to a fake endpoint.

What Publishing an Agent Actually Involves

Adopting DNS-AID has two parts. First you need an agent endpoint – typically a service that exposes selected business capabilities over an agent protocol, scoped carefully to what you actually want to share. Then you publish the DNS record that points to it. The record itself is trivial to add; the judgement is in everything around it: what the agent is allowed to do, how it authenticates callers, and how you keep the published information accurate as your services change. A record that points to a misconfigured or over-permissioned agent is worse than no record at all.

Getting Ready Without Getting Burned

Publishing an agent makes a door into your business deliberately easy to find, so the security of what sits behind that door matters more than ever. The endpoint should follow least privilege, log what it does, and never expose data or actions you would not hand to an anonymous caller. This is why DNS-AID and agent security are two halves of the same project: discoverability is only an asset if the thing being discovered is properly locked down. Treat the DNS record as the last step, after the agent behind it is built and secured correctly.

Getting discoverable without getting exposed

DNS-AID is young, but the businesses that prepare now will be the ones AI assistants can find and trust first – and the move costs little beyond getting it right. NetFortress helps Israeli SMBs publish their agents through DNS-AID safely: setting up the records, hardening DNS with DNSSEC, and making sure the agent behind the record is scoped and secured. Talk to us, and we will map out how to make your business discoverable in the agent era without opening yourself up.