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” 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).

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. 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, so breaking one session requires breaking both algorithms. 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. 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. 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. 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. 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. 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.<name>, and it only carries weight under DNSSEC. An unsigned TLSA record proves nothing – whoever answers the query can forge it.

HTTPS records. 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 (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.

# 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.<name>
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

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.<name>, 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:

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.