Below config used to work flawlessly 2 months ago.
Okay so I downloaded the Caddy module for Duckdns for Linux AMD 64 from website.
I use Duckdns for giving https to my local ip 192.168.1.197 with domain: adguardcad.duckdns.org
And my API key for DuckDNS is [redacted]
Now I use caddy for doing it, where my CaddyFile is
adguardcad.duckdns.org:443 {
# Use the ACME DNS-01 challenge to get a cert for the configured domain.
tls {
dns duckdns [redacted]
}
# This setting may have compatibility issues with some browsers
# (e.g., attachment downloading on Firefox). Try disabling this
# if you encounter issues.
encode gzip
reverse_proxy adguardhome:80
reverse_proxy /notifications/hub/ adguardhome:3012
# Proxy everything else to Rocket
}
I have also tried ping 1.1.1.1 from inside the container and it works:
root@omv:~# docker exec -it adguardcaddy /bin/sh
/srv # ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=51 time=14.364 ms
64 bytes from 1.1.1.1: seq=1 ttl=51 time=14.050 ms
64 bytes from 1.1.1.1: seq=2 ttl=51 time=14.132 ms
64 bytes from 1.1.1.1: seq=4 ttl=51 time=14.134 ms
64 bytes from 1.1.1.1: seq=5 ttl=51 time=14.052 ms
64 bytes from 1.1.1.1: seq=6 ttl=51 time=13.622 ms
64 bytes from 1.1.1.1: seq=7 ttl=51 time=13.499 ms
64 bytes from 1.1.1.1: seq=9 ttl=51 time=13.405 ms
I have the Vaultwarden in the same, where via admin access I was able to check the Vaultwarden container is able to connect to internet, so if my outbound connections are blocked, won't that also cause Vaultwarden to not connect with Github (accessible via Admin console)
The failures are for TCP port 53 requests - Ping will not simulate those types of requests.
Also, 1.1.1.1 was able to resolve the destination name(s).
So, the DNS server used is NOT part of the problem.
Taking a closer look at the error message:
We can see that a nameserver IP has been resolved [in this case "3.97.51.116"].
But the DNS request to it on TCP port 53 returned with a "timeout".
So, again, the DNS server used ["1.1.1.1"] is NOT part of that problem.
@fedonr I strongly suggest getting new (or regenerate) and different DuckDNS API Tokens!
Never post Private Keys, Credentials, nor secret API keys.
Editing them out is nice, but they are still loose in the wild for bad actors to get and use.
Now Public Keys are just that; anyone can and should be able to see them, so posting them is OK.
"I did that?" Hope so.
A lot of times "unaware or inexperienced admins" drop tons of stuff on the forum.
We need information to solve issues, but credentials and keys are another story. I don't know how many times I have reported these kinds of breeches... But they happen.
And on the other hand there are those that won't post the domain for one reason or another. It is a hand off. Good on the Leaders here and (moderators?) that catch this stuff and help fix it.
Still facing the issues, I tried to do some trial and error. Where I did factory reset on my router and it worked for the first time, so I kept on it for 3 days trying to delete certs and restart container every 5 hours after deleting caddy data and config files. It's working 1 out of 4 times in a day.
Logs
INF ts=xxx logger=tls.issuance.zerossl.acme_client msg=trying to solve challenge identifier=gharnas.duckdns.org challenge_type=dns-01 ca=https://acme.zerossl.com/v2/DV90
ERR ts=xxx logger=tls.issuance.zerossl.acme_client msg=cleaning up solver identifier=*.gharnas.duckdns.org challenge_type=dns-01 error=no memory of presenting a DNS record for “_acme-challenge.gharnas.duckdns.org” (usually OK if presenting also failed)
ERR ts=xxx logger=tls.issuance.zerossl.acme_client msg=cleaning up solver identifier=gharnas.duckdns.org challenge_type=dns-01 error=no memory of presenting a DNS record for “_acme-challenge.gharnas.duckdns.org” (usually OK if presenting also failed)
ERR ts=xxx logger=tls.obtain msg=could not get certificate from issuer identifier=.gharnas.duckdns.org issuer=acme.zerossl.com-v2-DV90 error=[.gharnas.duckdns.org] solving challenges: presenting for challenge: could not determine zone for domain “_acme-challenge.gharnas.duckdns.org”: unexpected response code ‘SERVFAIL’ for gharnas.duckdns.org. (order=https://acme.zerossl.com/v2/DV90/order/KqujzNEER2dkJKK5RpFzvg) (ca=https://acme.zerossl.com/v2/DV90)
ERR ts=xxx logger=tls.obtain msg=will retry error=[.gharnas.duckdns.org] Obtain: [.gharnas.duckdns.org] solving challenges: presenting for challenge: could not determine zone for domain “_acme-challenge.gharnas.duckdns.org”: unexpected response code ‘SERVFAIL’ for gharnas.duckdns.org. (order=https://acme.zerossl.com/v2/DV90/order/KqujzNEER2dkJKK5RpFzvg) (ca=https://acme.zerossl.com/v2/DV90) attempt=1 retrying_in=60 elapsed=10.854302968 max_duration=2592000
ERR ts=xxx logger=tls.obtain msg=could not get certificate from issuer identifier=gharnas.duckdns.org issuer=acme.zerossl.com-v2-DV90 error=[gharnas.duckdns.org] solving challenges: presenting for challenge: could not determine zone for domain “_acme-challenge.gharnas.duckdns.org”: unexpected response code ‘SERVFAIL’ for _acme-challenge.gharnas.duckdns.org. (order=https://acme.zerossl.com/v2/DV90/order/ODv6ymYqrO5Z9lkO9-MRCg) (ca=https://acme.zerossl.com/v2/DV90)
ERR ts=xxx logger=tls.obtain msg=will retry error=[gharnas.duckdns.org] Obtain: [gharnas.duckdns.org] solving challenges: presenting for challenge: could not determine zone for domain “_acme-challenge.gharnas.duckdns.org”: unexpected response code ‘SERVFAIL’ for _acme-challenge.gharnas.duckdns.org. (order=https://acme.zerossl.com/v2/DV90/order/ODv6ymYqrO5Z9lkO9-MRCg) (ca=https://acme.zerossl.com/v2/DV90) attempt=1 retrying_in=60 elapsed=10.85496946 max_duration=2592000
Jio, a major Indian ISP, has been observed to employ various methods to block certain websites and services. According to the search results, Jio is using a technique called SNI (Server Name Indication) inspection to block websites for its users. This method involves inspecting the SNI field in the TLS protocol to determine the intended destination of a connection and block it if necessary.
Additionally, Jio has also been reported to block UDP ports required for Cloudflare Warp, a service that provides a secure and fast way to access the internet. This blocking of UDP ports is likely done to prevent users from accessing certain websites or services that Jio may deem inappropriate.
It’s also worth noting that Jio has been known to change its public IP addresses frequently to maintain efficiency and manage its network resources. This can cause issues for users who rely on static IP addresses or have specific configurations that rely on a specific IP address.
In summary, Jio has been observed to block TCP and UDP requests for DNS, as well as block specific ports and services, in order to manage its network and block certain websites or services.
It is resolved now, as I had to change the resolver to google 8.8.8.8
As cloudflare and controld didn't work.
So, for the solution was resetting router and change resolver to Google.
Initially all google, cloudflare and controld but after resetting the router Google started working.
Still I do have a question, why suddenly cloudflare stopped working it worked for more than a year for me. And why do some resolvers work while others don't?
