How to run your own DNS resolver (using DNS-over-HTTPS) in Kubernetes using cloudflared

We recently had a blog post on how to secure your DNS traffic using DNS-over-TLS or DNS-over-HTTPS (German only). The article gave an introduction on how to run dnsdist as a local resolver on Debian11. In this case, dnsdist would accept queries using DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH).

This surely is the right solution for those scenarios, where your clients are capable of speaking DoT or DoH natively. But what if they don’t? In this case you can create your own resolver that listens on the “usual” aka unencrypted DNS ports. The DNS traffic on your local network is then unencrypted, which might or might not be acceptable depending on your threat analysis. Once the requests have reached your local resolver, it will forward them using DoH to a server of your choice. Which one to pick is up to you, a list of available servers can be found at DNSprivacy.org.

In this article, we will run our own resolver in Kubernetes using a helm chart for cloudflared. Despite the name, it can be used with many different endpoints, not just the ones from Cloudflare.

Running the Blocky ad-blocking dns-proxy in Kubernetes

Blocky is a dns-proxy capable of blocking undesired content, i.e. ads or malware. It supports blocklist-based filtering, supports new DNS protocols like DoH (DNS-over-HTTPS) or DoT (DNS over TLS) and a gazillion of other features. It is being provided as a docker image, and while docker is a fascinating piece of software, who choses to run things in plain Docker when you can do so in Kubernetes? While not everyone might be running Kubernetes at home, with k3s this is really easy. And it uses the same Kubernetes resources you see in data centers and edge locations and windparks and cars and whatnot.

This article will describe how to setup Blocky within your Kubernetes cluster, how to make it available from the outside and how to start using it. The configuration of Blocky itself is explained in full details in the project’s documentation, and as the installation inside Kubernetes uses the same configuration file, all of it applies also to instances within Kubernetes.

Let’s get started, shall we?

Getting started with Teleport

No, not the Star Trek thing. Teleport from goteleport.com. It is described as ‘The easiest, most secure way to access infrastructure.’ Let’s see what that means, and how to get things rolling.

Forwarding SSH traffic inside Kubernetes using Traefik

Are you running a Gitea or Gitlab instance inside your Kubernetes cluster? And you want to reach it not only via HTTPS, but also via SSH for easier pulling and pushing?

This article describes how to setup Traefik as ingress controller to do that, using Gitea as an example.

How to make git show information in your bash prompt

In a previous blogpost we learned how to use git and bash aliases and also use bash completion. Another nifty feature is showing some git information in your bash prompt. This blogpost will show you how.

How to use bash completion for your own git aliases

If you are like me, you will likely work on several different projects on a daily basis - and all of them will be stored in git.

Sure, git is easy to use. But typing the same set of commands multiple times, every day, can be quite annoying. Fortunately, using bash and git together allows to create some user-defined shortcuts.

Locking your screen when you remove your U2F device

Universal Second Factor (U2F) devices were invented as a second factor for websites using two factor authentication. The website sends a challenge, the U2F device responds if its button is pressed. A small LED starts blinking, you press your button and thus confirm the usage.

But you cannot only use U2F devices for websites. Using PAM’s pam_u2f module, you can plug it into any service that uses PAM. This was described in my previous article.

If you want to use your U2F device to unlock your running session, you need to treat it like a key. So, when you leave your desk to grab a cup of coffee, you need to take your key with you. You should of course lock your screen when you leave your desk, too. But wait – couldn’t you combine these steps? Lock your screen by removing your U2F device?

Having fun with U2F devices

Inspired by a recent article series in the German magazin c’t (1, 2, 3), I got my hands on two simple U2F devices to find out if their usage might help my work pattern.

Imagine sitting in public transportation and having to retype your (root) password for each and every sudo call you issue. Imagine having to retype your password each time your screen lock engages. Imagine just having to touch a small button on a USB device instead.