--- title: "What 100 cybersecurity vendors do about TLS and DNS: post-quantum πŸ‘πŸΌ, DNSSEC πŸ”΄" description: "67 of 100 cybersecurity vendors support post-quantum key exchange, but 75% leave DNS unsigned and not one publishes a TLSA record. A census of the Cyber 100 across TLS and DNS posture." pubDatetime: 2026-09-11T10:00:00Z author: hrbrmstr tags: ["post-quantum", "dns", "dnssec", "tls", "cybersecurity", "internet-standards", "research"] --- > Original: [What 100 cybersecurity vendors do about TLS and DNS: post-quantum πŸ‘πŸΌ, DNSSEC πŸ”΄](https://ai.rud.is/posts/2026-09-11-what-100-cybersecurity-vendors-do-about-tls-and-dns-post-quantum-dnssec) Hot-ish on the heels of the "[What 100 Cybersecurity Vendors Tell AI Agents: An llms.txt Census](https://ai.rud.is/posts/2026-09-04-cyber100-llms-txt-census)" post, today we cover some other items cybersecurity firms shld have dotted the i's and crossted the t's on, especially given the recent [brilliantly-executed attack on virtualizor](https://www.virtualizor.com/blog/security-incident-bgp-hijacking/)). ## TL;DR 67 of 100 vendors support post-quantum key exchange, which is pretty strong adoption for a spec that's still fairly young. But 75 leave their DNS unsigned, zero publish TLSA records, and only one deploys ECH. Defense contractors Lockheed Martin, Booz Allen Hamilton, and Northrop Grumman are in the unsigned zone. Cisco caps at TLS 1.2, Trend Micro accepts only P-384, and Microsoft publishes a CAA record with no issue tag. The post-quantum future arrived early; the DNS hygiene didn't get the memo. ## So, what are we checking for, exactly? [**Post-quantum key exchange**](https://en.wikipedia.org/wiki/Post-quantum_cryptography). An attacker recording TLS traffic today can derive the session key later once a capable quantum computer exists. The fix is a hybrid key exchange group that mixes a classical curve with [ML-KEM](https://en.wikipedia.org/wiki/ML-KEM), so breaking one session requires breaking both algorithms. [`pqprobe`](https://github.com/Allan-Nava/pqprobe) _(@ me wherev if you have a better tool suggestion)_ dials each host with three client profiles. The `classic` profile sends what browsers send today. The `pq-preferred` profile offers hybrid ML-KEM first with a classical fallback. The `pq-only` profile requires hybrid ML-KEM and won't settle for less. A host that completes all three is `pq-ready`. [**Encrypted Client Hello.**](https://www.rfc-editor.org/info/rfc9849/) The TLS ClientHello carries the server name in cleartext, which means any network observer learns which site a client visits. ECH moves that field into an encrypted extension, and the public key for it arrives in a DNS HTTPS record – so ECH needs two things at once: the `ech=` parameter in DNS and a server that accepts the encrypted hello. This census measures the two halves separately. [**CAA.**](https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization) CAA records name the certificate authorities allowed to issue for a domain. A CA has to check them before issuing, so a mistaken or fraudulent issuance becomes a blocked one instead. An empty CAA RRset means any CA can issue. A record with `issue ";"` means none can. [**DNSSEC chain validation.**](https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension-01) DNSSEC signs DNS answers so a resolver can prove the zone published them and that nobody altered them in transit. Validation walks from the root: the root signs the TLD, the TLD signs a DS record naming the child's key, and the child signs its own records. Every query here validates from the root rather than trusting a resolver's AD bit, so each status reflects the actual chain. [**CDS and CDNSKEY.**](https://www.rfc-editor.org/info/rfc8078/) CDS and CDNSKEY are the child zone asking its parent to publish a digest for a new key. A parent that honors them completes a key rollover without a support ticket, so their presence marks automated DNSSEC operations. [**TLSA and DANE.**](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities) A TLSA record binds a certificate or public key to a hostname in DNS, letting a client authenticate a TLS server without touching the CA trust hierarchy. The record lives at `_443._tcp.`, and it only carries weight under DNSSEC. An unsigned TLSA record proves nothing – whoever answers the query can forge it. [**HTTPS records.**](https://www.rfc-editor.org/info/rfc9460/) An HTTPS record (type 65, the Service Binding and Parameter Specification β€” SVCB β€” family) tells a client how to reach a service before it opens a connection: [Application-Layer Protocol Negotiation](https://datatracker.ietf.org/doc/html/rfc8833) (ALPN) protocols, HTTP/3 support, alternate ports, address hints, and the ECH config. It's the DNS half of a TLS posture, and a certificate scan never sees it. ## Test harness The targets are the same 100 domains as the aforementioned `llms.txt` census, the University of San Diego's "Cyber 100" list of influential cybersecurity companies (they really need to remove `threatstack.com` since it's not a thing anymore after they got acquired by F5). Certificates, key exchange groups, and CAA records live on the FQDN. DS, DNSKEY, and the other zone records live at the apex. TLSA lives under a service prefix. This means one probe list can't cover all three, so the census runs four commands over derived name lists and joins the results by name. ```bash # 1. per-FQDN: CAA, HTTPS, RRSIG zdns MULTIPLE -c fqdn.ini -f fqdns.txt -o fqdn.jsonl --metadata-file=fqdn.meta.json # 2. per-apex: DS, DNSKEY, CDS, CDNSKEY, NSEC3PARAM zdns MULTIPLE -c zone.ini -f zones.txt -o zone.jsonl # 3. TLSA at _443._tcp. zdns TLSA --prefix="_443._tcp." -f fqdns.txt \ --iterative --validate-dnssec --dnssec \ --per-ip-ns-rate-limit=20 -o tlsa.jsonl # 4. TLS, per address, with ECH and per-group dials pqprobe probe --list fqdns.txt --per-address --ech --per-group \ --dns 1.1.1.1:53 --json > pq.json pqprobe probe --list fqdns.txt --per-address --ech --per-group \ --dns 1.1.1.1:53 --findings=wrapped > pq-findings.json ``` Both `zdns` passes validate from the root (`--iterative --validate-dnssec`) and cap the query rate at 20 per authoritative IP. The apex is the last two labels of the FQDN, which holds for this list – every domain ends in `com`, `io`, `co`, or `org`. `pqprobe` was configured to resolve through `1.1.1.1` (`--dns`) for both addresses and ECH configs, so a host resolver can't filter the HTTPS records. It dials every A and AAAA record of every name (`--per-address`), then each key exchange group on its own (`--per-group`). The 100 names resolve to a final set of 272 addresses. A few notes on the methodology and some hiccups… A pre-flight run over 10 names validated the pipeline before the full pass, and included a post-quantum leader, two WAF-protected sites, two subdomain-hosted entries, and that one host the earlier `llms.txt` census found unreachable. The `dnssec_status` column (I'm working on getting the scripts and data files into a clean repo dir) comes from validating the apex DNSKEY RRset, not the DS RRset. A DS query for an unsigned child returns a signed denial of existence from the parent. A denial means a DS-status column reports `Secure` for zones that aren't signed at all, and the DNSKEY RRset can't be forged that way. Both columns agree with `dig` for every zone: 25 signed, 75 unsigned. One name answers differently depending on which address type a client reaches. `forcepoint.com` runs eight IPv6 addresses that cap at TLS 1.2 and two IPv4 addresses that offer TLS 1.3. The two `pqprobe` renderers disagreed on one address of `oneidentity.com`, which the first run graded `pq-blind` after a timeout on the classical profile. Two fresh runs, each with both renderers, graded both addresses `no-tls13`, so I used the rerun values. ## TELL ME THE RESULTS ALREADY | TLS class | Count | Example | |---|---:|---| | `pq-ready` | 67 | cloudflare.com, checkpoint.com | | `pq-blind` | 20 | microsoft.com, fortinet.com, paloaltonetworks.com | | `no-tls13` | 11 | cisco.com, splunk.com, vmware.com | | `tls-broken` | 1 | trendmicro.com | | `unreachable` | 1 | threatstack.com | | DNS measure | Count | |---|---:| | Zone signed, chain validated | 25 | | Zone unsigned | 75 | | CAA record present | 37 | | CAA record restricts issuance | 35 | | HTTPS record present | 12 | | ECH config published and accepted | 1 | | CDS or CDNSKEY published | 9 | | TLSA record present | 0 | 67 names complete the `pq-only` handshake, negotiating hybrid ML-KEM even for a client that requires it. 31 names accept a `pq-preferred` client but land on a classical group anyway – 22 on X25519 and 9 on P-256. Sadly, two names complete no handshake at all. The DNS numbers run in the opposite direction, and (ngl) they're a bit embarrassing for a list of influential security vendors. Three quarters of the list leave the zone unsigned, 63 names publish no CAA record, and not one name publishes a TLSA record. The newest transport cryptography is more common here than the oldest DNS hygiene (this is why we can't have nice things). ## TLS findings 67 names complete all three profiles and land on `X25519MLKEM768` – Cloudflare, Check Point, CrowdStrike, CyberArk, Darktrace, Akamai, IBM, BAE Systems, Proofpoint, Rapid7, PwC, KPMG, Leidos, Booz Allen Hamilton, Lockheed Martin, Northrop Grumman, HackerOne, Bugcrowd, Infoblox, Ivanti, RTX, and RSA among them. 20 names are `pq-blind`. They complete a handshake with all three profiles, but a `pq-only` client doesn't connect, so `pqprobe` falls back to a classical group. Microsoft, Intel, Fortinet, F5, Palo Alto Networks, Tenable, Trellix, Mimecast, NETSCOUT, Radware, Gen Digital, Telos, Cofense, Deep Instinct, Digital Defense, i-Sprint, Mitre, OneLogin, RiskIQ, and Kaspersky's US site are all in this bucket. 11 names cap at TLS 1.2, which makes post-quantum key exchange unreachable regardless of what the client offers: Accenture, Cisco, Forcepoint, Guidance Software, McAfee, Nexusguard, One Identity, Ping Identity, Splunk, Thycotic, and VMware. One of the very well known network security vendors on the list (perhaps the one whose entire business is built on knowing better) answers a TLS 1.3 ClientHello with a TLS 1.2 server hello on both of its addresses. `o_o` One host fails every profile. `trendmicro.com` answers on 150.70.185.35 and accepts only P-384. Every profile got `remote error: tls: handshake failure`, and the per-group dials show: P-384 completes, and X25519, P-256, P-521, X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 are declined with an alert (this means a client that doesn't offer P-384 has no group left to negotiate). As noted twice already, `threatstack.com` has no address to dial. It doesn't resolve since the acquisition – which is also what the `llms.txt` census found. `siemplify.co` resolves to Google anycast and presents a `*.google.com` certificate (Google bought them in 2022, so this is one more entry our edu pals should also rmeote). ## DNS findings 25 zones sign their DNS and validate from the root: Akamai, Accenture, BAE Systems, Bugcrowd, Callsign, Check Point, Cloudflare, CrowdStrike, CyberArk, Darktrace, Forcepoint, HackerOne, Infoblox, Ivanti, KnowBe4, Mitre, NETSCOUT, Palo Alto Networks, RiskIQ, RTX, Secude, Tenable, Trend Micro, Trustwave, and Zimperium. The other 75 don't, including Cisco, McAfee, Splunk, VMware, Fortinet, Microsoft, Intel, IBM, PwC, KPMG, Duo, OneLogin, Ping Identity, Rapid7, Proofpoint, SailPoint, Mimecast, F5, most of the consumer brands, and – perhaps most notably for an industry that sells security products to the federal government – Leidos, Booz Allen Hamilton, Lockheed Martin, and Northrop Grumman. Not one of the 100 publishes a TLSA record at `_443._tcp.`, so DANE is entirely unused here. Every TLSA query came back empty: 82 names carrying an indeterminate DNSSEC status, 15 an answer under a validated chain, 2 an insecure one, and 1 returning nothing at all. One name publishes an ECH config and accepts an encrypted ClientHello: `resecurity.com`. The config arrives in an HTTPS record that also carries `alpn` `h3,h2` and address hints. The decoded config names `cloudflare-ech.com`, which means the ECH deployment lives on Cloudflare's infrastructure rather than anything bespoke. No other name on the list publishes an `ech=` parameter. 12 names publish an HTTPS record: | Name | ALPN in the record | ECH | |---|---|---| | akamai.com | none (alias to `www.akamai.com.edgekey.net`) | no | | cloudflare.com | h3, h2 | no | | crowdstrike.com | h2 | no | | cyberark.com | h3, h2 | no | | darktrace.com | h2 | no | | gigamon.com | h2 | no | | ivanti.com | h3, h2 | no | | onespan.com | h2 | no | | resecurity.com | h3, h2 | yes | | rtx.com | h2 | no | | scnsoft.com | h3, h2 | no | | zerofox.com | h2 | no | 63 names publish no CAA record, leaving every CA free to issue for them. 35 names publish an `issue` or `issuewild` tag that names a CA, and 12 of those also include an `iodef` contact. Two names publish a CAA RRset that restricts nothing: `microsoft.com` and `riskiq.com` both serve a single `contactemail` record with the value `caarecordaware@microsoft.com` and no `issue` tag. A CAA RRset without an `issue` tag is not a restriction. It's just a comment. DNSSEC key algorithms split three ways: 21 signed zones use algorithm 13, ECDSA on P-256. Three use algorithm 8, RSA with SHA-256: Akamai, Infoblox, and Mitre. One zone publishes algorithm 5, RSA with SHA-1, alongside algorithm 13 in its key set: Accenture. (Algorithm 5 is deprecated, and has been for a while.) NSEC3 parameter hygiene is mostly clean. Six signed zones publish an NSEC3PARAM record; five use zero iterations, which is what RFC 9276 recommends. `infoblox.com` uses 10. Nine signed zones publish CDS and CDNSKEY records, letting the parent pick up a key rollover without manual DS edits: Cloudflare, CrowdStrike, CyberArk, Darktrace, HackerOne, Ivanti, RTX, Secude, and Tenable. The other 16 signed zones require an out-of-band DS update to roll a key. Eight names pass all three combined checks – post-quantum ready, zone signed, and a CAA record that restricts issuance: Callsign, Check Point, Cloudflare, Darktrace, HackerOne, Infoblox, Ivanti, and RTX. Five of those also publish CDS and CDNSKEY, and four publish an HTTPS record. Cross-tabulating against the `llms.txt` census shows no meaningful relationship. 28 of 67 `pq-ready` names serve an `llms.txt` (42%), against 7 of the 33 that aren't `pq-ready` (21%). For DNSSEC, 9 of 35 names serving an `llms.txt` sign their zone (26%), compared to 16 of 65 that don't (25%). With 100 names and that little spread, neither axis predicts the other. ## Respect my certificate authoritay? CAs authorized by CAA (`issue`/`issuewild` tags, 37 names publish a CAA RRset; domains naming each CA): - `letsencrypt.org` β€” 33 - `digicert.com` β€” 31 - `pki.goog` (Google) β€” 26 - `amazon.com` β€” 24 - `amazonaws.com` β€” 15, `sectigo.com` β€” 15 - `globalsign.com` β€” 12, `godaddy.com` β€” 12, `comodoca.com` β€” 12 - `amazontrust.com `β€” 11, `ssl.com `β€” 11, `awstrust.com` β€” 11 - `entrust.net` β€” 3, `identrust.com` β€” 2 - 1 each: `trust-provider.com`, `comodo.com`, `trustproviderbv.digitalcertvalidation.com`, `thawte.com`, `affirmtrust.com`, `e-szigno.hu`, `cloudflare.com`, `usertrust.com`, `starfieldtech.org`, `starfieldtech.com` There are two odd records in there: `hackerone.com` publishes `issuewild` ";" (forbids all wildcard issuance), and `onespan.com` publishes one issue whose value is 32 backslash characters with no CA name. The rest are normal. Also, 26 names authorize 5 or more CA families; `checkpoint.com` authorizes 8. CAs actually issuing the leaf certificates (grouped, domains / addresses β€” 272 addresses total): - Google Trust Services (WE1, WR1/WR2, YR1/YR2, YE1/YE2) β€” 43 / 107 - DigiCert β€” 18 / 45 - Amazon β€” 10 / 42 - Sectigo β€” 11 / 28 - GlobalSign β€” 7 / 27 - Microsoft β€” 2 / 8 - GoDaddy β€” 3 / 7 - GeoTrust β€” 1 / 2, ZeroSSL β€” 1 / 2, Thawte β€” 1 / 1, McAfee RSA OV β€” 1 / 1 In the end, three names serve a certificate from a CA they _do not authorize_: - `cisco.com` β€” Sectigo issuer; authorizes Amazon, DigiCert, GlobalSign, Google, Let's Encrypt, ssl.com, identrust.com - `infoblox.com` β€” Google Trust Services issuer; authorizes Amazon, DigiCert, GoDaddy, Let's Encrypt, Sectigo - `i-sprint.com` β€” Google Trust Services issuer; authorizes GoDaddy, Let's Encrypt ## Configurations that need work Each item below is checkable from fresh probes: - **cisco.com caps at TLS 1.2.** Both addresses answer a TLS 1.3 ClientHello with a TLS 1.2 server hello, so hybrid ML-KEM is unreachable at a network security vendor. NOTE: www.cisco.com _does_ support TLS 1.3 (`TLS_AES_256_GCM_SHA384`). The zone is also unsigned, no DS and no DNSKEY. Its CAA RRset is well-built: 11 records, restrictive. One out of three isn't great. - **trendmicro.com accepts only P-384.** (NOTE: `www.trendmicro.com`'s default negotiation is `X25519`). For the apex, very profile gets a handshake failure alert. Per-group apex dials show P-384 completing while X25519, P-256, P-521, X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 are declined. - **microsoft.com and riskiq.com publish a CAA record that restricts nothing.** Both serve one `contactemail` record, value `caarecordaware@microsoft.com`, and no `issue` tag. - **accenture.com keeps RSA/SHA-1 in its DNSKEY set.** The zone publishes algorithm 5 next to algorithm 13, and the site caps at TLS 1.2 with no CAA record. Algorithm 5 is deprecated (RFC 8624 downgraded `RSASHA1` to `MUST NOT` be used for new deployments / `NOT RECOMMENDED`). - **akamai.com, infoblox.com, and mitre.org sign with RSA/SHA-256.** Algorithm 8 keys are larger than ECDSA P-256 keys. Akamai also publishes an HTTPS record that carries only an alias. - **infoblox.com uses 10 NSEC3 iterations.** RFC 9276 says zero provides the same security. The other five zones with an `NSEC3PARAM` record all use zero. The extra hashing costs the resolver CPU on every negative answer, for no security benefit. - **forcepoint.com answers differently per address.** Eight IPv6 addresses cap at TLS 1.2; two IPv4 addresses offer TLS 1.3. - **63 names publish no CAA record.** Fortinet, Intel, IBM, Palo Alto Networks, Splunk, and McAfee are in that group. - **75 names leave the zone unsigned.** Leidos, Booz Allen Hamilton, Lockheed Martin, and Northrop Grumman are in that set. Companies with substantial U.S. government contracts, running unsigned DNS. ## What real security vendors should do 1. **Publish CAA records with `issue` and `issuewild` tags.** Name the CAs you use and add an `iodef` address. 63 names on this list publish nothing, and two publish a record that actively restricts nothing. 2. **Sign the zone, then publish CDS and CDNSKEY.** The zone signature protects every answer a client receives. CDS and CDNSKEY let the parent follow a key rollover without the manual step that causes DNSSEC outages. 3. **Retire TLS 1.2.** 11 names on this list still cap there, and post-quantum key exchange requires TLS 1.3. A TLS 1.2 endpoint can't reach hybrid ML-KEM at all – full stop. 4. **Add X25519MLKEM768 to the negotiated group list.** 20 names accept a classical group from a client that offers hybrid ML-KEM. Test with a client that requires the post-quantum group, because the `pq-only` dial is the one that fails first and reveals the gap. 5. **Publish an HTTPS record with `alpn` and `ech`, and deploy ECH.** One name out of 100 deploys ECH. The DNS record is cheap but I'll ack that the handshake support does take some work. 6. **Publish TLSA records for the hosts where you run TLS.** Nobody on this list does. DANE checks the binding in DNS and skips the CA trust path entirely – but it needs a signed zone to carry weight, which brings us back to item 2. *Source data and scripts coming once I get over the fall 2026 vax regimen.* ```json [ { "@context": "https://schema.org", "@type": "BlogPosting", "@id": "https://ai.rud.is/posts/2026-09-11-what-100-cybersecurity-vendors-do-about-tls-and-dns-post-quantum-dnssec", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://ai.rud.is/posts/2026-09-11-what-100-cybersecurity-vendors-do-about-tls-and-dns-post-quantum-dnssec" }, "headline": "What 100 cybersecurity vendors do about TLS and DNS: post-quantum πŸ‘πŸΌ, DNSSEC πŸ”΄", "datePublished": "2026-09-11T10:00:00Z", "description": "67 of 100 cybersecurity vendors support post-quantum key exchange, but 75% leave DNS unsigned and not one publishes a TLSA record. A census of the Cyber 100 across TLS and DNS posture.", "url": "https://ai.rud.is/posts/2026-09-11-what-100-cybersecurity-vendors-do-about-tls-and-dns-post-quantum-dnssec", "keywords": [ "post-quantum", "dns", "dnssec", "tls", "cybersecurity", "internet-standards", "research" ], "author": [ { "@type": "Person", "name": "hrbrmstr", "url": "https://rud.is" } ], "publisher": { "@type": "Organization", "name": "hrbrmstr", "url": "https://ai.rud.is/", "sameAs": [ "https://mastodon.social/@hrbrmstr", "https://bsky.app/profile/hrbrmstr.bsky.social", "https://github.com/hrbrmstr", "https://sr.ht/~hrbrmstr" ] } }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "item": { "@id": "https://ai.rud.is/", "name": "ai.rud.is" } }, { "@type": "ListItem", "position": 2, "item": { "@id": "https://ai.rud.is/posts/2026-09-11-what-100-cybersecurity-vendors-do-about-tls-and-dns-post-quantum-dnssec", "name": "What 100 cybersecurity vendors do about TLS and DNS: post-quantum πŸ‘πŸΌ, DNSSEC πŸ”΄" } } ] } ] ```