Running DNS server in Docker

TheHolm

circular dependency seems to be the case. I guess adding second external resolver to /etc/resolve.conf will help. Second entry will not be used unless first one ( pi-hole) is responding. But it need to be tested.
BTW, why do you want to send host’s DNS via pihole?

@fendrax@jlai.lu

Well, I have not really thought about why. I guess that’s partly due to old habits of running services on the host with systemd (my migration to docker is recent and still a work in progress). But I guess I’d like to continue to be able to resolve names of local devices on my network when connected through ssh on the host. Is that inherently wrong, still? I will implement the secondary DNS as a fallback. I am hoping to get rid of the issue that way.

lemmyvore

circular dependency

What’s in/etc/resolv.conf inside the dns container?

What’s the upstream dns for the dns servers in the dns container?

@fendrax@jlai.lu

In both the pi-hole (exposed on the host) and dnsmasq (used as upstream by pi-hole) containers:

# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make
 further changes once it
# has been modified.

nameserver 127.0.0.11
options ndots:0

# Based on host file: '/etc/resolv.conf' (internal res
olver)
# ExtServers: [host(127.0.0.1)]
# Overrides: []
# Option ndots from: internal

So they are pointing to docker’s embedded DNS, itself forwarding to the host.

lemmyvore

OK yeah, that might be a problem. You want to set the dns in the dnsmasq so it can resolve stuff upstream (probably with DoT or DoH), and the dns in pihole to the IP of dnsmasq. Look into the “dns”, “dns_search” and “dns_opt” compose directives.

You may also want to consider simplifing your stack by using only dnsmasq or only pihole. Both of them can do pretty much the same things if you add some plugins.

I’m using dnsmasq as lan dns server with DoH upstream as well as dhcp server. The dnsmasq is advertising itself as dns to all the dhcp clients. Also it runs on the router which allows it to hijack port 53 so any client attempting to do clear dns elsewhere ends up going through dnsmasq anyway. It also has an adblock plugin.

@fendrax@jlai.lu

Your suggestion looks similar to this other comment and makes sense. I’ll try that!

I have never managed to wrap my head around DoH and DoT but this is on my todo list ^^

I didn’t know dnsmasq has an adblock plugin, I’ll have a look. Originally, I was using dnsmasq alone (running on bare metal). Then I migrated to docker and added pi-hole for ad blocking. I tried to get rid of dnsmasq but pi-hole’s embedded DHCP is not as configurable as dnsmasq’s and I could not address my use case.

Thanks a lot for your time!

@vegetaaaaaaa@lemmy.world

Not an answer but still relevant: I actively avoid enabling unattended-upgrades for third-party repositories like Docker (or anything that is not an official Debian repository) because they don’t have the same stability guarantees, and rely on other upgrade notification methods instead.

how bad of an idea is this to run a DNS in docker and use it for the host and other containers?

Personally I would simply install dnsmasq directly on the host because it is one apt install and a configuration file away. Keep it simple.

@fendrax@jlai.lu

Yeah, that was my plan B. To be honest, I was not super confident that it would work when I put this setup together, because of the “host uses a container as DNS and docker uses the host as DNS” kind of circular dependency.

But people do use docker for DNS servers so it has to work, right? That’s where I’d like to understand where I’m wrong. I’m fine with running pi hole and dnsmasq on the host as long as I get why this is not doable in docker.

Thanks for your input, though. That’s helpful.

@vegetaaaaaaa@lemmy.world

Usually you would have a second DNS resolver configured in /etc/resolv.conf (or whatever name resolution config system you are using, resolvconf, systemd-networkd, etc). The system will fall back to this resolver if the first resolver fails to respond (and/or replies NXDOMAIN, I’m not sure. The exact order and fallback conditions may vary depending on which system you use). This can be another dnsmasq instance, a public DNS resolver, your ISP’s resolver, etc. This allows at least basic DNS resolution to work before your dnsmasq instance comes back up.

I would also add automatic monitoring for dnsmasq (either check that the service/container is running, or check the TCP connection to port 53, or check that DNS resolution is working for a known domain, etc)

@fendrax@jlai.lu

I see. I kind of thought about it earlier today while mulling over the problem. I can definitely do that first because it’s easy and makes total sense.

