DNSSEC on .to Domain

Are “.to” domains able to implement DNSSEC on a) Cloudflare NS b) Child NS c) other NS providers?

Essentially no on all counts. The .to domain is not DNSSEC signed, so domains underneath that section of the DNS tree cannot use DNSSEC.

Historically, a technique called DLV could be used to provide DNSSEC in this scenario, but it really is of no use in most situations any more.

How then are “.to” domains able to defend from the types of attacks that DNSSEC prevent (eg: DNS hijacking)?

What defenses does Cloudflare provide to “.to” domains?

i.e. What effective alternative to DNSSEC is there for “.to” domains?

None really. DNSSEC provides proof that the data came from the owner of a zone, and proof that it has not been altered. Those proofs rely on the TLD signing their zone, and allowing you to enter your DS records into the zone. The alternative is to use a TLD that does support DNSSEC, which is over 90% of the other TLDs.

About the only alternative we are able to identify is actually far superior to DNSSEC yet rare rarely used:


Perhaps Cloudflare ought to update to provide DNSCurve on Cloudflare NS and DNSCrypt on Cloudflare DNS, or an independent update on those?

@mvavrusa is probably the best place to get an Authoritative response :wink:

I suspect the ship has sailed on the DNSCrypt protocol. For Client to Resolver the world is rapidly moving to DOH, and DOH is underpinning a number of new protocols like ECH that Cloudflare are involved in.

I recall that some comments were made many years ago that they might support this if it gained some traction. That has not happened, and I believe that there are drafts for Resolver to Authoratitive DNS privacy and authentication protocols. I would not hold my breath on DNSCurve.

Conceptually, something proprietary to include it’s properties and appropriate upgrades.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.