Test rig

resolving correctly

weliketotestthings.com

A disposable domain standing in for a production one, used to rehearse a DNSSEC-signed delegation and a registrar account ownership change before doing either for real.

If you can read this, the delegation works. The request reached GitHub Pages by way of a signed zone served from Google Cloud DNS — every hop below resolved.

The chain under test

01
Registrar holds the delegation Namecheap → NS + DS at the .com registry
02
Authoritative DNS answers ns-cloud-*.googledomains.com
03
Zone is signed, chain validates DS at parent → DNSKEY → RRSIG → AD flag
04
Records point at the origin A → 185.199.108–111.153 · www → CNAME
05
Origin serves over TLS GitHub Pages, Let's Encrypt certificate

Why this exists

Changing which account holds a domain is irreversible, and the registrar UI gives no preview of what it will do to the nameservers, the DS record, or the transfer-lock status. So it gets rehearsed here first, on a name nobody depends on.

The question being answered: does a hand-entered DS for an externally signed zone survive an account ownership change intact?

Check it yourself

Delegation
dig NS weliketotestthings.com @a.gtld-servers.net +short
Chain of trust
dig DS weliketotestthings.com @a.gtld-servers.net +short
Validation
dig A weliketotestthings.com +dnssec @8.8.8.8
Registry record
rdap.verisign.com/com/v1/domain/weliketotestthings.com

A validating resolver sets the ad flag when the chain holds. If the DS is removed but the zone stays signed, the name goes insecure and still resolves. If the DS survives but points at the wrong key, it goes bogus and stops resolving entirely — which is the failure this rehearsal exists to rule out.