I don't know. Those warnings at DNSViz about the .click TLD are far from a smoking gun. It's just a few warnings, but nothing seriously. However, you might inform them of your issue and inquire if they have an idea.
2 Likes
This may be some extremely heavy lifting...
But I would add more authoritative DNS servers.
OR
Switch to another DNS Service Provider (DSP).
That said, I do see there is a new CAA entry:
;; ANSWER SECTION:
advocatesays.click. 10800 IN CAA 0 issue "letsencrypt.org"
Did that make the problem go away?
1 Like
Also consider using DNSSEC.
1 Like
Did that make the problem go away?
Nope, as I mentioned earlier the njalla support added the CAA entry for me but it didn't resolve the issue. I am still getting the error frequently.
But I would add more authoritative DNS servers.
OR
Switch to another DNS Service Provider (DSP).
Also consider using DNSSEC.
How would I go about that?
From the domain registrar control panel. NS and DS records. Your DNS provider usually has some kind of automation for handling both.
Those records are usually in another settings page because they're not in the advocatesays.click. zone, but in the click. zone. (You need to find another DNS provider, tho: 1984.is, he.net, cloudflare... there are several).
1 Like
I didn't find an option to create DS record but I tested out NS records with those DNS providers you listed and none of them seemed to yield an improvement. Meanwhile, I got a response from njalla support:
your A and CAA records resolve correctly, you can try i.e.
DNS Checker - DNS Check Propagation Tool
DNS Checker - DNS Check Propagation Toolif you are still seeing that issue, this might be an issue with your local DNS, make sure you can resolve the domain and CAA record before running certbot:
dig CAA advocatesays.click
dig A advocatesays.click
dig A www.advocatesays.clickif any of those fail for you, check if you have some local cache or dns setting that might break lookups. Once all is working, try running certbot again. If it still fails, run with -v to see more details on what exactly fails.
It was suggested to enable DNSSEC in the forum, we don't have support for DNSSEC for .click domains right now, so you can not enable that. But letsencrypt does not require DNSSEC, that was just a random suggestion to improve your setup.
Not really sure how this could be an issue with local DNS when other people here have tried dig with same issue as well, but I will be seeing about following those guidelines next, I guess.
What I don't get is why would Boulder complain about this if your domain is not DNSSEC enabled (in which case, a response saying "no CAA here" should be signed)
peppe@monolite:~$ dig +short ns advocatesays.click
3-get.njalla.fo.
2-can.njalla.in.
1.1.1.1.
1-you.njalla.no.
this is not how you add cloudflare as an authoritative dns. An authoritative dns is different from the dns you use to fetch the records, it's the one you use to publish them.
2 Likes
Reading this again I am convinced there is nothing you can do to solve this right now.
Yes, you might try changing authoritative dns, but if it works intermittently, it's probably fine. It only needs to work once in the ten days the automatic renewal is running. You might tell certbot to try every hour instead of twice a day, but I wouldn't do anything else.
My main suspect is some kind of anti abuse system on the njalla authoritative dns servers.
1 Like
You might be right, however right now I don't see a reasonable pattern behind these "outages" and I would prefer to be more sure that retrying this often will help (and don't want to push the rate limit needlessly either). I did the dig tests that njalla support requested without any errors and sent them verbose outputs from some successful and failed certbot dryruns, as well as asked about that anti abuse system theory.
You won't push rate limits if you try once an hour (failed validations is 5 per hour per hostname). Or twice a day.
1 Like
Yes, with production. But, --dry-run allows more. Not sure exact number.
2 Likes
More, a lot more.
60, actually. Staging Environment - Let's Encrypt
2 Likes
Got this response from njalla support:
Well you also added an NS record pointing to 1.1.1.1
that will fuck up everything!
as the note below says: use NS to delegate the nameserver resolution of a subdomain to an external nameserver, 1.1.1.1 is a public resolver, not your own nameserver that resolves your domain.
Adding 1.1.1.1 to the mix will result in a good amount of dns failures.
Confused now about what you meant about adding NS records.
1 Like
Following your link I found this guide:
https://support.cloudflare.com/hc/en-us/articles/205195708
As per instructions there, I registered in Cloudflare (for a free plan), added my site and added NS records in njalla dashboard that use Cloudflare's nameservers I was shown (now those are the only NS records I have set up). It appears that I will need to wait from 2 to 24 hours to see the results, so hopefully I understood the instructions correctly.
Ok. Did you remove the njalla nameservers? You should.
Yes, you did. Good. I still see the njalla ones, tho. So you should wait. In the meantime, go on cloudflare and recreate/import your other records: A, AAAA and whatever you need. Also disable DNSSEC (on njalla) or configure it according to cloudflare's instructions.
After that, you edit your dns records from cloudflare and the administrative info on njalla. You only edit NS records on njalla because they are in the click. zone, of which yours is a "subdomain".
(you should wait until this command shows cloudflare's nameservers only)
peppe@monolite:~$ for ns in $(dig +short ns click.); do dig @$ns ns advocatesays.click; done
; <<>> DiG 9.16.1-Ubuntu <<>> @ns1.uniregistry.net. ns advocatesays.click
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40191
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 36806aa79ba2f33b0100000061fbadfd9bab1b94fd53ed78 (good)
;; QUESTION SECTION:
;advocatesays.click. IN NS
;; AUTHORITY SECTION:
advocatesays.click. 900 IN NS 1-you.njalla.no.
advocatesays.click. 900 IN NS 2-can.njalla.in.
advocatesays.click. 900 IN NS 3-get.njalla.fo.
;; Query time: 118 msec
;; SERVER: 64.96.1.1#53(64.96.1.1)
;; WHEN: Thu Feb 03 11:27:09 CET 2022
;; MSG SIZE rcvd: 162
; <<>> DiG 9.16.1-Ubuntu <<>> @ns2.uniregistry.info. ns advocatesays.click
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10054
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9a7d1ac890da027a0100000061fbadfd523534cbc416bf40 (good)
;; QUESTION SECTION:
;advocatesays.click. IN NS
;; AUTHORITY SECTION:
advocatesays.click. 900 IN NS 2-can.njalla.in.
advocatesays.click. 900 IN NS 3-get.njalla.fo.
advocatesays.click. 900 IN NS 1-you.njalla.no.
;; Query time: 36 msec
;; SERVER: 64.96.2.1#53(64.96.2.1)
;; WHEN: Thu Feb 03 11:27:09 CET 2022
;; MSG SIZE rcvd: 162
; <<>> DiG 9.16.1-Ubuntu <<>> @ns3.uniregistry.net. ns advocatesays.click
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4419
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;advocatesays.click. IN NS
;; AUTHORITY SECTION:
advocatesays.click. 900 IN NS 1-you.njalla.no.
advocatesays.click. 900 IN NS 2-can.njalla.in.
advocatesays.click. 900 IN NS 3-get.njalla.fo.
;; Query time: 48 msec
;; SERVER: 185.159.197.3#53(185.159.197.3)
;; WHEN: Thu Feb 03 11:27:09 CET 2022
;; MSG SIZE rcvd: 134
; <<>> DiG 9.16.1-Ubuntu <<>> @ns4.uniregistry.info. ns advocatesays.click
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7959
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;advocatesays.click. IN NS
;; AUTHORITY SECTION:
advocatesays.click. 900 IN NS 1-you.njalla.no.
advocatesays.click. 900 IN NS 3-get.njalla.fo.
advocatesays.click. 900 IN NS 2-can.njalla.in.
;; Query time: 38 msec
;; SERVER: 185.159.198.3#53(185.159.198.3)
;; WHEN: Thu Feb 03 11:27:09 CET 2022
;; MSG SIZE rcvd: 134
peppe@monolite:~$
2 Likes
So, it has been over 24 hours and that dig command still only shows njalla nameservers for me.
In the meantime, go on cloudflare and recreate/import your other records:
A,AAAAand whatever you need.
It is already done automatically as part of the process of adding the site to cloudflare.
Also disable DNSSEC (on njalla) or configure it according to cloudflare's instructions.
As seen in one of my previous posts, njalla support stated that they don't provide DNSSEC.
After that, you edit your dns records from cloudflare and the administrative info on njalla. You only edit NS records on njalla because they are in the
click.zone, of which yours is a "subdomain".
Not really sure what this would entail. What edits do you suggest that I haven't done yet?
Did you add the NS records among all others or is there a separate interface? There should be a separate interface. Look for it.
1 Like
On njalla, there should be a specific option to set up your nameservers, separate from all your other DNS records.
This is because, I reiterate, most of your DNS records are in the advocatedays.click. zone, but editing your nameservers requires modifying the parent zone, which is called just click. and tells the internet where to fetch all the other records.
4 Likes