Quick heads-up for domain investors: DNSSEC can be a useful security feature when you run and control a live website and its DNS signing, but in the domain aftermarket it's usually a problem rather than a benefit. A leftover DNSSEC setting from a previous registrant can make your lander invisible to a chunk of visitors and can break verification checks at marketplaces or other services. Treat DNSSEC as something to leave off on landers, unless you know exactly how to manage it end to end.
This issue is especially common in the domain aftermarket. Expiring domains that once had DNSSEC enabled often keep the DS record set at the parent zone after they are transferred. Many investors do not notice that leftover DS records remain in place, so a domain that looks fine can still fail for visitors whose resolvers validate DNSSEC. In plain terms, a DS record is a flag in the parent zone that says the child zone is signed. If that flag is present but the domain is not actually serving valid signatures, validating resolvers treat that as a security error and refuse to return records, making your lander unreachable for those visitors.
You will see inconsistent behavior because not all DNS resolvers enforce DNSSEC. Some visitors and some verification systems use permissive resolvers that ignore the DNSSEC error and reach the lander, while stricter systems and validating resolvers will fail. This is why the same verification can pass when checked by permissive resolvers but fail when a strict, validating resolver is used. The root cause is a mismatch between the parent zone advertising DNSSEC and the child zone not providing valid signatures.
Fixing the problem is straightforward. Check whether a DS record exists for the domain and whether WHOIS or RDAP shows a DNSSEC indicator such as DNSSEC: signedDelegation. If you did not enable DNSSEC yourself and a DS record is present, contact your registrar or use your registrar control panel to remove the DS record. Removing the DS record tells validating resolvers there is no signed delegation and allows them to retrieve A, CNAME, and TXT records normally. After removal, allow a short propagation period and then re-run any verification steps that failed earlier.
This problem usually affects a small number of names in a portfolio rather than every domain, but the impact on those names can be severe because landers become inaccessible to a subset of visitors. In my sample analysis I ran on delegated .com landers, Afternic had 213 domains with DS records out of 72,304, Sedo had 26 out of 10,605, and Atom plus Squadhelp had 165 out of 26,552. Those numbers show this is not rare enough to ignore.
If you want a quick technical check without deep DNS knowledge, use the DNSViz website at https://dnsviz.net/ - Enter your domain there and DNSViz will analyze the delegation and show whether a DS record exists, whether the child zone is signed correctly, and where any validation failures occur. DNSViz presents the results visually and highlights mismatches so you can see at a glance whether a legacy DS record is causing problems and whether you need to remove it at your registrar.
Make checking for and removing legacy DS records part of your standard pre-listing routine. Only enable DNSSEC when you control the full signing chain and can manage key rollovers and signatures reliably. For aftermarket landers, the safest default is DNSSEC off until you are able to operate signing correctly end to end.
Edited to include instructions on how to check your own domain portfolio: post #7 in the comments.
This issue is especially common in the domain aftermarket. Expiring domains that once had DNSSEC enabled often keep the DS record set at the parent zone after they are transferred. Many investors do not notice that leftover DS records remain in place, so a domain that looks fine can still fail for visitors whose resolvers validate DNSSEC. In plain terms, a DS record is a flag in the parent zone that says the child zone is signed. If that flag is present but the domain is not actually serving valid signatures, validating resolvers treat that as a security error and refuse to return records, making your lander unreachable for those visitors.
You will see inconsistent behavior because not all DNS resolvers enforce DNSSEC. Some visitors and some verification systems use permissive resolvers that ignore the DNSSEC error and reach the lander, while stricter systems and validating resolvers will fail. This is why the same verification can pass when checked by permissive resolvers but fail when a strict, validating resolver is used. The root cause is a mismatch between the parent zone advertising DNSSEC and the child zone not providing valid signatures.
Fixing the problem is straightforward. Check whether a DS record exists for the domain and whether WHOIS or RDAP shows a DNSSEC indicator such as DNSSEC: signedDelegation. If you did not enable DNSSEC yourself and a DS record is present, contact your registrar or use your registrar control panel to remove the DS record. Removing the DS record tells validating resolvers there is no signed delegation and allows them to retrieve A, CNAME, and TXT records normally. After removal, allow a short propagation period and then re-run any verification steps that failed earlier.
This problem usually affects a small number of names in a portfolio rather than every domain, but the impact on those names can be severe because landers become inaccessible to a subset of visitors. In my sample analysis I ran on delegated .com landers, Afternic had 213 domains with DS records out of 72,304, Sedo had 26 out of 10,605, and Atom plus Squadhelp had 165 out of 26,552. Those numbers show this is not rare enough to ignore.
If you want a quick technical check without deep DNS knowledge, use the DNSViz website at https://dnsviz.net/ - Enter your domain there and DNSViz will analyze the delegation and show whether a DS record exists, whether the child zone is signed correctly, and where any validation failures occur. DNSViz presents the results visually and highlights mismatches so you can see at a glance whether a legacy DS record is causing problems and whether you need to remove it at your registrar.
Make checking for and removing legacy DS records part of your standard pre-listing routine. Only enable DNSSEC when you control the full signing chain and can manage key rollovers and signatures reliably. For aftermarket landers, the safest default is DNSSEC off until you are able to operate signing correctly end to end.
Edited to include instructions on how to check your own domain portfolio: post #7 in the comments.
Last edited by a moderator:
NamePros Parking had 0 domains with DS records in my sample set.
Bodis had the highest percentage of domains with DS records in the sample set.
Visitors who use DNSSEC validating resolvers might not be able to access any of these domains.
