Better local DNS

For what’s felt like forever, I’ve run dnscrypt-proxy as a local DNS resolver for my LAN. Queries initially hit a BIND instance for my “local” domains and dnscrypt-proxy is the forwarder for this setup. This configuration doesn’t lend itself well to query logging or to individually unblocking “semi-desirable”1 trackers with the ad-blocking lists I’ve configured through dnscrypt-proxy. I could finagle something with BIND’s views, but why not look at something like Pi-Hole?

I’ve looked at Pi-Hole off and on before. I usually come back to the same problem: local DNS.There are several forward and reverse zones I run in a split DNS setup with BIND. Pi-Hole partially supports something like this with conditional forwarding; however, I’ve got more than one zone to contend with forwarding. dnsmasq has the option to set several upstreams per domain and Pi-Hole seems to have maintained this functionality as they progress with their own fork.

So as long as this upstream server setting remains, I create /etc/dnsmasq.d/99-forwarders.conf with the following type of content to enable all this forwarding:

server=/example.com/192.168.1.x
server=/1.168.192.in-addr.arpa/192.168.1.x
server=//192.168.1.x

This setup allows BIND to still answer for the zones it’s responsible for while letting Pi-Hole do what it does best. Now, if you’re wondering where dnscrypt-proxy is in my setup – it’s still there! I have Pi-Hole querying it as an upstream resolver. It took me a minute to figure out that the Pi-Hole GUI wants the upstream DNS port to be expressed with a # vs a : though. Now I’ve got the ability to group my “clients” with Pi-Hole and maintain my local DNS. Truly, the best of both worlds.

  1. So many sites become useless if you block their tracker and telemetry hosts. Chipotle and other online restaurants are good examples of this. Both their app and website simply fail with an unknown error if you block Traffic Manager, which seems to occasionally appear on crowd sourced DNS blocklists. ↩︎

BitLocker automatically rebooting

My Windows 10 PC automatically updates and automatically reboots. I’m generally fine with the former behavior, the latter can be a bit frustrating at times. Suspending updates and doing them on my schedule feels clumsy. Not to mention the fact that Windows doesn’t consider running PuTTY sessions worth preventing a reboot. I guess that’s a plug for more tmux and/or screen usage, though. Nevertheless, I wish Microsoft would yield more control over this update system to power users.

I use BitLocker and must manually unlock the system during a reboot. Normally, this is fine; however, when an automatic reboot inconveniently occurs, it’ll boot loop the system because I’m not there to enter the passphrase. The Windows UEFI system automatically reboots the system after a minute. And again, and again, and again… Sometimes it gets itself in such a loop that Startup Recovery is needed.

I finally found an answer to this annoying problem. In Boot Configuration Data (BCD), there’s a value, “bootshutdowndisabled,” that can prevent this automatic reboot. Now the system will wait into perpetuity for me to unlock it. A far sight better than a constant reboot. I’m sure the fans and power supply are a might happier too. I figured I’d share this, since I’m probably not the only one annoyed by it on a modern system they want to (better) secure.

In an administrator command prompt:
bcdedit /set bootshutdowndisabled 1

Your system will thank you later 🙂

Unsuccessful login attempts

Seriously, why can’t more online services offer these notifications? If I know I haven’t tried to login recently, an unsuccessful login notification is a great tipper to me that I need to potentially change my passwords, etc.  Unless, of course, my account is associated with a rather prevalent & popular username that everyone is trying to login to and/or reset.

Oh, the pains of having a semi-old Gmail account with a rather well-desired username…

FreeBSD.org compromise

Hmm.  Looks like some of the FreeBSD project’s servers were compromised recently.  Having had my personal servers compromised in the past, I know it’s not a fun time for anyone involved in the usage, cleanup, and auditing of said systems.  From their post, I’d guess the developer’s home system was compromised.  Given that a leaked SSH key was the suspected method, I suspect the attacker found a useful set of keys and then followed the known_hosts breadcrumbs to find viable targets.

I find most of the intrusions on my personal, Internet-facing systems come from weak or unpatched web applications.  Since I run a shared hosting environment, a lot of this comes with the territory.  Generally, I can obviate some of the web app risks with tools like suPHP and suEXEC.  That doesn’t protect me, though, if I’ve failed to patch things like local root holes.  So like the FreeBSD folks, I try and isolate my Internet-facing systems from my backend systems.  Sadly, since most of my personal server stuff is a hobby, financial means often limit the amount of physical hardening I can do.  Nevertheless, I try and maintain at least a monthly patching cycle for all my computers.  Keeping abreast of security and application update mailing lists is also a huge plus.

Stay hardy and vigilant, folks.  Patch and secure your workstations and your servers!