If you prefer you can simply follow the RSS feed.
I think there was a problem with Unbound on Server #2 today that was slowing down replies. I have restarted Unbound on that machine and queries seem to be going pretty well again.
Thanks to dnscrypt.one for notifying me that the link to my GPG key on the contact page was not working. It should be fine now.
Thanks to some crappy DSL the web site was down from around 3:00am to 9:30am this morning. Resolvers were unaffected.
When Server #2's IPv6 address changed I forgot to update the main page. It should be correct now.
Thanks a bunch to John for letting me know the DoH listeners were not running. While troubleshooting during the recent problems I had disabled the script that monitors the DoH listeners and restarts them when necessary. My sincerest apologies for the service interruption!
Not too long ago I noticed that both resolvers were experiencing periods of very low queries per hour at random times. In the course of troubleshooting this issue I have enlisted the help of my VPS provider and OVH. As it turns out, the DNS traffic seems to be setting off OVH's DDoS protection, and when that happens ALL traffic seems to be stopped on the port in question. This means many users are being disconnected and are reconnecting to other servers. It also appears to take hours before reconnections bring the traffic back up to normal levels again.
One of the emails from OVH included a list of IP addresses that were the "top ten" traffic contributors. Although OVH had access to the dates/times, that information was not included, and OVH has no access to the query information because it is of course encrypted while traveling through their network. While the information is only able to confirm use of the service by a particular IP address, and it is helpful in troubleshooting the problem, I am still concerned that such information should not be stored anywhere. Please note that if a rich organization [like the US government for example] were interested in the traffic from one of these IP addresses they would be able to confirm use of dnscrypt.ca by simply looking at the outbound traffic, but the idea of storing that info separately still bothers me. I am requesting that both OVH and ULayer delete references to those IP address but admit that I have no control over either and can not promise that they will live up to any promise to delete it. In the meantime, I am continuing to work on the DDoS problem and will hopefullly have it cleared up soon.
Please accept my apologies for the information disclosure (no matter how minor or how contained) and I hope that being up front about it will ensure ongoing trust in the way dnscrypt.ca treats user privacy. If anyone has any questions about this [or any other aspect of dnscrypt.ca] please do contact me and I will answer any questions as best I can.
Looks like the web site went down late last night as a result of a dead DSL line. A squirrel chewed the phone line and it has now been replaced. Looks like this is not my weekend. :-(
Tonight I came home to an email from a user telling me the certificates on the DoH services had expired. It was absolutely my bad, and I appreciate the email. They have been renewed with my apologies for the downtime tonight.
Both servers are running on m13253's DoH implementation now instead of RouteDNS. I guess I could have made this announcement earlier, but nobody seemed to notice... which is good right? :-)
I have a script that runs hourly which checks the Unbound counters and records how many cache hits and misses have occurred in the last hour. Recently I have been seeing strange numbers in which the queries per hour drop dramatically and then rise again. While trying to troubleshoot I restarted RouteDNS from the command line and immediately saw a bunch of errors being barfed up. I am concerned that DoH listener may be timing out on a number of queries that it should be able to resolve. As a result I have tested m13253's DoH implementation on a small VM at home and then on a different port on Server #2. Earlier today I switched the live listener on Server #2 and all DoH queries are going through Nginx, then the doh-server, then Unbound (DNSCrypt based queries remain unchanged).
So far it seems to be functioning fine and luckily I was able to recycle the certs from RouteDNS. The downtime was less than 1 second as the RouteDNS service was killed and the Nginx service reloaded on the new port. I will monitor the Unbound counters to see if this solves the severe traffic drop problem, and if it does I will switch over Server #1 soon.
A couple of nasty vulnerabilities were found in Unbound recently. I patched Unbound on both servers around 11am today.
Server #2 went down around 7am. There is a problem with the hypervisor that it lives on and will be moved to a new host shortly.
I almost never use my dnscrypt.ca based XMPP address so I changed the contact page to show my snork.ca XMPP address. That way I only need to monitor a single account eh.
The host that runs Server #2 was down for a half hour around 6pm yesterday. When the host came back up the scripts I made were able to successfully restart all of the listeners.
Sorry folks, I screwed up the certs notification for routedns, so the doh services were barfing up an expired cert error. I have picked up fresh certs and they are running fine again. My bad!
The DNSSEC signatures expired today and as a result the dnscrypt.ca domain was not resolving properly for about 15 minutes. The resolvers were up and anyone already connected to them should not have noticed, but anyone initiating a new connection may not have been able to connect. Totally my bad. Sorry folks, I am going ot see if I can make a script that will automate signing (update BIND zone and reload domain) every second week.
I am expecting to switch from rebel.ca to 10dollar.ca in the next week or two. There should be no downtime [assuming DNS transfers fine] and if all goes well nobody will even notice. :-)
Someone recently alerted me to the fact that the provider-name and fingerprint information for the servers should be more readily available, so I changed the table on the main page to show a lot more information. All of this info can be compared against the public resolver list by using the dnscrypt.info stamp page.
Server #1 is moving to a new IP address (both IPv4 and IPv6). Most clients should automatically pull the new addresses from the public resolver list but see the main page if you need the details.
Curious eh? Well, have a look at the 2019 News.