Dnssec on .cyou domain

Hi, I’ve setup a few hundred subdomain using .cyou domain. It is working fine , but in the last few days, all of my subdomain return DNS_PROBE_FINISHED_NXDOMAIN , is the problem with desec or my server?

For further information, in the last few days I register another .cyou domain to desec. I also plan to have a few hundred subdomain on the new .cyou domain. The new .cyou domain is currently working, but the old one isn’t. However, both of the new and old .cyou domain is pointing to the same ip address with A record, do desec support two domain that point to the same ip? using https://dnssec-analyzer.verisignlabs.com/ , my old.cyou return Zone cyou (212.18.249.120) returns NXDOMAIN for old.cyou

Your question is lacking basically all info that might help to give you a relevant answer. NXDOMAIN means that the name server that was asked does not know the domain.

Also try $ dig @8.8.8.8 <example.com> NS, i.e. specify the name server you are asking and then check the result. Name servers to try: public ones such as 8.8.8.8 or 1.1.1.1, and also ns1.desec.io, ns2.desec.org. Replace <example.com> with your domain name of course.

Also try DNSViz to analyze the problem.

Irrelevant. You can have any number of DNS A records in any number of domains pointing to the same IP address. (That does not mean that the service running on that IP will handle this, just that the DNS resolution will work if DNS is working correctly.)

fiwswe

1 Like

thank you for the reply. I’ve just tried dig. There’s no difference between 8.8.8.8 and 1.1.1.1 , what I notice is that <my_not_working_domain.cyou> give A record of 36.86.63.182 which is not my server, and <working_domain.cyou> give the correct A record. But I’m not really sure what the result means. Here is the result

  1. dig @8.8.8.8 <my_not_working_domain.cyou> <working_domain.cyou> ns1.desec.io ns2.desec.org
    ; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> @8.8.8.8 <my_not_working_domain.cyou> <working_domain.cyou> ns1.desec.io ns2.desec.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47301
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;<my_not_working_domain.cyou>. IN A

;; ANSWER SECTION:
<my_not_working_domain.cyou>. 300 IN A 36.86.63.182

;; AUTHORITY SECTION:
cyou. 3600 IN SOA ns0.centralnic.net. hostmaster.centralnic.net. 1663158228 900 1800 6048000 3600

;; Query time: 87 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 14 19:32:48 WIB 2022
;; MSG SIZE rcvd: 130

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45475
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;<working_domain.cyou>. IN A

;; ANSWER SECTION:
<working_domain.cyou>. 3600 IN A 23.xx.xxx.xx8 (my server ip)

;; Query time: 106 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 14 19:32:48 WIB 2022
;; MSG SIZE rcvd: 75

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33446
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns1.desec.io. IN A

;; ANSWER SECTION:
ns1.desec.io. 900 IN A 45.54.76.1

;; Query time: 282 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 14 19:32:48 WIB 2022
;; MSG SIZE rcvd: 57

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23498
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns2.desec.org. IN A

;; ANSWER SECTION:
ns2.desec.org. 600 IN A 157.53.224.1

;; Query time: 72 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 14 19:32:48 WIB 2022
;; MSG SIZE rcvd: 58

  1. dig @1.1.1.1 <my_not_working_domain.cyou> <working_domain.cyou> ns1.desec.io ns2.desec.org
    ; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> @1.1.1.1 <my_not_working_domain.cyou> <working_domain.cyou> ns1.desec.io ns2.desec.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19220
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;<my_not_working_domain.cyou>. IN A

;; ANSWER SECTION:
<my_not_working_domain.cyou>. 300 IN A 36.86.63.182 (not my server ip)

;; AUTHORITY SECTION:
cyou. 3600 IN SOA ns0.centralnic.net. hostmaster.centralnic.net. 1663158228 900 1800 6048000 3600

;; Query time: 74 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Sep 14 19:29:22 WIB 2022
;; MSG SIZE rcvd: 130

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52447
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;<working_domain.cyou>. IN A

