Big Tech’s Unsigned Domains Put DNSSEC Back in the Spotlight

Trend Observation

A GitHub post noting that aws.com and google.com return unsigned DNSSEC answers landed because it violates an instinct many developers have about infrastructure brands. AWS and Google sell DNS, cloud security, identity, certificate tooling, and global traffic systems. Seeing their own high-profile domains appear unsigned feels, at first glance, like finding a missing seatbelt in a safety demo.

The observation is not that DNSSEC is unavailable from these companies. AWS documents DNSSEC signing in Amazon Route 53, and Google Cloud DNS has a DNSSEC overview explaining zone signing, DS records, and resolver validation. The tension is different: providers can offer DNSSEC to customers while choosing not to sign every one of their own corporate apex domains.

That distinction is where the developer conversation gets interesting. The reaction is partly security concern, partly surprise, and partly a familiar infrastructure shrug. DNSSEC is one of those technologies that many engineers agree with in principle, then hesitate to operate at scale. The consensus is easy at the whiteboard: DNS answers should be cryptographically authenticated. The consensus gets less stable when the domain is globally critical, managed across many teams, routed through multiple systems, and expected to survive registrar changes, key rollovers, CDN migrations, and emergency traffic moves without a public outage.

Evidence

The supplied transcript shows the core pattern: delv amazon.com and delv aws.com return unsigned answers, delv google.com also returns unsigned, while delv cloudflare.com returns a validated answer with an RRSIG. A public check from Verisign’s DNSSEC Debugger currently reports no DS records for google.com in the .com zone, while the same tool finds a DS record and signed A records for cloudflare.com. That difference matters because the DS record is the parent-zone link that lets a validating resolver build a chain from the DNS root to .com to the child domain.

DNSSEC itself is not obscure magic. RFC 4033 describes it as adding data origin authentication and integrity to DNS, while also making clear that it does not provide confidentiality. In practical terms, a signed zone publishes DNSKEY records and signatures over record sets. The parent zone publishes a DS record that points to the child zone’s key. A validating resolver checks that chain. If the signatures line up, the resolver can say the DNS answer was not silently changed between the authoritative source and the resolver.

If the parent zone has no DS record for a child domain, the result is usually not a hard failure. The delegation is treated as unsigned. That is why google.com can resolve normally while still not getting DNSSEC authentication for its answer. The web keeps working, but a validating resolver cannot cryptographically prove that the A or AAAA records for that name came from a signed google.com zone.

The more subtle evidence is in vendor documentation. AWS warns that enabling DNSSEC in Route 53 brings operational obligations: key-signing keys, KMS dependencies, monitoring alarms, TTL constraints, and limits around multi-vendor configurations. Google’s Cloud DNS documentation says full protection requires three aligned pieces: the DNS zone, the TLD registry with a DS record, and a resolver that validates signatures. Cloudflare’s DNSSEC docs present a cleaner user-facing flow, but even there the process still depends on adding DS material at the registrar unless Cloudflare can automate that path.

That explains why the post resonated. It exposes a split between capability and adoption. DNSSEC is supported by major platforms, validated by public resolvers such as Google Public DNS, and visibly deployed by Cloudflare on its own domain. Yet some of the most security-literate companies on the internet still leave highly visible domains unsigned.

What Developers Are Reading Into It

One camp sees this as an embarrassing gap. Their argument is straightforward: if a company operates foundational internet infrastructure, its main domains should model the security posture it recommends to others. DNSSEC is not new. The DNS root has been signed for years, .com supports DNSSEC, and modern managed DNS platforms can automate much of the signing work. From this view, unsigned corporate domains send the wrong signal, especially when those same companies publish guidance about preventing spoofing, cache poisoning, and domain hijack paths.

This group also points out that HTTPS does not make DNSSEC irrelevant. TLS protects the connection after the browser reaches an IP address and validates a certificate. DNSSEC protects a different layer: the authenticity of the DNS data itself. Those layers overlap in some threat models, but they are not substitutes. DNSSEC also enables record types and patterns such as SSHFP, TLSA in DANE deployments, and stronger authentication for records beyond web A and AAAA lookups.

