DNS error after removing from cloudflare

I am from holland and own 8 domains. Five .nl domains, 1 .com, 1 .de and 1 es domain. After moving the dns to cloudflare several cerificate problems ocured. So I moved it all back to my own server. But now (after 10 days) the .com .es and .de can not be found by users using DNS 1.1.1.1 and 8.8.8.8. Other dns servers are working fine. So half the world can’t find these websites now. Is this some sort of penalty for deletion? Google stopt showing my ads because of this. What can I do to correct this?

What exact domain(s) are you seeing problems on?

1 Like

These three: then com de and es domans from calconditioner (sorry, forbidden to post the url)

No worries:

  1. calconditioner.com
  2. calconditioner.de
  3. calconditioner.es

Did I understand that well?

If so, the issue is that you didn’t disable DNSSEC at your domain registrar, before you changed name servers.

You can often find the DNSSEC related configuration around the place where you change name servers.

Otherwise, you need to get in touch with your domain registrar to get that sorted out.

Additionally, regarding the .ES domain:

calconditioner.es.      86400   IN      NS      ns1.dnstools.nl.
calconditioner.es.      86400   IN      NS      penny.ns.cloudflare.com.
calconditioner.es.      86400   IN      NS      mcgrory.ns.cloudflare.com.

You would either have to remove the Cloudflare ones (if you want to remove Cloudflare), or remove the ns1.dnstools.nl one (if you want to use Cloudflare).

2 Likes

Thank you. That could indeed be the problem. I am now using dnstools . nl servers and have disabled dnssec after the change. I’ll change it back and forth again but with dnssec off. Will let you know if that helps.

Which test do you use? If I run
dnschecker . org
then everything seems to be fine but it doesn’t work.

  1. Domain WHOIS of the domain

  2. Querying and following the DNS hierarchy from top to bottom (e.g. first from the root “.” zone, to e.g. the .ES TLD, and then downwards to e.g. your .ES domain).

Some at least country-code TLD’s such as e.g. .ES may not have an active WHOIS server for their domain(s), however -

A domain WHOIS lookup will (most often) show whether or not the domain has DNSSEC enabled or not, it will for e.g. .COM and .DE as you mention, even though .DE has always been limited in output on the WHOIS server.

In my memory, .ES is one of those few country-code TLD, that to my knowledge, never ran an actual WHOIS server that would provide informations about domains for their TLD, in such situations, you can move on to e.g. the DNS hierarchy:

dig +trace” is a command (on e.g. Linux systems) that can show quite some information along the way, including which severs the DNS traverse through to reach it’s final answers:

$ dig +trace calconditioner.es

; <<>> DiG 9.16.37-Debian <<>> +trace calconditioner.es
;; global options: +cmd
.                       3408    IN      NS      f.root-servers.net.
.                       3408    IN      NS      g.root-servers.net.
.                       3408    IN      NS      h.root-servers.net.
.                       3408    IN      NS      i.root-servers.net.
.                       3408    IN      NS      j.root-servers.net.
.                       3408    IN      NS      k.root-servers.net.
.                       3408    IN      NS      l.root-servers.net.
.                       3408    IN      NS      m.root-servers.net.
.                       3408    IN      NS      a.root-servers.net.
.                       3408    IN      NS      b.root-servers.net.
.                       3408    IN      NS      c.root-servers.net.
.                       3408    IN      NS      d.root-servers.net.
.                       3408    IN      NS      e.root-servers.net.
.                       3408    IN      RRSIG   NS 8 0 518400 20230914200000 20230901190000 11019 . ABD7TLnCD2tgTpRXkaLmrS8tPSxrjqq/vg+vSnrN+qGv04nTFiG0wCka UOHy4DnEywaqWFXj3iLYPSacdlzox0ziMaCv2w7KnFRlRgKtc3GFpR/3 qyIT66eWXtZ9g4k2AqiKQKDn/g7BwyWP5iar2yirLTAQEjEAX4GdwuQo R7Wft5GGm0zWil8Vvo6IqI6xmL3aUZtGjYOjSLKTGTIos8mCVxAMHt6T uCGalSEAfx0CG7NlzGQdg8RsB8t6QpQd0AtbBqlIS6g4dZ9ZULvpFMON qSnIIKWQJ8Ji6dTor8nlqCZaujIwYJmCSP4+lc536VDj/ut3180xXDYQ lLczZA==
;; Received 717 bytes from 192.168.8.1#53(192.168.8.1) in 4 ms