;; ANSWER SECTION:
<working_domain.cyou>. 3600 IN A 23.xx.xxx.xx8 (my server ip)

;; Query time: 113 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Sep 14 19:29:22 WIB 2022
;; MSG SIZE rcvd: 75

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6347
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns1.desec.io. IN A

;; ANSWER SECTION:
ns1.desec.io. 900 IN A 45.54.76.1

;; Query time: 278 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Sep 14 19:29:22 WIB 2022
;; MSG SIZE rcvd: 57

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58830
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns2.desec.org. IN A

;; ANSWER SECTION:
ns2.desec.org. 600 IN A 157.53.224.1

;; Query time: 206 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Sep 14 19:29:23 WIB 2022
;; MSG SIZE rcvd: 58

Don’t try to test too much at once! Test one domain at a time. And also test for specific DNS records. I asked for NS specifically because this is a mandatory record and it shows which name servers are authoritative for the domain. A records are not mandatory and have the potential for additional error sources (misconfigurations).

First let’s see if DNS is working at all for your problematic domain.

That seems to be the case as your query for the A record gave back a result, not an error:

Now ask for the NS and compare the result to the deSEC NS. Are they the same?
$ dig @8.8.8.8 <my_not_working_domain.cyou> NS

If yes then ask one of the deSEC NS directly for the A record instead of 8.8.8.8.
If not then your domain is not delegated to deSEC.

To keep these basic debugging instructions somewhat short, I’ll stop here. The tree grows exponentially with each step and its possible results…

fiwswe

Ahh I see, I misunderstood your instruction, dig @8.8.8.8 <my_not_working_domain.cyou> NS doesn’t return any NS, compared to <working_domain.cyou>, it return the correct desec NS, however when I use dig @ns1.desec.io <my_not_working_domain.cyou> A it return the correct A record but with bad cookies, which means my domain is delegated to deSEC, do that means my <my_not_working_domain.cyou> nameserver somehow is empty? That means I should check my domain provider right?

  1. dig @8.8.8.8 <my_not_working_domain.cyou> NS
    ; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> @8.8.8.8 <my_not_working_domain.cyou> NS
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9148
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;<my_not_working_domain.cyou>. IN NS

;; ANSWER SECTION:
<my_not_working_domain.cyou>. 300 IN A 36.86.63.182

;; AUTHORITY SECTION:
cyou. 3600 IN SOA ns0.centralnic.net. hostmaster.centralnic.net. 1663161380 900 1800 6048000 3600

;; Query time: 41 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 14 20:22:13 WIB 2022
;; MSG SIZE rcvd: 120

  1. dig @8.8.8.8 <working_domain.cyou> NS
    ; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> @8.8.8.8 <working_domain.cyou> NS
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39558
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;<working_domain.cyou>. IN NS

;; ANSWER SECTION:
<working_domain.cyou>. 3600 IN NS ns2.desec.org.
<working_domain.cyou>. 3600 IN NS ns1.desec.io.

;; Query time: 112 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 14 20:20:28 WIB 2022
;; MSG SIZE rcvd: 92

  1. dig @ns1.desec.io <my_not_working_domain.cyou> A
    ;; BADCOOKIE, retrying.

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> @ns1.desec.io <my_not_working_domain.cyou> A
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3442
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: bdd711df6034b67c010000006321d7dd639196b580e41d3a (good)
;; QUESTION SECTION:
;<my_not_working_domain.cyou>. IN A

;; ANSWER SECTION:
<my_not_working_domain.cyou>. 3600 IN A 2x.xx.xxx.x18

;; Query time: 50 msec
;; SERVER: 2607:f740:e633:deec::2#53(2607:f740:e633:deec::2)
;; WHEN: Wed Sep 14 20:32:13 WIB 2022
;; MSG SIZE rcvd: 93

