I made a domain transfer with DNSSEC enabled to an operator that does not support DNSSEC. The first operator has no option to disable DNSSEC, and I did not think about it anyway. And now I have a problem - the transfer was on Thursday, and the domain up to today is not visible all over the world (including Google's DNS). Could this be due to DNSSEC? Is there a chance to complete the propagation in this situation?

  • 1
    Make sure it isn't a simple DNS issue for starters - to confirm, you've double checked the DNS settings at the new registrar and your domain is still pointed at your server using the same A/CNAME record - but it still does not resolve? – Maximillian Laumeister Nov 24 '18 at 21:00
  • 1
    To the best of my knowledge DNSSEC is supposed to drop out of resolver caches within 48 hours at the very maximum, so this delay is neither normal nor expected. If everything had gone successfully you should be able to see it resolving on most DNS resolvers by now. – Maximillian Laumeister Nov 24 '18 at 21:08

Could this be due to DNSSEC?

Yes, but impossible to be sure as you do not give the domain name involved, not even the TLD (rules change about transfers and DNSSEC data depending on the TLD). Debugging DNSSEC-related problems in the DNS is already a complicated task when you have the name of the broken domain, but without it, this becomes an impossible task.

Even "domain transfer" is not very clear so the answer below will only be generic explanations covering most normal cases.

DNSSEC needs ongoing maintenance

Whatever DNS provider you use to handle your nameservers, if you enable DNSSEC you need to understand that you will have ongoing maintenance that someone will need to do:

  • only directly inside the nameservers, signatures must be regenerated and, for good security practices, keys should be rotated, typically after a few months for ZSKs.

  • if you also change the KSKs (again good security practices, but typically counting in years and not months like a ZSK), it means you will need to change the DS record at the parent zone, which for now means giving this DS to the current registrar so that it forwards it to the registry which then publishes it (there are other schemes currently being cooked to try avoid the registrar in that case, .DK and .CH/.LI have or will have shortly such features)

So the above means: any kind of DNS provider change may have consequences. It is an hard problem, if not done at the correct pace and especially if the old provider does not cooperate. There are RFCs for guidances on that.

DNS provider is registrar, or not

When you buy a domain name, you go typically to a registrar, whose job is to register domain names. Then if you want it to resolve you need DNS service. Registrars are also often DNS providers (including for domain names not registered with them in some cases), but you can as well choose an outside DNS provider.

In that second case, the DNSSEC maintenance is more complicated. If your registrar is also your DNS provider and also maintain all DNSSEC records for you automatically, then you have less to worry of course, but you are also putting everything in the same basket, so it is a compromise to understand

A domain name transfer between registrars has no impact on DNS resolution

When a domain name is transferred between two registrars, there is no change in the nameservers used at least at the registry level.

Which means that, as soon as the transfer is finished, the domain, now at a new registrar, still uses the same nameservers that it was using before the transfer, and hence if present previously, DNSSEC should continue to work in the exact same way.

With caveats:

  • if your DNS provider was your previous registrar from which you just transferred out, based on the contract you signed with it, it may or may not stop providing DNS service for your domain now at a second registrar. Good registrars will, even in this case, at least continue to provide service for some days, so that you have time to switch properly. If you are in a situation where the DNS service is immediately cut off after transfer, you will soon be in a world of pain

  • if you asked your new registrar to change the nameservers during transfer, it should do the operation right after the transfer finished. But if the new nameservers are not set up exactly as the old ones, including what is related to DNSSEC and specially the DNSKEY records, then as soon as the nameservers are changed your domain will (can) appear broken to validating resolvers that will produce NXDOMAIN for your domain because they will see the DS record in parent zone but no DNSKEY record anymore in the nameservers

Transferring a domain name with DNSSEC

Now this is where it depends a lot on TLDs.

With some registries, each registrar needs to be certified or at least checked for DNSSEC and the registry will prohibit transfers from a DNSSEC enable registrar to a non DNSSEC enabled one.

Some registries may prohibit transfers of DNSSEC enabled domains (in which case you first need to strip DNSSEC to go back to the insecure case, then transfer, then put back DNSSEC).

Some registries may strip DNSSEC related records (that is the DS record in their (registry) zone) during the transfer, specifically if the new registrar is not DNSSEC enabled, or has not used a specific switch requesting to keep the DNSSEC records during transfers.

There is a specific EPP extension to ease transfer of DNSSEC enabled domains: Key Relay Mapping for the Extensible Provisioning Protocol However:

  1. it needs to be implemented by the registry. To the best of my knowledge this is only the case for SIDN, the .NL registry
  2. the new registrar needs to use it
  3. the old registrar needs to cooperate

Which creates many conditions not often found.

A word on "propagation"

While everyone uses it in the DNS context, it is wrong. DNS is not top-down: when a change happen in a zone, this is not pushed down to all recursive resolvers (an impossible task anyway). On the contrary, the recursive nameservers will start to learn about the change in some given time, depending on both the content of their cache, and the TTL (Time To Live) values. Which is why changes can appear immediately, or after hours or days, depending on how you test, what you tested before, and from where.

You are mentioning Google DNS servers, which shows exactly what not to do: in case of DNS changes you need first to query the authoritative nameservers (starting from parent zone) to check if they have the expected values. Only after which you can start poking at various public recursive, but please remember there is a world outside of Google, so you can use as well (CloudFlare), (IBM+PCH), (Freenom) or (VeriSign), (OpenDNS), among many others and depending on which entity you decide to send your data to. You could as well start by using your own local recursive nameservers, either on your own box, on your LAN or on your ISP network.

You also have online troubleshooting tools:

  • https://zonemaster.net/
  • https://dnsviz.net/ which is specially good for DNSSEC as it presents chain of trusts and delegations as an image with nodes and links which makes understanding the situation far simpler than text output (and you can even install it locally in fact)

What could have happened and what to do?

  1. The nameservers may have been changed and the new ones have different zone content; this immediately breaks DNSSEC because of lack of DNSKEY record now. First action to solve the issue: go at registrar and remove DNSSEC material (the DS record) to have time to set up the nameservers again correctly
  2. Registrars were changed and the DS record was removed by registry or by new registrar. Your domain should then still resolve correctly, but you are not protected by DNSSEC anymore. First action to solve the issue: double check that your registrar handles DNSSEC (which means just being capable of sending DS records to the registry) and ask your DNS provider to activate DNSSEC again on your domain
  3. Probably many other cases, but they all depend on details you did not provide
  • Excellent answer! – David Sep 4 at 11:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.