Another camp treats the finding as less shocking. They argue that the practical attack surface for a domain like google.com or aws.com is already constrained by certificate transparency, HSTS, browser certificate validation, resolver hardening, registrar controls, monitoring, and fast incident response. Google’s own Public DNS security documentation describes DNSSEC validation, but it also lists other anti-spoofing measures such as source-port randomization, query matching, and response filtering. In that reading, DNSSEC is valuable, but not the only control standing between users and a forged destination.

There is also an operations argument that does not fit neatly into security slogans. DNSSEC can fail closed. A bad DS record, expired signature, broken key rollover, registrar mismatch, or migration mistake can make a domain disappear for validating users. The failure mode is not cosmetic. For a global apex domain tied to login, support, billing, software distribution, cloud consoles, and incident communications, the downside of a signing mistake can be severe. Security engineers may still prefer signing, but reliability teams will ask whether the risk reduction justifies the added failure modes.

The Pattern Behind The Debate

The broader pattern is that infrastructure security is no longer judged only by feature availability. Developers increasingly look for adoption signals from the vendors themselves. If a cloud provider says a control matters, the community expects to see that control used on the provider’s own critical assets. That expectation has grown stronger in areas like passkeys, SBOMs, SLSA provenance, hardware-backed signing, reproducible builds, and now DNSSEC.

But DNSSEC occupies an awkward position. It is mature enough that engineers can reasonably ask why it is missing. It is also operationally sharp enough that large organizations may decide not to apply it uniformly. This is why the Cloudflare comparison gets attention. cloudflare.com validating successfully is not just a technical fact. It functions as a public adoption signal from a company whose brand is tied to DNS. It shows that signing a high-profile domain is possible, visible, and defensible.

The counter-signal from AWS and Google is harder to interpret. It may reflect historical domain architecture, internal risk assessment, registrar constraints, traffic-management complexity, or simply prioritization. Without an official explanation for these specific domains, outsiders should be careful about turning a DNS query into a full security verdict. An unsigned DNSSEC answer is a real fact, but it is not a complete audit.

Counter-Perspectives

The strongest counter-argument is that DNSSEC’s security benefit depends on validation. If the user’s resolver does not validate DNSSEC, signed records do not help that user directly. Many users rely on ISP resolvers, enterprise DNS layers, VPN DNS, local forwarders, or application-specific resolution paths. Some validate, some do not, and some rewrite or filter responses for policy reasons. DNSSEC improves the system only when enough of the chain participates.

Another counter-argument is that DNSSEC does not hide queries. DNS over HTTPS and DNS over TLS protect the path between client and resolver, while DNSSEC authenticates data from authoritative DNS. They solve different problems. A domain can be signed and still leak query metadata unless the client uses an encrypted transport to a resolver. A client can use DoH and still receive data for an unsigned domain that lacks DNSSEC authentication. Treating any one of these as the full answer usually leads to overconfidence.

There is also the problem of operational centrality. DNS is a dependency for everything above it. Signing a domain creates new dependencies on key custody, signing infrastructure, registry state, monitoring, and emergency procedures. For ordinary domains, managed DNS can make that manageable. For hyperscale corporate domains with many internal owners and historical systems, the migration may be more complicated than the outside view suggests.

None of these counterpoints erase the criticism. They just make the criticism more precise. The better question is not whether AWS and Google know DNSSEC exists. They plainly do. The question is why their own public apex domains are not carrying the same cryptographic assurance that their platforms can provide to customers, and whether that choice still makes sense in 2026.

What Changes

For most developers, nothing breaks because of this discovery. Browsers still reach these sites. TLS still validates certificates. Public resolvers still apply anti-cache-poisoning defenses. The internet has lived for a long time with partial DNSSEC adoption.

What changes is the visibility of the gap. A short command-line transcript turned a background protocol decision into a community trust signal. That is the real trend: developers are increasingly auditing the defaults and public posture of infrastructure vendors, not only reading their docs. The result is often uncomfortable for vendors because it collapses marketing, architecture, and operations into one observable artifact.

The most balanced read is that unsigned aws.com and google.com should be treated as a meaningful security discussion, not a panic headline. DNSSEC would add a layer of DNS integrity for those names. It would also add operational duties that large providers may have judged differently. The community’s skepticism is useful precisely because it asks both sides to be more specific: what threat is being accepted, what control replaces it, and why should users consider that trade-off reasonable?