DedSec Security Research ·
Take an invented report for example.com with eight DNS findings: zone transfer allowed on ns2.example.com; open recursive resolver at 198.51.100.53; lame delegation for legacy.example.com; parent and child NS sets differ; nameservers lack diversity; zone uses NSEC and can be walked; no CAA record; wildcard record detected. They arrive with similar severities. In fact two of them could give an outsider control or a weapon, two give away information, two can take you offline with nobody attacking, and two are hygiene items, one of which (the wildcard) may already be intended.
This post takes each finding in turn: what the check sends, what a positive or negative result means, and what the relevant RFC says. Related topics are linked, not repeated: subdomain takeover for dangling records and delegations, email authentication for SPF, DKIM and DMARC, TLS posture for certificate transparency, and change detection for what SERVFAIL, NXDOMAIN and timeouts say about whether a name exists.
Sources, retrieved from rfc-editor.org on 24 October 2026: RFCs 1034, 1035, 2182, 2606, 4033, 4034, 4035, 4470, 4592, 5155, 5358, 5452, 5737, 5936, 6781, 6840, 8659, 8914, 9276 and 9499, and the BIND 9.18 delv manual page. RFC 9499 obsoletes RFC 8499 as the DNS terminology reference, so definitions are cited from 9499. Names are from RFC 2606 and addresses from RFC 5737. dig behaviour described below was checked with dig 9.18.
A zone transfer is "the act of a client requesting a copy of a zone and an authoritative server sending the needed information" (RFC 9499, section 6). AXFR (RFC 5936) copies the whole zone so secondaries stay in sync. Handed to anyone, it lists every name and record you publish: hosts linked from nowhere, staging names, SaaS verification tokens, delegations to other providers. It is not a way in by itself. It is the map an attacker would otherwise piece together from brute force and certificate transparency logs, delivered in one TCP session.
RFC 5936 section 5 says an implementation "SHOULD provide means to restrict AXFR sessions to specific clients", should allow access by address and range, and "is RECOMMENDED to implement access controls based upon" TSIG and/or SIG(0). It also says an implementation "SHOULD allow access to be open to all AXFR requests" as an operator choice, but "SHOULD NOT have a default policy for AXFR requests to be 'open to all'". So an open transfer does not break the protocol. It is a policy, and the RFC expects someone to have chosen it deliberately. If nobody can say why a server allows it, nobody chose it.
AXFR runs over TCP; section 4 quotes RFC 1034: "TCP or some other reliable protocol must be used for AXFR requests." The check connects to port 53 and sends an AXFR query for the zone. An allowed transfer streams the zone, beginning and ending with its SOA record. A refusal is an error response (section 2.2.1 says a server that is not authoritative "SHOULD set the value to NotAuth(9)"; other errors carry their own codes), or the connection is closed.
A refusal from one server tells you nothing about the others, because access control is set per server and can differ per listening address:
A zone signed with NSEC publishes the same list of names another way (see the DNSSEC section). Closing AXFR on such a zone only closes one of the two routes.
An open resolver "accepts and processes queries from any (or nearly any) client" (RFC 9499, section 6). RFC 5358 (BCP 140) section 3 describes the reflection attack. The attacker publishes a record "with large RDATA and Time to Live", sends queries to open recursive servers forging the victim's source address, and each server resolves, caches and delivers the large answer to the victim. The cached record stays "for the duration of the TTL, even if it's deleted from the zone", and the RFC gives an amplification factor for EDNS0 servers that "could be around 80". You are not the target. Your server does the damage, and the abuse reports carry your address.
The second exposure is your own cache. RFC 5452 section 4.1 ("Forcing a Query"): providing full service "enables the third party to send the target resolver a query for the domain name it intends to spoof", which "opens up a window of opportunity for getting fake answer data accepted." The same section notes that answering only from cache makes this harder, because the attacker can no longer pick the exact moment, but can still estimate a time range.
RFC 5358 section 4: "By default, nameservers SHOULD NOT offer recursive service to external networks." Servers "meant to be authoritative only" should "turn recursion off completely", and recursive and authoritative service should be kept separate "as much as practical."
The check sets RD (recursion desired) on a query for a name the server is not authoritative for, then reads the RA flag, the response code and the answer section. RA is a claim. RFC 1035 section 4.1.1 says it "denotes whether recursive query support is available". RFC 9499 defines an authoritative-only server as one that "ignores requests for recursion", meaning it "responds to requests for recursion with responses indicating that recursion was not performed". Such a server replies with RA clear and an error such as REFUSED, and dig prints "WARNING: recursion requested but not available". An open recursor replies with RA set and data. The cases in between are why reading a flag is not enough:
A delegation happens "when an NS RRset is added in the parent zone for the child origin" (RFC 9499, section 7). That section quotes RFC 1912's definition of lame delegation, a nameserver "delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone", then notes the term now also covers servers that do not answer, unreachable addresses, and answers "with an error or without the authoritative bit set". It concludes "there is no consensus on what a lame delegation is" and that the term "should be considered historic and avoided in favor of terms that are specific and clear." A finding with that label should say which condition was seen, for which server, from where.
NS records exist twice: in the parent at the delegation point, which resolvers follow on referral, and at the child's apex. RFC 1034 section 4.2.1 says the records describing a cut "should be exactly the same as the corresponding RRs in the top node of the subzone"; section 4.2.2 says both administrators "should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so." (RFC 5936 section 3.2 notes this "should" predates the BCP 14 keywords.) They drift because they are edited in different places, typically a registrar and a zone file. What a mismatch does depends on which server is wrong:
DNSSEC does not authenticate the referral: RFC 4035 section 2.2 says NS RRsets at delegation points "MUST NOT be signed". If the zone is signed with a DS at the parent, an attacker's server cannot produce valid signatures for new data, so validating resolvers return SERVFAIL. Non-validating resolvers accept the forged answers.
RFC 2182 (BCP 16) section 3.1 says secondaries "must be placed at both topologically and geographically dispersed locations on the Internet, to minimise the likelihood of a single failure disabling all of them". Section 5 notes the specification and registration rules "require at least two servers for every zone", that a two-server zone runs on one whenever either is down, and that "it is recommended that three servers be provided for most organisation level zones, with at least one which must be well removed from the others." It also warns that more servers raise "the likelihood that one server will be misconfigured, or malfunction, without being detected", which is how a single open-AXFR secondary happens.
From outside, diversity is an inference. A check can compare NS names, addresses, prefixes and announcing networks. It cannot see two addresses on one machine, or one anycast address served from many sites. Every nameserver at a single provider is a provider-level single point of failure even if that provider's network is widely spread. Someone should have decided that deliberately.
A validating resolver classes answers as secure, insecure, bogus or indeterminate. Bogus, in RFC 4033 section 5's words (quoted in RFC 9499 section 11), means a trust anchor and a secure delegation say the data is signed, "but the response fails to validate for some reason: missing signatures, expired signatures, signatures with unsupported algorithms". RFC 4035 section 5.5: the server "MUST return RCODE 2" (SERVFAIL), and returns the full response only "if the original query had the CD bit set."
So a broken zone fails only for users whose resolvers validate. An engineer testing from a non-validating resolver sees nothing wrong. The tickets come from users behind validating ISP or public resolvers, which is why "works for me" proves nothing here.
NSEC3 iteration counts above zero are a fourth cause, covered below.
Use the CD (checking disabled) bit. Under RFC 4035 section 3.2.2, a validating server receiving CD "SHOULD, if possible, return the requested data ... even if the recursive name server's local authentication policy would reject the records". SERVFAIL without CD and data with it means the servers are reachable and validation failed. SERVFAIL both ways points at reachability or delegation.
Resolvers that implement RFC 8914 may add an Extended DNS Error, which dig prints as an EDE line: 7 Signature Expired, 9 DNSKEY Missing ("A DS record existed at a parent, but no supported matching DNSKEY record could be found for the child"), 10 RRSIGs Missing. It is a hint. Section 3 says forwarding EDE "is implementation dependent", so a missing EDE line tells you nothing. To catch expiry before users do, a check has to query each authoritative server directly for RRSIG expiration, because one stale secondary can be the only server that fails.
RFC 5155 section 1.1 says NSEC "introduces a side-effect in that the contents of a zone can be enumerated". Each record names the next existing name, so "it is trivial to enumerate the content of a zone by querying for names that do not exist." RFC 4470 says that for owners who forbid arbitrary transfers, "this side effect of the NSEC architecture subverts those policies."
NSEC3 hashes the names, but section 12.1.1 says it is "still susceptible to dictionary attacks", only "substantially more expensive". RFC 9276 (BCP 236, 2022) revised the advice:
So a check that flags "NSEC3, zero iterations, no salt" as weak is flagging the configuration RFC 9276 recommends. A walkable zone is a disclosure finding, and its weight depends on whether any name was meant to be secret. If one was, DNS is the wrong place to keep it secret. RFC 9276 mentions minimally covering NSEC records (RFC 4470), generated on demand to cover fewer names, which RFC 4470 notes requires online private keys. The email-authentication post shows what walking means for DKIM selectors.
CAA (RFC 8659) lets a domain holder "specify the Certification Authorities (CAs) authorized to issue certificates for that domain name." Under section 3, a compliant CA "MUST check for publication of a Relevant RRset" and, if one exists, "MUST NOT issue" unless the request is consistent with it or a policy exception applies.
The lookup climbs the tree. For www.shop.example.com the CA queries that name, then shop.example.com, then example.com, stopping at the first non-empty set, "up to, but not including, the DNS root". A lower set therefore replaces a higher one rather than adding to it. Each query follows aliases, so a CNAME to a provider picks up whatever CAA the target publishes. Section 7 notes that RFC 8659 dropped RFC 6844's climbing of the CNAME target's own tree. In section 4, issuewild overrides issue for wildcard certificates, and an issue value of ";" on its own asks that no CA issue.
What it does not do, by the RFC's own account:
It can also block your own issuance: a subdomain delegated to a nameserver at a private address gives the CA SERVFAIL, which it "MAY interpret ... as preventing issuance" (section 6.3). "No CAA" is a hygiene finding: publishing it is cheap and narrows which compliant CAs can issue. Certificate transparency is how you see what was actually issued; see the TLS posture post.
Wildcards are instructions for synthesising records (RFC 1034 section 4.3.3, quoted in RFC 9499 section 8). RFC 4592 works through the rules, with an example zone in section 2.2.1:
For discovery, an enumerator that does not detect wildcards reports every guess as a live subdomain. One random-label test is not enough, because the rules above mean a wildcard at the apex says nothing about names under an existing dev.example.com, and an A-only probe misses a wildcard holding other types. Detection has to be repeated at each level and for each type queried.
For takeover checks, a wildcard CNAME to a third-party platform points every possible name there. If the platform lets any account attach any hostname, names you never used can be claimed. The takeover post treats that as its own finding. A checker that tests names one by one can report one record as thousands of findings.
Signed zones give a cleaner test. RFC 4034 section 3.1.3 says the RRSIG Labels field "MUST NOT count ... the wildcard label" and lets a validator "determine whether the answer was synthesized from a wildcard". An answer for a.b.example.com whose RRSIG says Labels 2 came from *.example.com. A real record at that name would say 4.
Rank by who can act and what they need, not by a score.
Someone else can act now, with no further mistake on your part.
Disclosure.
Availability, no attacker required.
Hygiene.
These use dig and delv from BIND 9. Use your own names, and query only servers you run or are authorised to test.
dig +norec @ns1.example.com dev.example.com NS (the parent's referral, in AUTHORITY, no aa flag) with dig +norec @ns1.dns-vendor.example.net dev.example.com NS (the child's answer, aa set). For a registered domain, dig +trace example.com NS shows the parent's referral.dig +nssearch example.com prints the SOA from each nameserver address. One that stays behind the others may have stopped transferring.dig +short SOA example.com gives the MNAME first; then dig AXFR example.com @ns1.example.com for every NS, the MNAME and each address, such as dig AXFR example.com @192.0.2.53.dig @198.51.100.53 rnd-4f1c9.probe.example.org A: read ra, status and answer, and check your probe.example.org server for that label. dig +norec @198.51.100.53 www.example.org A tests cache-only answers.dig +dnssec example.com SOA @203.0.113.10 through a validating resolver: ad means validated. On SERVFAIL, repeat with +cd and note any EDE line. delv example.com SOA validates against BIND's built-in root trust anchor and explains failures; +vtrace shows each step.dig +dnssec +norec +multiline @ns1.example.com example.com SOA shows RRSIG inception and expiration. Repeat for every nameserver.dig +short DS example.com with dig +multiline DNSKEY example.com, whose comments show each key id and mark KSKs.dig +dnssec nonexistent-7f3a.example.com A shows NSEC or NSEC3 in AUTHORITY; dig +short NSEC3PARAM example.com gives algorithm, flags, iterations and salt.dig +short CAA www.shop.example.com, then each parent, stopping at the first non-empty answer.dig +short zq7x1.example.com A and dig +short zq7x1.dev.example.com A, repeated for TXT and MX, at every level you enumerate.Maphra starts from a domain name, enumerates subdomains and resolves infrastructure, and attributes each discovered asset to the organisation that owns it. Its Comprehensive Security Analysis covers TLS and certificate posture, security headers, DNS hygiene, email authentication and misconfiguration checks across every discovered asset. Every discovered asset is checked for exposure, including DNS hygiene and takeover-prone records, and exposure analysis looks for permissive DNS among other things; each finding carries the raw response that produced it. Active validation runs only inside an explicit scope boundary you define, and the scope gate prevents active checks from reaching third-party hosts that merely appear in your surface. Findings are deduplicated across scans and tracked through new, reopened and fixed states.
That is the whole claim. The checks and methods in this post are general practice, not a description of how Maphra's DNS checks work. Nothing here claims that Maphra attempts zone transfers, probes for open recursion, compares parent and child NS sets, assesses nameserver diversity, checks nameserver domains for registrability, validates DNSSEC chains or reads RRSIG expirations, detects NSEC walkability or NSEC3 parameters, evaluates CAA, detects wildcards in any particular way, or which fields of a DNS response its retained evidence includes. Put the questions above to us as you would to anyone else.
Back to example.com. Check the delegation first: a nameserver name in a domain nobody holds is the incident. Close the open resolver. Find out why ns2 hands out the zone, and ask the SOA primary the same question. Confirm DNSSEC validates from more than one resolver and no server's signatures are close to expiry. Then publish CAA, document the wildcard as intended, and leave NSEC alone unless a name in the zone was meant to be secret, because DNS was never going to keep it secret.