If you prefer you can simply follow the RSS feed.
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.