I Built a DNS Expert Gem — Here's What It Actually Does

Keywords: DNS expert, AI for DNS, Gemini Gem, SPF DKIM DMARC, zone file validation, DNSSEC, email deliverability, network engineering

Reading time: ~8 minutes

DNS is narrow, technical, and unforgiving. A misconfigured record can take down email delivery, break a website, or cause authentication failures that take hours to trace back to the original mistake. Bad records also propagate — sometimes for hours, sometimes for days — which means you can't just "undo and try again." You have to get it right before it goes out.

I've been working with DNS professionally for over two decades. Across enterprise networks, ISP-scale authoritative servers, and small business setups, I've made most of the mistakes that exist. I built a DNS Expert Gem because even at that experience level, I want a fast second opinion before I push a change to production.

The Gem isn't a replacement for DNS knowledge. It's a way to verify my reasoning against a fast, syntax-correct, scenario-specific reference — faster than opening RFCs, faster than paging through man pages, faster than waiting for a colleague to be free.

The Problem I Was Trying to Solve

Three specific problems kept showing up in my DNS work:

First, validation before deployment. I had a pattern of writing zone file changes, reading them three times, and still missing a syntax error or a logic mistake that would propagate to the world before I caught it. Caught locally before the change went out: zero propagation impact. Caught after: anywhere from 30 minutes (if I was lucky) to 48 hours (if a TTL was set wrong).

Second, debugging email authentication issues. SPF, DKIM, and DMARC misconfigurations cause email to be silently dropped or marked as spam, and the failure messages in mail logs are notoriously unhelpful. Tracing an SPF `permerror` back to a `+ip4` syntax mistake or a DMARC `p=quarantine` policy that doesn't match the receiver's interpretation takes real DNS expertise. I had that expertise — but the time-to-resolution was longer than I wanted.

Third, explaining DNS behavior to non-DNS people. When a customer's email is being rejected, they want to know why. Translating "your DMARC alignment is failing because the DKIM signature isn't on the same domain as the From header" into something a non-technical stakeholder can act on takes effort. I wanted a way to generate those explanations on the fly without translating each time.

Generic AI tools could help with some of these but not all. They gave me general-purpose DNS answers when I needed syntax-correct, scenario-specific ones. I wanted a narrow, focused assistant — not a generalist with DNS knowledge.

