SECOND MEASUREMENT SM-013

In 2018 the White House withdrew its DNSSEC mandate because agencies “already should have” done it. One in six executive-branch domains still has no DNSSEC, and the NSA signs with SHA-1

Markovian ProtocolMeasured 2026-10-03Status: published 2026-10-23; questions sent 2026-10-23DOI: 10.5281/zenodo.23608524

The Domain Name System is the phone book that turns a name like irs.gov into an address your computer can connect to. DNSSEC is the signature on each page of the book, so that a forged entry handed to you on the way can be caught. In August 2008 the White House budget office told every federal agency to have DNSSEC “deployed and operational by December 2009”. In August 2018 it withdrew that memo on the grounds that the requirement was outdated, since agencies “already should have implemented these security protections”. We took the government’s own list of federal domains, all 1,316 of them, published by CISA,⁷ and asked the .gov zone which of them are signed. In the executive branch, 986 of 1,169 are. The other 183 are not, and 129 of those answer with an address: grants.gov, passport.gov, foia.gov, health.gov, headstart.gov, cloud.gov, sam.gov, and get.gov, which is where agencies go to register a .gov domain. Thirteen more are signed with mistakes serious enough that Google’s and Cloudflare’s public resolvers refuse to answer for them at all; one of them is clinicaltrial.gov. And 63 zones sign with SHA-1, an algorithm NIST’s own DNS guide told agencies in 2013 to move away from by September 2015, and that its March 2026 guide no longer lists. They include nsa.gov, defense.gov, sec.gov, fcc.gov, usps.gov, healthcare.gov, medicare.gov, cyber.gov, and all eight domains of the Supreme Court.

Disclosure: Markovian Protocol holds no financial position in any organisation named here, was paid by no one for this work, and showed it to no one before publication except one named reviewer; the organisations measured get the questions on publication. How we work.

What they said, what we found

Who is signed and who isn’t

The headline domains are fine. whitehouse.gov, cisa.gov, dhs.gov, irs.gov, ssa.gov, va.gov, usa.gov, login.gov, vote.gov, cia.gov, fbi.gov, state.gov, omb.gov: all signed, all validating. The gaps are one layer down, in the services agencies run rather than the front doors they show.

Which of the 183 matter most is a question of who visits them. Against the Tranco list of the million most-visited domains, 59 of the 183 appear, 22 inside the top 100,000, and the two busiest are faa.gov (rank 2,810) and treasury.gov (2,834): the Federal Aviation Administration’s home and the Treasury’s, each with more traffic than any other unsigned federal name, and in Treasury’s case signed but with no DS in the parent, so the signatures count for nothing. Then health.gov, ojp.gov, llnl.gov, aviationweather.gov, sam.gov, digitalgov.gov, cloud.gov, airnow.gov and womenshealth.gov, all inside the top 20,000.

The judicial branch is the odd one. The Supreme Court signs all eight of its domains. The Administrative Office of the U.S. Courts, which runs the systems lawyers and litigants actually use, signs one of its 13: uscavc.gov. uscourts.gov, pacer.gov, bankruptcy.gov, federalcourts.gov, federalrules.gov and usprobation.gov are unsigned, and so are the Tax Court’s ustaxcourt.gov and the Sentencing Commission’s ussc.gov.

Signed, but broken

An unsigned domain still works. A wrongly signed one doesn’t: a validating resolver, and Google’s and Cloudflare’s both validate, answers SERVFAIL and the user sees nothing. Thirteen federal domains are in that state today, and the parent zone shows why for eleven of them; the twelfth, mortgagetranslations.gov, is explained by its own expired signatures, and pmi.gov is unexplained.

Seventeen more domains don’t answer through either resolver with checking on or off, and four fail on one resolver only (250.gov, explore.gov and transparency.gov, unsigned White House names Google won’t resolve, and poolsafely.gov in the first run only). Among the seventeen: notify.gov (GSA), osde.gov (CIA), givecfc.gov (OPM), opic.gov, and two Federal Reserve domains. They are in the registry; they are not on the internet.

SHA-1

NIST’s general rule, SP 800-131A, disallowed SHA-1 for new signatures after 2013 except where its own protocol-specific guidance allows it, and for DNSSEC that guidance did, for a while. The DNSSEC algorithms that use it, RSASHA1 and RSASHA1-NSEC3-SHA1, were marked NOT RECOMMENDED for signing by the IETF in 2019, and when NIST rewrote its DNS deployment guide in March 2026 its table of signing algorithms has five entries and none of them is SHA-1. The 2013 edition of that guide had said RSA with SHA-1 was the only algorithm both mandatory to implement and approved for federal use, adding that it would be phased out for RSA/SHA-256, and set a date: “The migration path for USG DNSSEC operation will be to ECDSA (or similar) from RSA/SHA-1 and RSA/SHA-256 before September 30th, 2015.”⁹ That is the protocol-specific allowance 800-131A refers to; it carried its own expiry, and the 2026 edition no longer carries it at all.

