DNS Infrastructure - Architecture and reasoning

DNS Architecture

I have over the years refined the way I see my DNS infrastructure, this is the one I have in my homelab currently :

This diagram reflects some technical choices I’ve come to like for their simplicity. Here’s a small description of the design :

• The clients and servers are connected to a PiHole DNS resolver
• The PiHole has a conditional forwarding to the FreeIPA
• It recurses to an external DNS provider otherwise

This allows me some finesse. I can now :

• Firewall off DNS for the FreeIPA, except for the PiHole
• Move the FreeIPA without major DNS resolution problems, as I just have to change forwarders
• Prevent recursion on FreeIPA itself
• Benefit from PiHole for DNS filtering
• Disallow recursion for some hosts (yes) using PiHole groups

The idea stems from the purpose of FreeIPA itself. Its role shouldn’t be to ensure upstream DNS resolution, as it puts some dependencies on a system that’s already critical to operate most of the time. It also allows me to limit the risk a bit, when it comes to attack surface as I can limit what will reach it. It’s also a fun way to have multiple domains, that I can reach through a single system without having to fiddle too much.

This is actually simple to do on PiHole, just create a file /etc/dnsmasq.d/02-forward.conf and add in the following content :

# This is my config, adapt whenever applicable
rev-server=192.168.0.0/16,192.168.100.1
rev-server=192.168.0.0/16,192.168.100.2
server=/home.epicfail.be/192.168.100.1
server=/home.epicfail.be/192.168.100.2
server=/lab.epicfail.be/192.168.30.90
server=/lab.epicfail.be/192.168.30.91

rev-server will provide a conditional forwarder for PTR records, server provides a conditional forwarder for A, AAAA, CNAME, TXT, … All the things :)

There’s however a big potential problem that some reader will have noticed already. The DNS requests seen by FreeIPA will come from PiHole and the information will less usable in the context of some N-IDS. This is a good thing as it allows to have an insight into how a real enterprise network might look like. Not done yet, but the plan is to collect the logs from PiHole, collect the network traces, and use an elastic SIEM to correlate them together. PiHole logs the client IP along the query, so the information still exists. The centralisation of that information within a logfile is appreciable.

Next steps

There’s something big which has already been present for a long-time, that I am evaluating at a far slower pace. I’ll address the elephant in the room. DNS-over-TLS and its sibling, DNS-over-HTTPS.

I’m currently using PiHole, with FreeIPA. This one has a seemingly pretty easy setup per PiHole dnscrypt-proxy Documentation. With N-IDS, correlation will become unfeasible unless it relies on TLS decryption. It’ll have to come from the PiHole logs, which is annoying.