es.                     172800  IN      NS      g.nic.es.
es.                     172800  IN      NS      h.nic.es.
es.                     172800  IN      NS      a.nic.es.
es.                     172800  IN      NS      c.nic.es.
es.                     86400   IN      DS      44375 8 2 9D9858AE981AA53DD1143D93844E3D69B0FB73A9B4FE5759DA39E036 E754D402
es.                     86400   IN      RRSIG   DS 8 1 86400 20230914050000 20230901040000 11019 . jFUudpfzAMIg58VGciVZYLWku6uMwb5IX2uwRobD4piwiGiQTar7IT+L BFNY52pKIHfU9wkk6SmWa3jApBlWUcjsSuHS9MhbwPJ6U8Rg37/xRn+f lWWFKdER97DMjGOE1Vygtp8uTzzoM3XF1/yf2opg2cwbtcdA0d8t0CMc ZEmRk1oermNeKy6m0TvHvNPKccNDTH61hKhyP01A9zpYGznQ2tU4tSSv 0cJoiqsH1XpjmhNzWBryWnQTDpXADYCx+XsEBeOJaefC3RUhnRlFLH0e A5P0LsY0QiVisbS+VJlYpxSNmZD8t+110tS5ttZ0/G54qrwYuSjjYarf +o0yrQ==
;; Received 655 bytes from 2001:500:12::d0d#53(g.root-servers.net) in 84 ms

calconditioner.es.      86400   IN      NS      ns1.dnstools.nl.
calconditioner.es.      86400   IN      NS      mcgrory.ns.cloudflare.com.
calconditioner.es.      86400   IN      NS      penny.ns.cloudflare.com.
calconditioner.es.      86400   IN      DS      25612 13 2 422E9C8AC15F91364E37386CDBC8CAD05FF1141BC299405946AA444B CACBFAE2
calconditioner.es.      86400   IN      RRSIG   DS 8 2 86400 20230906114032 20230823110644 16468 es. u7ZM/sOlSIe2grd2hgnlS4eCYhhyiyqlyajZHvbBuDk9We727mpDi8AW hT5f+D3lnJ1ligPLXcA6pV4zCrsT/QQabg6M08c/sqkEVvt06vZhOo88 +iF9xRRZ4MutTk+6yHkvNvNOuo7wfV+GH1Q+Xfqy7R/ZXB1p8L/deK1A XaqZN+xHRbIRTwdgLlXyW2QrVRbsZlpNg59X8ECaB2OtCOdZiL2Gjjxv w/akkHi0BICxXGDEEaW3erU/BxZcJBSreAwemFX6UoRsGO8CC1PdpZzs bP+aTsn6FRdK+u5EglwQW2j1PjbnVmNV4fLBPevlkIMQ2P3eeTGXpSVA 8N3dSQ==
;; Received 500 bytes from 194.69.254.1#53(a.nic.es) in 68 ms

calconditioner.es.      300     IN      A       85.10.131.62
;; Received 62 bytes from 2803:f800:50::6ca2:c27c#53(penny.ns.cloudflare.com) in 40 ms

In the above, dig first asked my router where to find the “.” (root zone), where it found the name server g.root-servers.net to be one of the servers for the root zone.

Asking g.root-servers.net where to find the ES TLD, g.root-servers.net responded with the a/c/g/h.nic.es servers, where a.nic.es was being choosen.

Querying a.nic.es for where your domain is, a.nic.es told us:

calconditioner.es.      86400   IN      NS      ns1.dnstools.nl.
calconditioner.es.      86400   IN      NS      mcgrory.ns.cloudflare.com.
calconditioner.es.      86400   IN      NS      penny.ns.cloudflare.com.
calconditioner.es.      86400   IN      DS      25612 13 2 422E9C8AC15F91364E37386CDBC8CAD05FF1141BC299405946AA444B CACBFAE2

That literally means: Ask ns1.dnstools.nl, mcgrory.ns.cloudflare.com or penny.ns.cloudflare.com for where to find calconditioner.es.

The DS record provided means that the calconditioner.es domain’s DNS data is supposed to be DNSSEC signed, with a key that corresponds to the value of the DS record from the domain registry there.

Since neither of ns1.dnstools.nl, mcgrory.ns.cloudflare.com or penny.ns.cloudflare.com answers with DNSSEC signed DNS data, the DNS data for calconditioner.es is “bogus”.

As such, any DNS resolver out there (be it 1.1.1.1, 8.8.8.8, your own ISP’s resolver, or whatever) that is validating DNSSEC will respond with DNS response code 2 (SERVFAIL).

Some resolvers (e.g. including 1.1.1.1) may provide extended data about DNS failures, e.g. if you look here:

$ dig +dnssec calconditioner.es. @1.1.1.1

