Skip to content

Security and monitoring

Security check

The security issues and misconfigurations DNSMigrator reports, the live checks against nameservers and public resolvers, and where each runs.

6 min read

On this page

The security check reviews a zone for two kinds of problem only: security issues that someone can abuse right now, and misconfigurations that break a record or make receivers ignore it. It never reports best-practice advice such as "add CAA" or "tighten DMARC", so every finding needs action.

Where it runs#

WhereRecords checkedLive checks
Assistant → Findings tab, for a migration or a managed zoneEvery record the migration will write, including saved edits, or the zone's desired recordsRun live checks
DNS security checkerRecords found by public discovery, which is usually partialAlways
Assistant edits and draftsThe records after the proposed changeNo

When the assistant proposes changes, it shows how many critical and high findings would remain, and each proposal lists the findings it resolves.

Security issues#

RuleFindingSeverityDecided from
private-addressPrivate address publishedCriticalRecords
credential-publishedCredential published in DNSCriticalRecords
spf-allows-allSPF lets anyone send as youCriticalRecords
zone-transfer-openZone transfer open to anyoneCriticalLive
subdomain-takeoverSubdomain can be taken overCriticalLive
nameserver-hijackableNameserver domain is unregisteredCriticalLive
internal-mail-serverMail goes to an internal serverHighRecords
exposed-serviceInternal service advertisedHighRecords
spf-broad-rangeSPF authorizes a huge address rangeHighRecords
dkim-weak-keyDKIM key is too shortHighRecords
domain-expiringDomain registration expiringHighLive
dnssec-weak-algorithmDNSSEC uses a deprecated algorithmMediumRecords

Notes on the less obvious rules:

  • credential-published matches only formats that are unambiguous by shape: AWS access keys, private key blocks, GitHub and Slack tokens and live Stripe secret keys. Anything that merely looks like a password is left to the assistant's review, and the value is redacted before any record reaches the model.
  • spf-broad-range fires for an ip4: range wider than /16 or an ip6: range wider than /32. A range of /1 or wider counts as spf-allows-all.
  • dkim-weak-key reads the RSA modulus size from the key's DER header and fires below 1024 bits, the minimum in RFC 8301.
  • dnssec-weak-algorithm covers DNSKEY and DS records using algorithms 1, 3, 5, 6, 7 or 12, and DS sets that only use SHA-1 digests, per RFC 8624.
  • subdomain-takeover fires when a CNAME, MX or child NS points at a name whose domain isn't registered, or a CNAME points at a deleted resource on a platform where anyone can claim the name again, such as Azure App Service, Azure Traffic Manager, Azure Blob Storage or AWS Elastic Beanstalk. Platforms that show an HTTP error page for missing resources need an HTTP check and aren't covered.
  • domain-expiring fires when the registry reports that the registration expires within 30 days or has expired.

Misconfigurations#

RuleFindingSeverityDecided from
resolution-failingPublic resolvers can't resolve the domainCriticalLive
dnssec-brokenDNSSEC validation failsCriticalLive
spf-multipleMore than one SPF recordHighRecords
spf-too-many-lookupsSPF needs too many lookupsHighRecords
spf-invalidSPF record is brokenHighRecords
dmarc-invalidDMARC record is brokenHighRecords
dkim-invalidDKIM key is brokenHighRecords
caa-invalidCAA record is brokenHighRecords
cname-conflictCNAME next to other recordsHighRecords
cname-loopCNAME loopHighRecords
record-invalidRecord can't be publishedHighRecords
dnssec-record-invalidDNSSEC record is brokenHighRecords
nameserver-internalNameserver isn't reachable from the internetHighRecords
nameserver-lameNameserver doesn't answer for the zoneHighLive
mta-sts-invalidMTA-STS record is brokenMediumRecords
tlsrpt-invalidTLS-RPT record is brokenMediumRecords
record-occludedRecord hidden by a delegationMediumRecords
delegation-mismatchRegistry and zone list different nameserversMediumLive
target-is-aliasPoints at an aliasMediumRecords
target-is-ipPoints at an IP addressMediumRecords
target-missingPoints at a name with no recordsMediumRecords
target-danglingPoints at a name that doesn't existMediumLive
dmarc-report-unauthorizedDMARC reports go to an unauthorized domainLowLive

Several of these reuse the zone checks, but only their errors: advisory lint warnings are never findings here.

Live checks#

Run live checks queries public DNS for the zone's domain as it is right now, then combines what it learns with the records in the workspace:

  • Public resolvers agree. The apex SOA is asked through Cloudflare, Google Public DNS, Quad9, OpenDNS and AdGuard DNS. If most of them fail, the domain is down for most visitors.
  • DNSSEC validates. The parent's DS records are compared with the zone's DNSKEYs, and validating resolvers are asked whether the chain holds.
  • Zone transfer closed. An AXFR is attempted against every authoritative nameserver, not just the first.
  • Nameservers answer and can't be hijacked. Each delegated nameserver must answer authoritatively for the zone, and each nameserver's own domain must be registered. The registry's nameservers are compared with the zone's NS records.
  • Targets still exist. Every CNAME, MX, SRV and child NS target is resolved through the public resolvers. A target counts as missing only when most resolvers return NXDOMAIN, so one resolver's hiccup can't raise a finding.
  • DMARC report addresses authorized. External rua and ruf addresses need a <your-domain>._report._dmarc.<their-domain> record, per RFC 7489.
  • Registration not expiring. The expiry date comes from the registry over RDAP.

The panel lists each check with a pass or a failure, and failures appear as findings. Results are cached for 10 minutes per set of records. A workspace can run 30 live checks an hour, and each run is recorded in the activity log as security.live-check.

Fixing findings#

Open a finding to see what's wrong, the record involved and the fix. In the Assistant, Ask the assistant to fix these drafts edits for the findings it can fix with records. Edits are checked again before you approve them, and nothing reaches a provider until you review the plan: a migration's preview, or a zone's push.

Why doesn't the check tell me to add CAA or DKIM?

Missing protections aren't vulnerabilities, and mixing advice with real problems hides the problems. The check only reports something exposed right now, or a record that's broken or ignored.

Why does the public checker find less than the Assistant?

Public DNS can't list a zone's records unless the nameservers allow a zone transfer, so discovery asks for common names and is usually partial. The Assistant checks every record in the migration or zone.

Can a live check change anything?

No. It sends DNS queries, one zone transfer request per nameserver and one RDAP lookup. It never writes to a provider or registrar.

What counts as a subdomain takeover?

A record that points at a name anyone can claim: a domain that isn't registered, or a deleted resource on a cloud platform where the name can be created again. Whoever claims it can serve content, receive mail or answer queries as your subdomain.