What I Tried First (and Why It Wasn't Enough)

My first approach was a personal cheatsheet — a markdown file with my most-used record templates and the syntax quirks I'd learned the hard way. It was useful for templates but didn't help when I needed to debug a specific SPF record that was failing in production. The cheatsheet wasn't queryable.

Second attempt was using `dig`, `nslookup`, and online DNS lookup tools to manually verify every change before deployment. This is still part of my workflow, but it doesn't catch logic mistakes — it only confirms that the syntax is valid and the records are responding. If I had the wrong IP in an A record, dig would happily confirm the wrong IP.

Third attempt was using general-purpose AI with a long prompt explaining my role and what I needed. This worked better but the context had to be re-pasted each session, and the assistant would drift into general explanations instead of staying focused on my specific scenario.

What I wanted was a DNS-specific assistant that already knew my context, would give me syntax-correct answers, and could both validate my reasoning and explain things to non-DNS stakeholders when I needed it to.

The DNS Expert Gem did exactly that.

The Gem I Use

Here's the core of the instructions I saved into the Gem:

You are my DNS expert assistant. You help with zone file syntax, record validation, SPF/DKIM/DMARC configuration, DNSSEC, TTL strategy, and DNS-level troubleshooting.

When I share a DNS configuration or scenario:

  • Validate syntax against RFC conventions for the relevant record type
  • Flag logic errors (wrong IP, missing trailing dot on FQDN, mismatched tags)
  • For SPF: enforce the 10-lookup limit, flag `+all` or `?all` as dangerous, explain mechanism syntax
  • For DMARC: flag policies weaker than `p=quarantine`, explain alignment and reporting
  • For DKIM: verify selector naming, key length, and that the public key is published correctly
  • If I ask for an explanation for a non-technical reader, drop jargon and lead with the impact

My context: 20+ years of DNS experience. ISP-scale authoritative servers, enterprise mail systems, multi-tenant hosting. I want syntax-correct answers, not general explanations.

The "if I ask for an explanation for a non-technical reader, drop jargon and lead with the impact" instruction is the one that turned out to be most useful for the customer-explanation problem. By default the Gem gives me the technical answer; when I add a phrase like "explain for the customer," it switches to plain language without me having to reformat.

Two Real Examples — Before and After

These are based on actual DNS configurations I've worked on. Domain names are changed but the configurations and the issues are real.

Example 1: SPF Record Validation

Situation. A customer's email was being rejected by some receivers with SPF `permerror`. The SPF record had been growing over time as they added new sending services. I needed to check whether the record was over the 10-lookup limit and find what to cut.

Customer's existing record:

v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 include:_spf.google.com include:mail.zendesk.com include:emails.pegsurance.com include:sendgrid.net include:mailsenders.netsuite.com include:spf.protection.outlook.com include:_spf.salesforce.com include:esp.dmarcian.com include:clickme.mailsuite.com ~all

What I asked the Gem:

"Validate this SPF record. Count lookups and flag anything over the RFC limit."

Gem's response:

Problem: This record exceeds the 10-DNS-lookup limit (RFC 7208 §4.6.4). With all `include` mechanisms expanded, this resolves to ~14 lookups. Receivers enforcing the limit return `permerror`.

Counted lookups (9 includes + 2 ip4 = 11 counted):

  • ip4:192.0.2.10 (no lookup)
  • ip4:192.0.2.11 (no lookup)
  • include:_spf.google.com (resolves to ~3 nested lookups)
  • include:mail.zendesk.com (1)
  • include:emails.pegsurance.com (1)
  • include:sendgrid.net (1)
  • include:mailsenders.netsuite.com (1)
  • include:spf.protection.outlook.com (1)
  • include:_spf.salesforce.com (1)
  • include:esp.dmarcian.com (1)
  • include:clickme.mailsuite.com (1)

Recommendation: Consolidate to a single sending IP list using `ip4:` and `ip6:` mechanisms where possible, and remove redundant subdomains. Specifically: the `emails.pegsurance.com` and `mailsenders.netsuite.com` includes are both subdomains of the same vendor — they can be merged. Removing both reduces by 2.

Also: change `~all` to `-all` once you've confirmed all legitimate senders are in the record. `-all` is the recommended policy for production domains.

What the editor got right. It didn't just count lookups — it identified which includes were mergeable, which reduced the count to under 10. It also flagged the `~all` (soft fail) vs `-all` (hard fail) policy choice, which was a separate but related issue. The technical depth was exactly what I needed at the time.

What I changed. About 5% — I rewrote the record with the merged mechanisms and `-all`, then verified with dig before pushing. The analysis was the Gem's; the final record was mine.

Example 2: Customer-Facing Explanation

Situation. A non-technical customer wanted to understand why their email was sometimes going to spam. The underlying issue was a DMARC policy mismatch with their email service provider. I needed to explain this in a way the customer could act on.

What I asked the Gem:

"Explain for the customer: their DMARC policy is set to 'none' but the email service uses different alignment than their From domain. They're not authenticated properly. Plain language. Lead with what they need to do."

Gem's customer version:

Some of your outgoing email is being flagged as suspicious because of how it's being authenticated. There are three checks most email providers use to verify an email is really from you: SPF, DKIM, and DMARC. Your setup is passing the first two but failing the third.

The fix is to update your DMARC record. Currently it says "do nothing if checks fail" (`p=none`). It should say "treat failures as suspicious" (`p=quarantine`) once you've confirmed your email service is properly authenticated.

Your email provider can make this change for you — give them the new record value and ask them to publish it. Once it's live, your email should stop being flagged.

What the explanation got right. It led with what the customer needed to do (update the DMARC record), not with the technical details. It used the three-letter acronyms (SPF, DKIM, DMARC) but defined them inline. It explained what the current state was, what the right state was, and who could fix it. No mention of alignment modes, identifier verification, or RFC numbers.

What I changed. About 10% — I added the customer's specific DMARC record value they should publish, removed one sentence that felt too technical. The structure was the Gem's.

Where This Works and Where It Doesn't

After about 18 months of use, here's an honest assessment.

It works well for:

  • Syntax validation before deployment. Catches the trailing-dot, lookup-count, and policy-choice issues that are easy to miss in long records.
  • Translating technical findings into customer-ready explanations. The "explain for the customer" toggle has saved me hours of writing time.
  • Quick reference for record types I use less often. NAPTR, SSHFP, TLSA — I know these exist but use them rarely enough that the Gem is faster than reading RFCs.
  • Debugging email authentication failures. The Gem knows the failure modes and the standard fixes, which shortens the time-to-resolution.

It doesn't work well for:

  • Authoritative final answers on novel configurations. If I'm setting up something I haven't done before, the Gem's suggestions are a starting point, not a final answer. I still need to verify against the actual RFC and test in a non-production environment.
  • Real-time troubleshooting of live DNS propagation. The Gem doesn't have access to live `dig` results or propagation checking tools. It can reason about what should happen, not what's actually happening right now.
  • Anything involving DNSSEC key rollover. The mechanics of key rollover are too operational and time-dependent for a static-knowledge assistant. I use proper tooling and process documentation for those.
  • Compliance-specific configurations (e.g., specific regulatory requirements for email). Those need domain expertise beyond DNS.

A Note on What This Replaces

The Gem doesn't replace DNS expertise. I still need to understand the underlying mechanisms — what an SPF `+include` does, how DKIM alignment works, why DMARC reporting matters. The Gem gives me a fast reference and a validation step, but the actual decisions are mine. If I'm wrong about how a record should be configured, the Gem might validate the wrong thing confidently. The expertise is what catches that.

For someone newer to DNS, the same Gem can serve as a learning aid — but I'd caution against treating any AI output as authoritative on something as operationally consequential as DNS. Validate everything against RFCs and your own testing before deploying.

For me, the Gem has cut my pre-deployment review time by roughly half, and the customer-explanation feature has reduced the time I spend writing incident reports and customer updates. The wins are mostly time savings on routine work, which compounds across a year.

Related Reading

Sources

— Justin

📅 First published: 2026-04-29 | 🔄 Last updated: 2026-06-21