63 of the 1,316 federal zones, across all three branches, have no DS record for anything but an RSA/SHA-1 key: 54 executive, 8 judicial (the Supreme Court’s eight), 1 legislative (gao.gov). Seven more (nsf.gov, research.gov, sss.gov, ssab.gov and three Postal Service names) carried a SHA-1 DS beside a modern one on 3 October (nsf.gov’s was gone by 11 October); a validator that supports the modern algorithm uses it, so we count them separately. Counting any SHA-1 DS gives 70.

One zone is in a different class. lps.gov, a Defense Department domain, has five DS records in .gov, two of them typed as DSA (algorithm 3) with SHA-1 digests. The zone serves no DSA key: its four DNSKEYs are all RSA/SHA-256, and the two DSA-typed records carry the key tags of its RSA key-signing keys, so they are mistyped entries that validators ignore while the matching RSA records carry the chain (live_spotchecks_2026-10-11.json). RFC 8624 marks DSA MUST NOT either way; the record that matters is the SHA-1 digest, which RFC 8624 says MUST NOT be used to generate new DS records while validators MUST still accept it. 73 of the 1,105 signed federal domains have at least one DS with a SHA-1 digest, 90 records in all; for hc.gov it is the only DS. SHA-1 as a signing algorithm is NOT RECOMMENDED, not forbidden. By RFC 8624’s own words the MUST-level items in the set are the SHA-1-digest DS records, 73 domains’ worth, which .gov publishes; the signing algorithm is a NOT RECOMMENDED.⁶

Three of the 63 carry algorithm-5 (RSASHA1) DS records: tvaoig.gov, nwtrb.gov and adf.gov, which also carries algorithm 7 and serves only algorithm-7 keys. Algorithm 5 cannot do NSEC3, so tvaoig.gov and nwtrb.gov answer non-existence with plain NSEC and can be walked name by name; NIST’s 2026 guide prefers NSEC anyway, so this is enumeration by design, not a fault by NIST’s book. We checked: both serve NSEC. For those two the algorithm choice and zone enumeration are the same decision.

None of this is a vulnerability you can use today; no public collision attack produces a forged DNSSEC signature. It is a configuration NIST’s own DNS guide said to leave behind by 2015, running on the zone of the agency that writes the cryptographic requirements for national security systems.

How this ends

It ends one agency at a time, and the weekly recheck counts them: a DS record appears in .gov for a domain and it leaves the 183; a zone is re-signed or its stale DS withdrawn and it leaves the 13; a key is rolled off RSA/SHA-1 and it leaves the 63. CISA runs the registry and holds a security contact for most of these domains; the field is blank for 59 of the 258 domains in the three counts above (unsigned executive, SHA-1-only, broken), all eight Supreme Court domains among them. The shortest path to the end still runs through its own list.

The evidence

Every quote below was copied from the source and checked against a saved copy, fetched 2026-10-03. The registry file, both census runs, every DS record, the memos, the NIST publications and the scripts (census.py, analyze.py, auth_denial.py) are published next to this page; the derived tables (DS records, SHA-1 list, broken zones, resolver detail, in-use flags, Tranco ranks) came from the census and live DS queries through code we have not yet published as a script, which is a publish-day task (SHA256SUMS).

cisagov/dotgov-data current-federal.csv, commit 67a8ae94 (2026-10-02T12:07Z): 1,316 rows
  Federal - Executive 1,169   Federal - Legislative 121   Federal - Judicial 24   Federal 2

Run 1 03:33Z   DS 1,105   validating 1,081   SERVFAIL 34
Run 2 03:38Z   DS 1,105   validating 1,080   SERVFAIL 35   (poolsafely.gov, supportfan.gov, gpodev.gov flip)

get.gov        Department of Homeland Security   DS: none   DNSKEY: none   A: yes
treasury.gov   Department of the Treasury        DS: none   DNSKEY: served   AD: no
clinicaltrial.gov  DS tags 43789, 58792   DNSKEY tags 28576, 55833 (asked with checking disabled)   no match
mortgagetranslations.gov   RRSIG expiration 20260708
nsa.gov        DS algorithm 7, digest type 2   algorithm 7 = RSASHA1-NSEC3-SHA1

Our questions

Sent on 23 October to CISA’s .gov program, which runs the registry and get.gov (help@get.gov: questions 1, 3, 4 and 6), and to OMB’s Office of the Federal Chief Information Officer, which wrote both memos (ofcio@omb.eop.gov: questions 2 and 5). Answers will be printed here as written.

1. The registry records who owns each federal domain. Does CISA track whether each one is signed, and would it publish that column?
2. Is there a current, binding requirement that federal domains be DNSSEC-signed, now that M-08-23 is rescinded, beyond SC-20 in the SP 800-53 baseline? If so, where is it written, and what is the plan for the 183?
3. get.gov, the site agencies use to obtain a .gov domain, is unsigned. Is that intended?
4. Thirteen domains, listed above, are signed in a way that makes Google’s and Cloudflare’s validating resolvers refuse them, one for three months. Does anyone monitor federal zones for validation failures, and were the owners told?
5. Is RSA/SHA-1 signing permitted for federal zones under any current NIST or OMB guidance? If not, is there a date by which nsa.gov, defense.gov, sec.gov, healthcare.gov and the others move off it?
6. Treasury: treasury.gov serves DNSSEC keys and publishes the CDS delete signal, an explicit request for no DS in .gov. Is running the zone signed but unchained a deliberate choice, and if so why?

