[Yeri]

(CF TAM here)

All plans come with support. Even the free plans (community, or email, the bot will deflect the request but if you email you're still stuck, you will get a reply _eventually_ (due to heavy support load, it can take a while though).

The correct procedure would be:

* turn off DNSsec on old registrar (and wait a day or two)

* update NS and/or migrate domain

* wait a while and make sure it works

* turn on DNSsec in CF dash and update DNSsec settings in the domain

It's not that DNSsec doesn't work -- it's doing exactly what it's supposed to be doing.

[mike_d]

The correct steps are to completely disable DNSSEC and remove the relevant records. It is far too fragile for the majority of use cases. Effort should instead be put into deploying things like DNSCrypt that implement transport security and confidentiality.

Transport security is like HTTPS. DNSSEC was the equivalent of PGP signing every webpage. The former brings value to the end user, the latter not so much.

Even the government has issued memo M-18-23 ("Shifting From Low-Value to High-Value Work") that rescinds the requirements for the government to implement DNSSEC.

[cryptonector]

I want both, DNSSEC and DNSCrypt.

WebPKI is a joke because it lacks name constraints and so isn't and can't be hierarchical. DNSSEC is a true PKI -- you can still have multiple roots if you like and don't trust ., but it's got name constraints, so whatever domain you graft an alternate PKI at, from there on down you get bound to that PKI. This is really, truly fantastic.

Add DANE and you have a complete replacement for WebPKI.

DNSCrypt is needed to increase confidentiality, it's cheaper than DNSQuic and such things. Unfortunately .'s and com's and major TLDs' NSes are unlikely to want to waste CPU cycles on any DNS confidentiality solution, and even if some TLDs did, unless clients use QName minimization, users gain no confidentiality -- . and the TLDs all have to adopt it.

The two, together, would be truly fantastic.

[mike_hearn]

DNSSEC is however the only way you can make TLS really work. The whole TLS ecosystem is dependent on CAs that are basically just a giant hack. They're signing a statement that they did a bunch of DNS resolutions at a point in time from different network vantage points (maybe, hopefully), and got consistent answers. DNSSEC+DANE lets you get the actual data you want (domain name->public key binding) from the root source, without needing the complicated middlemen.

[mike_d]

DNSSEC+DANE is an affirmation by the United States government that you have followed a chain to an answer about a certificate pinning. Handshake (www.handshake.org, Trigger warning: crypto) will give you what you are talking about (CA non-reliance) anchored in the owner of the website itself.

If you aren't a fan of DV certificates (as you point out verified by resolution), you can always restrict your trust store to only CA certificates that sign EV certificates (verified by business records).

[cryptonector]

The root zone doesn't change often. You can pin . or even run your own private . with pinned . content if you don't trust the root.

If you do, then you get MITM protection.

If you don't, but choose to use QName minimization, you still get a modicum of MITM protection: because the attacker would have to choose to get in the middle without having enough knowledge of whether a particular upcoming TLS connection (or whatever) will be of particular interest.

Really, DNSSEC is infinitely better than the WebPKI, even WebPKI+CT, especially when DNSSEC clients use QName minimization, and even more so when clients pin copies of . from time to time.

[Spunkie]

I mean when you are adding a new domain, CF can clearly tell if a domain already has dnssec on or not. Seems like something that should raise a warning to the user.

[medguru]

That would have been very helpful. The [Enable DNSSEC] button in the control panel is very assertive and confident through its casual and innocuous appearance.

Source: me, having lost access to my domain for 4 days for reasons that are not yet fully clear to me.