Change the nameservers and leave the previous host's DS at the registrar, and 8.8.8.8 stops answering the domain. The address is still published. The machine still accepts connections. A resolver that checks DNSSEC looks at the parent, finds a hash of a key this zone no longer publishes, and returns SERVFAIL.
With no DS in the parent, that same resolver returns the record. When the DS and the key disagree, the resolver withholds the answer. Google Public DNS and Cloudflare's 1.1.1.1 both validate, so the failure shows up on phones and on any other device pointed at those addresses. A resolver that skips the check still loads the site, which is why the report you get is "it works for me."
The parent is holding a hash
The chain starts at a key shipped inside the resolver, the root trust anchor. The root signs a DS for the TLD. The TLD signs a DS for your domain. That DS is the string you paste at the registrar. Ours is digest type 2, SHA-256, over an algorithm 13 key.
The zone publishes the key as a DNSKEY, and a signature, the RRSIG, over each set of records. The resolver hashes the DNSKEY, compares the hash to the DS, checks the signature on the A record, and then hands the address to the stub. Drop a link and the resolver stops there.
dig example.com A @8.8.8.8 shows the failure as SERVFAIL. Add +cd and you are asking that resolver to skip validation and return whatever the nameserver said. An answer with +cd, and SERVFAIL without it, means the chain is wrong and the host is up. A dead host fails both queries.
dnssec-failed.org is a public name kept in that state so the two queries have somewhere to land. dig dnssec-failed.org A @8.8.8.8 returns SERVFAIL. The same query with +cd returns an address. The parent still publishes a DS, and that DS does not match a DNSKEY the zone publishes. The digest in the DS is the sentence "broken chain of trust send help!" rather than a hash of the current key.
When a name is missing, a signed zone answers with NSEC3, a span of hashes standing in for the missing name. Plain NSEC used to name the neighboring labels in alphabetical order, which handed anyone walking the zone a free copy of it. NSEC3 hashes those names. Someone patient can still guess. Signing creates that record. On the DNS zone in NodeRings, the Records tab leaves it off the list you edit. The DS you paste is on the DNSSEC tab of that same zone.
Algorithm 13 is a packet-size decision
Algorithm 13 is ECDSA on the P-256 curve, with SHA-256. The signature is 64 bytes. A 2048-bit RSA signature, still sitting on plenty of older zones as algorithm 8, is 256 bytes before the rest of the answer is counted.
DNS still prefers UDP. The size operators try to stay under, so the packet survives the path without fragmenting, is about 1232 bytes. A 256-byte signature spends a fifth of that on one RRSIG. The answer spills, the resolver tries again over TCP, and that retry is what people remember as DNSSEC being slow. The P-256 signature fits in the first packet. The check runs at the resolver, which caches the validated answer for the TTL, so the next lookup from that resolver is a cache hit.
We sign with algorithm 13, use NSEC3 for the absence proof, and show one SHA-256 DS. Some registrars will not take a DS. They ask for the DNSKEY and hash it themselves. The DNSSEC tab on the zone shows both strings. Paste whichever field that form wants. Either way the parent ends up holding a digest of the same key.
The move that takes the site down
It breaks in a dull order, which is why the dull order gets skipped.
The domain is already signed at the previous host, so the parent has their DS. You create the zone here, point the registrar at ans1.nrings.io and ans2.nrings.io, and leave the old DS in place because turning DNSSEC off feels like a step backwards.
The new nameservers are signing with a different key, or serving an unsigned zone while you wait. The parent still tells every validating resolver to require the old key. People on 8.8.8.8 and 1.1.1.1 get SERVFAIL. Someone on a resolver that skips validation loads the site and tells you it is fine. Leave the old nameservers in the list beside ours and it flickers, because some queries still land on the host whose key matches the DS.
Remove the DS at the registrar first. Wait until a query to the TLD servers comes back empty. For a .com name that query is dig example.com DS @a.gtld-servers.net. Parent TTLs run long, often a day, sometimes two. Empty means the parent is empty. A recursive resolver can cache the old DS after that, but you need the parent itself clear before the nameservers move.
Then set only those two nameservers. The Nameservers tab has the pair to copy, and a button once you have saved them at the registrar. The badge stays on Waiting for NS until the parent publishes our NS, then Delegation verified, and the zone goes Active.
Then sign. Enable DNSSEC. Copy the DS. Put it back at the registrar. Click Check parent DS. The badge moves from Unsigned, to Signed (add DS at registrar), to Signed (DS at parent) once that hash is visible above the zone.
Coming off DNSSEC is the same walk backwards. Delete the DS, wait until the parent query is empty, then Disable DNSSEC. Disable while the DS is still published and you get the same SERVFAIL, pointed at your own zone. The force checkbox is for the lag after the parent is already empty and our check is behind. If the DS is still at the registrar, leave the box alone and wait.
The check beside the certificate
DNSSEC is the address being the one you published. The lookup is still readable on the path from the stub to the resolver to the nameserver. TLS is the other check, the machine proving it may speak for that name. A forged A record sends the browser to the wrong host before the certificate is even offered. A right address with nothing checking the certificate is a different problem, the right machine and an open conversation. Use both when the name matters.
Hosted DNS sits on the account, and the signing controls are the DNSSEC tab once the zone is Active. The clicks are in the DNSSEC guide. The same zone can answer differently by location. That problem is about who the nameserver thinks is asking, which is GeoDNS follows the resolver.