Background: DNSSEC in reality is couple of security keys and several DNS records that should exist in addition to your normal DNS records. Those reside in two places:
- Authoritative DNS server for your domain. This holds the DNSKEY, RRSIG and NSEC/NSEC3 records.
- Authoritative DNS server for your parent domain ("com" domain for example.com). This holds DS records.
Private keys themselves can actually be stored anywhere (or even deleted after they used to sign all that have to be signed), but normally they will also reside somewhere on the domain authoritative server.
Now, the answer to your question depends on how your DNS provider will implement DNSSEC support.
In simpliest (for you) scenario, DNS hosting will do all the work (creating KSK and ZSK keys, publishing DNSKEY records, signing and automatically resigning zone file with RRSIG and NSEC/NSEC3 records, and preparing DS key that you will send to your registrar).
(As you see it requires support not only from your DNS hosting but also from your registrar. ICANN maintains list of DNSSEC supporting registrars)
You in this case will only have to copy DS key provided by your DNS hosting and send it to your registrar (hopefully via web interface or by any other means that your registrar supports).
P.S. As you see, the whole process have nothing to do with your computer(s) nor with any OS which you run, be it debian or windows, heaven forbid.
Issue resolved. It was a problem at GoDaddy's end.
I created a ticket and received the following reply after 61 hours.
Our validation web service calls out to the registrar back-end web service, which calls out to the registry for DNSSEC validation. Many times the call to the registry times out. This is most likely why you were receiving errors.
If the person on the chat had told me this it would've saved me a lot of time and also the need to create a topic here.
Best Answer
No, it is not sufficient to just remove the configuration locally on an authoritative name server.
DNSSEC is a hierarchical system, chain of trust agains DNS cache poisoning.
Example of a Chain of Trust:
The zone itself is signed with the private key on your primary authoritative name server, e.g.
ns1.example.com.
has the private key for signingexample.com. A
withexample.com. RRSIG A
.The public key of
example.com.
has been sent to and confirmed by the authority forcom.
, which then has it inexample.com. DS hash
and correspondingexample.com. RRSID DS
, signed with private key for.com.
The public key of
com.
has been sent to and confirmed by the root authority, which then has it incom. DS hash
and correspondingcom. RRSID DS
, signed with private root key i.e. key for.
, aka Root Zone Trust Anchor:You can get a nice visualization of any domain with DNSViz. It also detects configuration errors.
Therefore, the authority responsible of the TLD must be contacted, probably through the registrar, and informed that DNSSEC should be disabled for the domain. They will disable DNSSEC by removing the chaining
DS
record from their nameservers. Otherwise DNSSEC will still be enabled, causing your authoritative name server to be seen as a rogue name server.