Their reply, scored

Disclosure timeline

What we can’t be sure of

• We measured the registered domain only. An agency can leave the apex unsigned and sign the zones it actually uses underneath, or the reverse. “All applicable information systems” is broader than 1,316 names and we did not go below them.
• Two public resolvers from one vantage point, twice in five minutes. For the DS census the vantage point does not matter, the DS lives in the parent and the answer is the same everywhere; for the 13 refusals it does, because a refusal is a property of the validator’s algorithm policy as much as of the zone. The three domains that flipped between runs show how much noise that carries; the 1,105 and 183 did not move.
• A DS record is the test, because without one no validator anywhere treats the zone as signed. Absence is the unambiguous direction; presence is not, since a DS can point at a key the zone no longer serves, which is what the 13 catch, so the two tests are complements. On 4 October we re-asked every one of the 211 no-DS domains at .gov’s own authoritative server (a.ns.gov) rather than a resolver: all 211 negatives are authenticated denials, an NSEC record owned by the name with no DS in its type list, signed by the .gov zone key, which we validated up to the root trust anchor (auth_denial.py, authoritative_denial.json). Treasury’s zone publishes the delete signal, so its missing DS is a choice, not a rollover in progress; the sixth question asks why.
• Whether SHA-1 signing is still permitted for federal DNS depends on reading SP 800-131A’s exception against SP 800-81. The 2013 guide allowed it in effect; the 2026 guide’s table doesn’t include it. We have put that reading to CISA and OMB rather than assert it.
• The registry is CISA’s view of who owns what. Names held by CISA’s “.gov Administration” (example.gov, igorville.gov) count as unsigned here because they are in the list; 17 of the 183 are those.

Run it yourself

Python 3 standard library plus dig. One 160 KB download from GitHub, about 5,000 DNS queries, twenty seconds on twenty threads.

curl -sLO https://raw.githubusercontent.com/cisagov/dotgov-data/main/current-federal.csv
python3 census.py       # DS, DNSKEY, AD flag per domain -> census.jsonl
python3 analyze.py      # branch and agency tables, validation failures, algorithms -> tables.json

Ran it? Send the number you got and the date to hello@markovianprotocol.com, subject “Rerun SM-013”. We print it on the track record with your name, or just the date if you prefer, and the first outside rerun of each paper gets the same seal the operators get.

References

1. Office of Management and Budget. Memorandum M-08-23, Securing the Federal Government’s Domain Name System Infrastructure, 22 August 2008. obamawhitehouse.archives.gov.
2. Office of Management and Budget. Memorandum M-18-23, Shifting From Low-Value to High-Value Work, 27 August 2018, p. 12. whitehouse.gov.
3. NIST. SP 800-53 rev. 5, Security and Privacy Controls, SC-20; Low baseline. usnistgov/oscal-content.
4. NIST. SP 800-131A, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, January 2011 (withdrawn 2015), and SP 800-131A rev. 2, March 2019. doi.org/10.6028/NIST.SP.800-131Ar2.
5. S. Rose, C. Liu, R. Gibson. NIST SP 800-81r3, Secure Domain Name System (DNS) Deployment Guide, March 2026. doi.org/10.6028/NIST.SP.800-81r3.
6. P. Wouters, O. Sury. Algorithm Implementation Requirements and Usage Guidance for DNSSEC, RFC 8624, June 2019. rfc-editor.org/rfc/rfc8624. RFC 9157 (2021) moved the live table to the IANA DNS Security Algorithm Numbers registry, iana.org/assignments/dns-sec-alg-numbers, which we checked on 4 October 2026: DSA (3) MUST NOT sign, MUST NOT validate; RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) NOT RECOMMENDED to sign, MUST validate.
7. CISA. dotgov-data, current-federal.csv. github.com/cisagov/dotgov-data.
8. NIST. Estimating USG IPv6 & DNSSEC External Service Deployment Status, USG table of 3 October 2026. usgv6-deploymon.nist.gov. Saved copy nist_usgv6_gov_2026-10-03.html.
9. R. Chandramouli, S. Rose. SP 800-81-2, Secure Domain Name System (DNS) Deployment Guide, NIST, September 2013 (withdrawn March 2026). Saved copy sp800-81-2.pdf.

Cite as

@misc{markovian-sm013,
  author = {{Markovian Protocol}},
  title  = {DNSSEC on federal .gov domains, October 2026},
  number = {SM-013},
  year   = {2026},
  month  = oct,
  url    = {https://markovianprotocol.com/measurements/sm-013.html}
}