I already have prometheus monitoring the DNS resolution, I think. I’ll check!

Thanks for taking the time to answer!

@daddy32@lemmy.world

Shouldn’t you just have a fallback DNS for cases like these? During the outage, it would be the one used and after the things settle, you would be back at primary.

Maybe some kind of monitoring/notifications on top of thatm

@fendrax@jlai.lu

Yes, others have suggested something similar. I’ll do that first because it is easy. Monitoring-wise, I should already be covered but since prometheus is running on the same server, it was down during the outage. There is room for improvement, for sure! I have a couple of RPis on my network that I can leverage for better monitoring.

@AtariDump@lemmy.world

When it comes to a “secondary”DNS… [there is nothing like a primary and secondary DNS server. These indications are quite misleading but many systems adopted it this way. Pihole only list the DNS servers as primary and secondary, because this is what the providers write on their pages. The bad phrasing is supported especially by how Windows handles it.](https://discourse.pi-hole.net/t/primary-vs-secondary-dns/1536/2)

[Most operating systems implement DNS servers as alternatives, not as fallbacks, i.e. they will query any of both servers from time to time, so it is quite likely that you will loose your Pi-hole filtering capabilities (at least partially) [if you specify a secondary DNS server on your network].](https://discourse.pi-hole.net/t/secondary-dns-server-for-dhcp/1874)

The **ONLY** DNS server you should have set on your network is a/the PiHole(s).

@daddy32@lemmy.world

Oh my, TIL. But what then in cases like these, when the Pihole itself is down? You need fallback…

@AtariDump@lemmy.world

You need another DNS server. Fallback implies that it’s only there if the first stops responding, which isn’t how DNS works.

@fendrax@jlai.lu

For some reason, I am only seeing this comment thread now, so sorry for the late response.

Thanks for those valuable details. But I am still a bit confused. I understand why you are saying that pi hole should be the only DNS server handling requests sent by LAN devices (including the machine hosting the DNS). That’s because it is the only one which can resolve local names (well, that’s actually its upstream dnsmasq running as a sibling container that does that but that’s a minor detail).

But then you say there should be another DNS server to solve my problem. If I put two server entries in /etc/resolv.conf, one being pi hole and the other my ISP’s DNS, the two of them will be randomly picked by DNS clients. When the ISP’s is used, it will fail to translate local names. I guess there is a way to let the client try the other server after a failure but it will add some undesirable latency.

Sorry if I misunderstood your point but after reading the first comments I was quite convinced by the idea of adding a second nameserver entry in /etc/resolv.conf. Your explanations convinced me otherwise and now I have the impression that I can’t really solve my initial problem in a reliable way.

@AtariDump@lemmy.world

You should have two PiHoles.

@fendrax@jlai.lu

My goodness, that’s some impressive responsiveness ^^

I guess see your point. But then the problem shifts to the upstream dnsmasq instance which acts as DHCP + DNS for the local devices. This is the server ultimately able to translate local names.

I don’t think it’s doable to have two instances of dnsmasq that are able to translate local names interchangeably. That would require two DHCPs to have authority on the network. But I’m no expert so I may be missing something obvious.

@AtariDump@lemmy.world

You only set one DHCP server. DHCP hands out both PiHoles as DNS servers on the network.

Name resolution is handled by DNS and not DHCP.

@Willdrick@lemmy.world

Maybe a bit of a low tech solution, but I have an older RPI 3B running a second instance of PiHole.

@Smash@lemmy.self-hosted.site

I have two docker hosts which both run Pihole and get synced via gravity. I set those instances as first and second DNS servers in DHCP and on each docker host

@Decronym@lemmy.decronym.xyz

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

Fewer Letters	More Letters
DHCP	Dynamic Host Configuration Protocol, automates assignment of IPs when connecting to a network
DNS	Domain Name Service/System
IP	Internet Protocol
PiHole	Network-wide ad-blocker (DNS sinkhole)
RPi	Raspberry Pi brand of SBC
SBC	Single-Board Computer
TCP	Transmission Control Protocol, most often over IP

[Thread #683 for this sub, first seen 16th Apr 2024, 11:25] [FAQ] [Full list] [Contact] [Source code]

Running DNS server in Docker

Running DNS server in Docker

Selfhosted