If this was the answer to a query for NS records, then something is strange! This answer lists an A record not an NS record. Try for the SOA record:
$ dig @8.8.8.8 <my_not_working_domain.cyou> SOA

You could also try to see what the parent domain (the TLD in this case) has:
$ dig @a.nic.cyou <my_not_working_domain.cyou> NS

BTW: When you substitute a value for <my_not_working_domain.cyou> is this the actual domain (example.cyou) or a subdomain (www.example.cyou)? You should use the former in your queries.

The result of the query for the working domain is as I would have expected it.

Cookies? DNS does not use cookies to my knowledge.

Probably a good idea to check what the domain provider has as NS records for your domain, yes. There should be some value there, even if it is just some default server of the domain provider. I have never seen a domain without any NS records. And the fact that you do get back an A record proves that there must be something there.

However odds are high that the delegation to deSEC has not happened. Again something you have to fix with your domain provider. They need to convey this info to the parent domain cyou.

fiwswe

I use (example.cyou) for all the test, dig @8.8.8.8 <my_not_working_domain.cyou> SOA also return A record

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> @8.8.8.8 <my_not_working_domain.cyou> SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55558
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;<my_not_working_domain.cyou>. IN SOA

;; ANSWER SECTION:
<my_not_working_domain.cyou>. 300 IN A 36.86.63.182

;; AUTHORITY SECTION:
cyou. 3600 IN SOA ns0.centralnic.net. hostmaster.centralnic.net. 1663162901 900 1800 6048000 3600

;; Query time: 89 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 14 21:02:40 WIB 2022
;; MSG SIZE rcvd: 120

dig @a.nic.cyou <my_not_working_domain.cyou> NS return NXDOMAIN
; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> @a.nic.cyou <my_not_working_domain.cyou> NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52660
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 3d59bff81e7d34c31ecdfd246321dfe896455c38010748f3 (good)
;; QUESTION SECTION:
;<my_not_working_domain.cyou>. IN NS

;; AUTHORITY SECTION:
cyou. 3600 IN SOA ns0.centralnic.net. hostmaster.centralnic.net. 1663162901 900 1800 6048000 3600

;; Query time: 17 msec
;; SERVER: 2001:67c:13cc::1:120#53(2001:67c:13cc::1:120)
;; WHEN: Wed Sep 14 21:06:32 WIB 2022
;; MSG SIZE rcvd: 132

my current name server in the domain provider settings is still desec name server, I’ll contact the domain provider, maybe they messed up the configuration

It seems I was wrong: → RFC 7873 and RFC 9018. But DNS-Cookies are probably irrelevant to your problems.

Again strange!

Maybe the domain is not really registered at all? You get the A record because of some catch-all behavior of the cyou. name servers?

A normal domain should have at the very least NS-glue records in the parent domain. You are not seeing those so the domain might be reserved for you but it is not fully functional.

Definitely contact them (your domain provider) to get this straightened out. While you’re at it for deSEC you will also need to add the DS records matching the deSEC DNSKEY records next to the NS-glue records in the cyou. domain to complete the chain of trust for DNSSEC. So get them to add those as well.

fiwswe

The domain is working last week, I’ll update here if the problem is with the domain provider. Thank you for your help. Really appreciate it.

Hi pupstime,

Welcome to deSEC!

It seems like fiwswe’s observations are correct. Another very strong hint that your domain is not delegated to deSEC is that when you query something for your broken domain, the response contains the line

cyou. 3600 IN SOA ns0.centralnic.net. hostmaster.centralnic.net. 1663161380 900 1800 6048000 3600

When a record is not found, the SOA record is usually sent instead. By the fact that this SOA record belongs to cyou. (and not your domain), you can conclude that cyou. has no NS records for your domain.

The situation last week is immaterial at the moment. Still, it would help debugging if you could share you domain names. Experts in the forum may be able to figure something out (such as whether there are traces of modification in the registry Whois, and so forth).

In any case, you definitely need to contact your domain registrar.

Stay secure,
Peter