; <<>> DiG 9.16.37-Debian <<>> +dnssec calconditioner.es. @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2768
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for calconditioner.es.)
;; QUESTION SECTION:
;calconditioner.es.             IN      A

;; Query time: 60 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Sep 01 23:33:07 CEST 2023
;; MSG SIZE  rcvd: 103

The EDE line provides some information:

; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for calconditioner.es.)

Google, Quad 9 and OpenDNS actually does something similar:

$ dig calconditioner.es @8.8.8.8

; <<>> DiG 9.16.37-Debian <<>> calconditioner.es @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21243
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 10 (RRSIGs Missing): (For calconditioner.es/a)
;; QUESTION SECTION:
;calconditioner.es.             IN      A

;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Sep 01 23:38:53 CEST 2023
;; MSG SIZE  rcvd: 75

$ dig calconditioner.es @9.9.9.9

; <<>> DiG 9.16.37-Debian <<>> calconditioner.es @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7123
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 10 (RRSIGs Missing)
;; QUESTION SECTION:
;calconditioner.es.             IN      A

;; Query time: 44 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Fri Sep 01 23:38:55 CEST 2023
;; MSG SIZE  rcvd: 52

$ dig calconditioner.es @208.67.222.222

; <<>> DiG 9.16.37-Debian <<>> calconditioner.es @208.67.222.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60933
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; EDE: 6 (DNSSEC Bogus)
;; QUESTION SECTION:
;calconditioner.es.             IN      A

;; Query time: 52 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Fri Sep 01 23:39:00 CEST 2023
;; MSG SIZE  rcvd: 52

Many people out there believe all DNS code 2 (SERVFAIL) to be DNSSEC errors at first sight, which isn’t always the case.

I actually love the work and effort and so on, that the maintainers behind those sites put on to it, however -

I still believe it is very unfortunate that the quality of many of those test sites are whacky at best.

The ones that currently say that your site(s) works fine, assuming that the three domains above are correct, - they are either NOT doing DNSSEC validation, and/or otherwise missing some sanity checks, according to my humble opinion.

That is because through the location you are testing from, things are being validated (if not properly, then at least better) on the path between you and the site, than on those DNS checker sites.

The above got quite technical, … but:

TL;DR: I would typically start from e.g. domain WHOIS where possible, and DNS queries following the DNS hierarchy from top to bottom as mentioned above.

1 Like

So if I understand correctly, turning on dnssec on the current dnsserver should solve the problem. I’ve done that now and I’m going to wait and see, that’s all I can do I think.

And, what if I removed dns from cloudflare while dnssec was still set?

Does cloudflare removes dnssec before removing the dns setting?

Or, can I simply add the domail to cloudflare dns again, enable dnssec, then disable dnssec en then remove the domain from cloudflare?

While enabling DNSSEC on the new servers will be a very good idea, that alone is not going to solve the problem.

The domains are not registered with Cloudflare, and you’re trying to move away from Cloudflare.

Everything you try to do via Cloudflare will literally be a waste of time.

You will need to coordinate the removal (or preferably, since you enabled DNSSEC at the new place, the update) of the DNSSEC material through your current domain registrar.

^

As mentioned up there, the domain registrar is the place where you changed (or added) the dnstools.nl name servers.

That change was likely done at the same place where you pay the yearly fees for the domain to.

That is the place you need to go to remediate all of this.

1 Like

I moved the DNS to cloudflare because I was pissed about the dnstools servers going down a few times. That didn’t go well with the certificates, so I put it back. Removed all entries on cloudflare and set dns to ns1. dntools. nl & ns2. dntools. nl with my hosting provider.
Servers like nic. es should be automatically notified of this change, but they still point to cloudflare and say DNSSEC is active there. This has been going on for a week. All I can think of is that cloudflare didn’t propagate the changes to nic . es
I feel held hostage and now have 3 webshops that don’t work. So if anyone from cloudflare is reading along… HELP

No matter which domain registrar (or DNS provider) you move around to/from, you will experience this kind of issue, when you are not EITHER deactivating DNSSEC, OR updating DNSSEC to match the new provider’s DNSSEC key materials at the same time.

Your domain registrar, the place where you pay the yearly fees for your domain, may however be, if they are not able to help you with with this.

→ If you can share which company you paid money for those domains to, I might be able to bring up something more about how to fix the issue.

As I’ve said multiple times: Cloudflare isn’t the problem.

There is ABSOLUTELY NOTHING Cloudflare can do, it is between you and the domain registrar.

Cloudflare is NOT the company holding you hostage with this:

2 Likes

Thank you for your help. Activating DNSSEC in dnstools seems to solved the problem.
I got “a little” paranoid about it.

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