7

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?

4
  • 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? Commented Nov 24, 2018 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. Commented Nov 24, 2018 at 21:08
  • "To the best of my knowledge DNSSEC is supposed to drop out of resolver caches within 48 hours at the very maximum". No. There are no magical 48 hours value anywhere in the DNS. Everything is governed by TTLs which provides maximum amount of time of retention, and then by various software internal limits and local policies (like refusing to abide by too small TTLs). One should make sure not to entertain the false idea that there is some sort of DNS propagation or some hardcoded values. Plus if you check authoritative nameservers, and not recursive, changes are "immediate", no TTL into play. Commented Nov 6, 2021 at 20:22
  • by TTLs, and for DNSSEC by begin/end of validity timestamps in RRSIG records. Commented Nov 6, 2021 at 20:23

2 Answers 2

9

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 (except of course for a couple of registries where the registrar can or is even forced to supply the nameservers list at transfer time, which results basically in the same thing as if the new registrar does a nameserver change right after the transfer has completed).

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 1.1.1.1 (CloudFlare), 9.9.9.9 (IBM+PCH), 80.80.80.80 (Freenom) or 64.6.64.6 (VeriSign), 208.67.222.222 (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
0
4

The same DNSSEC transfer issue has just happened to me. I am far from being a pro network engineer and it took me a while to troubleshoot the problem. Thanks to Patrick's excellent answer, I'm back online and I'd like to document the practical aspects of my encounter here, hopefully to help others and the future me.

The story goes like this. I used to have my personal domain with Google Domains for several years and it was all good, until suddenly they asked me for a proof of my identity:

Collect all of the following documents:

  • A bank statement or utility bill that includes your billing address
  • Your non-expired government issued driver’s license, identification card, or passport information page

Way to go, Google Domains! For the first time in over a decade of my domain ownership I got asked for something like that. And I had to act quickly, as was instructed in the email:

Unfortunately, if we are unable to verify you information within 10 days, your Domain may be suspended.

Naturally, I had decided to transfer my domain somewhere else ASAP, and that's how I ended up with GoDaddy. I used them once before, so I thought I'd quickly churn over and then figure out what to do next.

Little did I know it might also have been a good idea to disable DNSSEC before leaving Google Domains. Two days later, my domain was still resolving to NXDOMAIN, and I began investigating what was going on. DnsViz indicated the issues with DNSSEC and incorrect/missing DS key.

The thing is, if you use GoDaddy's own nameservers, their basic DNS hosting tier doesn't allow editing DS entries. Apparently, they had copied the old DS record from Google Domains and now it was defunct and stuck in limbo. I'd have to upgrade to their Pro tier to use their DNSSEC features, which wasn't something I originally planned for.

Alternatively, if you use GoDaddy as only a registrar and host your domain DNS records somewhere else, then GoDaddy allows you to edit or remove DS records.

After a quick search for a free DNS hosting provider, I picked Cloudflare. I created a free account with them, provisioned the DNS records for my domain and made a change in my GoDaddy account to use Cloudflare's nameservers.

Then I enabled DNSSEC at Cloudflare, removed the old DS entry and added a new one at GoDaddy's (steps), and 10 minutes later my domain started to resolve again.

So far, Cloudflare has been incredible. I've known their name before because I've been using their 1.1.1.1 and DNS-over-HTTPS services (with OpenWrt and Pi-hole) for quite a while and it's been great. This however is the first time I'm using their cloud DNS hosting infrastructure and it surely stands up to the hype.

7
  • 1
    At some point in time, I basically switched all domains over to Cloudflare — basically because it's so easy to configure things, everything always works 24h/7, and they're free on top of everything. They have two limitations: you cannot register domains with them, only transfer; and they do not support all TLDs, even some major ones (such as .EU). But I'm sure they'll address everything with time. DNSSEC support (among so many other useful things... such as HSTS...) is literally just switching it on and off on a small slider. All the background mess is handled silently... Commented Sep 24, 2020 at 23:12
  • 1
    @GwynethLlewelyn yep they're excellent, a role model of not-be-evil corporate success. Hopefully they'll manage to not drop the ball.
    – noseratio
    Commented Sep 25, 2020 at 1:36
  • "until suddenly they asked me for a proof of my identity:" note that for gTLDs, this is in fact a requirement by ICANN hence pushed to all registrars; it is called the WDRP policy see icann.org/resources/pages/registrars/consensus-policies/wdrp-en and there is a FAQ on it for registrant: icann.org/resources/pages/faqs-f0-2012-02-25-en ; many ccTLDs have similar constraints (on registrars asking "sometimes" proofs to registrant, or even the registry doing it itself randomly or not, for example .EU or .BE) Commented Nov 3, 2021 at 21:05
  • 2
    "Apparently, they had copied the old DS record from Google Domains " The DS records are at parent, ie the registry, not at the child. The registry keeps them (they are typically not affected by a registrar transfer, as explained in my answer, they are like the NS records, untouched during a transfer). So it is expected you don't see them through your DNS provider UI/API. To change the DS records you need to go through your registrar (that can be, or not, your DNS provider) so that it can push those changes to the registry. They are not "local" Commented Nov 3, 2021 at 21:06
  • So because Google Domains was both registrar and provider, once I've transferred to GoDaddy, my DS record was effectively lost for me. I should have retrieved it before the move.
    – noseratio
    Commented Nov 4, 2021 at 10:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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