Work at the CA/Browser Forum (DNSSEC Ballot SC-085v2) Directly Mitigating an Attack

[Henry Birge-Lee]

Hi all,

I wanted to bring up an interesting instance where recent work at the CA/Browser Forum (specifically the DNSSEC ballot SC-085v2) is directly cited as helping to mitigate the damage from a real-world attack.

On 2026-04-17, the crypto service eth.limo (a web3 DNS company) suffered a DNS hijack that involved the adversary malicious updating nameservers to gain control of eth.limo’s operations. However, eth.limo used DNSSEC and DNSSEC-validating recursive resolvers had cached eth.limo’s DS records. Thus, DNSSEC-validating recursive resolvers required a proper signature from eth.limo’s true DNSSEC key which the adversary did not have access to. During the attack, DNSSEC-validating resolvers returned SERVFAIL for the domain. Non-DNSSEC-validating resolvers on the other hand followed the malicious NS records and returned adversary-controlled records.

In eth.limo’s post-mortem ( https://x.com/eth_limo/status/2045552916157563148 ), they explicitly call out two CA/Browser Forum initiatives: CAA checking and DNSSEC validation of DCV and CAA (Ballot SC-085v2). Eth.limo uses this as justification/evidence to show that no valid TLS certificate could have been signed during the incident. I can say that without the ballot and the status quo our research team observed prior to the ballot’s passing, even a moderately determined adversary could have easily found a CA not validating DNSSEC which might have signed malicious certificates in these circumstances. Furthermore, eth.limo was alerted to the incident via downtime notifications. Had the adversary successfully escalated its attack to a true TLS MitM, the incident could have gone undetected for longer and caused substantially more damage. While it's hard to say with complete certainty, it appears likely that the passing of the DNSSEC ballot significantly mitigated the damage of this attack.

I want to take a moment to thank everyone who supported this proposal and helped make my original ballot draft a reality as SC-085v2 (including but not limited to Clint Wilson for proposing the ballot and Wayne Thayer, Dimitris Zacharopoulos, and Ryan Dickson for being endorsers). I also want to thank the CA/Browser Form participants as a whole. Often working on these standards is tireless work, and by the nature of web PKI being a preventative technology, this work is not always front and center in news headlines. This is a nice example where eth.limo took the time to read the standards and cite the particular initiatives that helped protect their platform and lead to zero malicious TLS certificates as a result of the DNS hijack. I hope this helps remind everyone of the importance of continuing to improve the standards and the state of TLS certificate issuance.

Best,

Henry

[Jacob Hoffman-Andrews]

Hi,

Great to see recognition for the DNSSEC work!

I want to be clear about the threat model, though. I think this is actually a case of attackers not fully understanding their capabilities. They could have achieved issuance if they had. Since the attackers controlled the registrar account and could change the NS records, they could also change the DS records.

It's not clear from the post-mortem whether the attackers actually changed the DS records, since it only mentions changes to the NS records. The post-mortem does say "validating resolvers checked the attacker's responses against the legitimate DS record still cached from the parent zone."

In the hypothetical where the attackers did change the DS records but were thwarted by caching: caching helps if a CA's resolver has recently resolved the domain name in question. Which for almost all CAs won't be the case. Even for a CA that has recently resolved the domain name, there is no guarantee the DS record remains cached for its full lifetime.

Also, a moderately patient attacker could change the DS records and wait for the TTL of the old DS records to expire before doing anything else.

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/1e6c97f4-d05c-4112-86dc-2fad420f7d43n%40groups.cabforum.org.

[Henry Birge-Lee]

Hi Jacob,

I am glad you brought these points up. I think they are important angles worth discussing. I did wanted bring up a couple points.

Regarding attacker capability to change NS but not DS records: I agree that given the registrar account compromise the attacker most likely had the ability to change DS or NS records, but I will point out there are scenarios where the attacker can only manipulate NS records. DS records are cryptographically signed as part of the DNSSEC-trust chain. NS records even for DNSSEC domains are unsigned (see the attached screenshot). Thus if DNSSEC keys were kept offline and an adversary compromised online DNS infrastructure, the adversary could tamper with NS and not DS records.

I agree the post mortem is ambiguous if the DS records were changed.

Per caching I would argue the situation is actually a bit more complex... Prior to MPIC in the universe where all CAs needed to run 1st-party DNS, I agree if CA A had not signed a cert for an eth.limo domain it would be unlikely to contain recent DS records in its cache. However, MPIC permits the use of 3rd party DNS resolvers. Furthermore, many CAs are using the same 3rd party DNS: Amazon (this is inherited by use of Open MPIC AWS-lambda). Thus there is some chance of cache sharing and a popular domain that recently got certs (or just had lookups by the AWS DNS resolver) may hit a cache on MPIC. I would argue that in the AWS-default DNS resolvers (which are the ones used out of the box by open-MPIC AWS-lambda as well as other AWS tenants), there is a legitimate cache hit probability. Delegation records also tend to have long caches. There is precedence for cash stickiness being considered a security measure in DNS as it was previously used to justify DNS's low 16-bit TXID entropy (although the kaminsky utilized optimistic cach updating to bypass this). Obviously relying on caching is not an ideal security measure, but it does impact the nature of the DNS.

Regarding attacker patience: I don't completely agree with this stance. eth.limo was alerted to the attack via outage detection. Many attacks I have studied were detected in a similar matter. There is a large difference between: 1) the adversary hijacking DNS and then upgrading to a true stealthy TLS interception attack that many orgs are not currently monitoring for and 2) the adversary hijacking DNS only to induce an outage for the duration of the DS TTL. Silent TLS interception requires a good amount of complexity for a security team to diagnose and know where to look and it's likely no one will even be alerted that there is a problem since the application-layer checks checks still show green. A complete outage due to no TLS certs gets detected by any uptime monitor (similar to the way eth.limo cought it) and immediately gets a response. I argue a delay on the order of a TTL is a good security outcome.

Best,

Henry

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAN3x4Qkzr_wzZSuGo0vHdr6jTgJgAGdmWqQs-Yd081Z%2Bu3KO1w%40mail.gmail.com.

[Sebastian Robin Nielsen]

You are wrong about DS records being untamperable if the signing key is offline. This because any DS update requested via the registrar panel will be signed by the registry, unless the domain has a registry lock (clientUpdateProhibited).

This means, even if the DS private key is held offline, an attacker taking control of the domain can easily replace the DS records with DS records for a key he owns.

Registry usually checks if a DNSSEC chain can be built, but if the attacker changes NS and DS at the same time, the change will go through as a chain can be built to attacker's server. This is usually just a sanity check so the domain owner don't accidentially misconfigure DNSSEC.

So this is a problem that has to be solved on the registry level (better autentication methods for updating domains like SMS and TOTP codes independent of the registrar).

Thus something ICANN would have to do - Enforce stricter authentication methods for TLD operators so even if a attacker takes control of the registry panel (domain panel inside web hotel) he cannot update NS, Glue or DS without additional TOTP or SMS authentication requested by the registry (TLD owner, for example iis.se for .se, and VeriSign for .com, or PIR.org for .org) in this way a web hotel (registrar) with bad domain security don't compromise a domain.

Best regards, Sebastian Nielsen

-------- Originalmeddelande --------

Från: Henry Birge-Lee <henryb...@gmail.com>

Datum: 2026-05-15 20:33 (GMT+01:00)

Till: server...@groups.cabforum.org

Ämne: Re: [Servercert-wg] Work at the CA/Browser Forum (DNSSEC Ballot SC-085v2) Directly Mitigating an Att

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAGxVKU4hE9_7M8JsEXk%3D%3DAq7ZAPiQuVfvosqbE_ABmT0Qnpp6Q%40mail.gmail.com.

[Henry Birge-Lee]

Hi Sebastian,

To be clear my statement was "there are scenarios where the attacker can only manipulate NS records."

In your reasoning you implicitly assumed an online registry and a compromise of the domain owner's registrar. When I was referring to the keys being kept offline, I mean the Zone Signing Key used by the register to sign DS records. For certain compromises of DNS operations (say an access-control failure at a regional PoP), an NS record could be manipulated and a DS record would be protected.

Specifically:

adversary can likely adversary can only manipulate NS records

impact NS and DS records as DS record manipulation would lead to invalid RRSIGs

│ │

▼ ▼

┌────────────────────┐ ┌────────────────────┐ ┌──────────────────────────────────────┐

│ Domain owner │ │ DNS registry │ │ Globally-deployed │

│ registrar │─────>│ with HSM for │─────>│ authoritative DNS resolvers │

│ account │ │ DNSSEC key │ │ serving presigned zones │

└────────────────────┘ └────────────────────┘ └──────────────────────────────────────┘

If a DS record is signed by a register's Zone Signing Key and the Zone Signing Key is truly offline (not in an online HSM to handle requests from Extensible Provisioning Protocol but in a vault like the actual ICANN root keys are), then there is no way to update a signed DS record via a client request. I know most registers don't operate like this to let people make dynamic changes to DNSSEC delegations, but the protocol does permit this.

Best,

Henry

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/E1wNy6R-0004O2-71%40sebbe.eu.

[Sebastian Robin Nielsen]

For what I know, 0 registry operate like this. I could only envision one single TLD operator operating like this (if they do, I don’t know) and that is .gov

They could keep their signing keys offline and only allow updates via for example phone or snail mail where everything is checked and double checked via callbacks, and then the DS record is signed in a ceremony.

If there came a new TLD that only licensed banks were allowed to use, like .bank (like chase.bank, paypal.bank or visa.bank or mastercard.bank) im pretty sure they would operate like this aswell.

 

But otherwise, an possibility to modify NS records implies possibility to modify DS records, since they are edited in the same panel.

Thats why I said that compromise of registrar (or registry) always means compromise of DNSSEC.

 

So even if the protocol allows this and its technically possible, it would not be feasible for the ”normal domain owner” to have to authenticate out-of-band (via phone or snail mail on business hours) to their registrar or registry to make changes to their domain, it would piss off hobbyists pretty much, especially if they make a small error in their config or if their DNS server decide to change IP suddently.

When you say ”globally deployed authoriative DNS servers” I suggest you mean mirroring of DNS, like zone transfers to registry servers all over the world like anycast. In that case, it would protect, but such an attack would not be feasible anyways, since an attack on a local POP/DNS server would give limited ”bang for the buck”.

 

An attacker would take the easiest target – registrar control panel. Espeically smaller ICANN accredited web hotels usually have crappy security, and if a high value domain is there, some ”hack-hack-hack” there and you score it for all authorative DNS servers over the whole world both for DS and NS.

One thing that WOULD fix ICANN accredited registrars with crappy security, would be a simple registry mechanism where you have to enter a TOTP or SMS code to approve a domain change. Then it wouldn’t matter if you can log into any doman owners account with a’ or ’’=’ , you would never be able to make any change that would be pushed to the registry, since the registry would independently authenticate the customer, instead of blindly trusting the registrar.

 

Best regards, Sebastian Nielsen

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CAGxVKU56H1MzhceEPr_-NkxrdVy1gDk1fTkW8U_jKH%2Bx1qx5DA%40mail.gmail.com.

[Jacob Hoffman-Andrews]

Regarding attacker patience: I don't completely agree with this stance. eth.limo was alerted to the attack via outage detection. Many attacks I have studied were detected in a similar matter. There is a large difference between: 1) the adversary hijacking DNS and then upgrading to a true stealthy TLS interception attack that many orgs are not currently monitoring for and 2) the adversary hijacking DNS only to induce an outage for the duration of the DS TTL. Silent TLS interception requires a good amount of complexity for a security team to diagnose and know where to look and it's likely no one will even be alerted that there is a problem since the application-layer checks checks still show green. A complete outage due to no TLS certs gets detected by any uptime monitor (similar to the way eth.limo cought it) and immediately gets a response. I argue a delay on the order of a TTL is a good security outcome.

We're in agreement that changing A records and thus breaking renewals is a noisy operation.

What I mean by a patient attacker is this:

 - attacker changes DS record to attacker-controlled key.

 - attacker signs pre-existing records with no changes.

 - attacker waits for the TTL of the previous DS records to pass

 - attacker changes existing A records to point at their own servers, and signs the updated records with their own key.

 - attacker gets a TLS certificate and starts proxying traffic to the original servers.