Kresd dominates Pi-hole in LXC container for DNS requests despite dedicate IP addresses

Software SW help
1

On my Omnia Turris router, I installed Pi-hole in a LXC container and assigned a dedicated IP address to the container. The goal is to access the existing kresd DNS resolver and the Pi-hole DNS resolver independently of each other:

  • 192.168.1.1: kresd
  • 192.168.1.2: Pi-Hole

To test that correct resolver answers my DNS request, I request the resolution of pi.hole, a special domain used by Pi-hole that should always point to the Pi-hole’s IP.

The problem that I now face is that while I can access the Pi-Hole’s web interface in the browser via the dedicated IP, pi.hole does not get resolved. Hence, it seems as if always and independently of the IP kresd is replying instead. When I ssh into my router or even into the LXC container, then pi.hole gets correctly resolved.

Following my test setup:

From an external machine on the network:

me@pc:~# nslookup pi.hole 192.168.1.2
Server:     192.168.1.2
Address:    192.168.1.2#53

** server can't find pi.hole: NXDOMAIN

me@pc:~# curl -I "http://192.168.1.2/admin/login"
HTTP/1.1 200 OK
...

From the router:

root@turris:~# nslookup pi.hole 192.168.1.2
Server:     192.168.1.2
Address:    192.168.1.2:53

Name:   pi.hole
Address: 192.168.1.2

Name:   pi.hole
Address: fd00:...

root@turris:~# curl -I "http://192.168.1.2/admin/login"
HTTP/1.1 200 OK
...

From inside the LXC container of the router:

root@pihole:~# nslookup pi.hole 192.168.1.2
Server:     192.168.1.2
Address:    192.168.1.2#53

Name:   pi.hole
Address: 192.168.1.2
Name:   pi.hole
Address: fd00:...

root@pihole:~# curl -I "http://192.168.1.2/admin/login"
HTTP/1.1 200 OK
...

In short:

Pi-hole External Device Router LXC Container
Web Interface :white_check_mark: :white_check_mark: :white_check_mark:
DNS (pi.hole resolves) :cross_mark: :white_check_mark: :white_check_mark:

I don’t have any dedicated forwarding or firewall rules. Is there any other setting that allows kresd to hijack any incoming DNS request?

For completeness, here my LXC container network configuration:

lxc.net.0.type = veth
lxc.net.0.link = br-lan
lxc.net.0.name = eth0
lxc.net.0.flags = up
lxc.net.0.hwaddr = ...
lxc.net.0.ipv4.address = 192.168.1.2
lxc.net.0.ipv4.gateway = auto
lxc.net.0.ipv6.address = ...
lxc.net.0.ipv6.gateway = auto

While I feel comfortable with Linux, I am lacking knowledge on the network side of things. Any hint is much appreciated. Thanks in advance!

2

Normally /etc/config/resolver contains

config resolver 'common'
        list interface '0.0.0.0'
        list interface '::0'

i.e. the resolver listens on all addresses assigned to the router. I expect that is the root of your problem.

3

If I remember right, the default is better (when these lines are removed).

4

Thanks a lot, @vcunat, for the reply. Indeed having such a generic binding looks like the culprit. Unfortunately, after removing the two interface options that you mentioned and restarting the resolver, I am still confronted with the same issue. Could it be that kresd has additional options that let it bind to all interfaces?

root@turris:~# netstat -tulnp | grep ":53 " | grep -v ":5353"
tcp        0      0 127.0.0.1:53            0.0.0.0:*   LISTEN      5701/kresd
tcp        0      0 192.168.1.1:53          0.0.0.0:*   LISTEN      5701/kresd
tcp        0      0 2001:...:53 :::*                    LISTEN      5701/kresd
tcp        0      0 ::1:53                  :::*        LISTEN      5701/kresd
tcp        0      0 fe80:...:53 :::*                    LISTEN      5701/kresd
tcp        0      0 fd00:...:53 :::*                    LISTEN      5701/kresd
5

Maybe its a firewall issue. Check:

telnet pihole.ip 53

From external device. Also Adblock by default makes port redirection rule of all 53,5353,853

Also maybe its something related to pihole resolving itself. Try adding static entry to pihole with its IP

Also when your LXC cobtainer is in the same network as your pc. I would try different device in the same network like a mobile phone for example. To rule out problem on pc.

1 Like
6

I thought that I have ruled this one out. But as a matter of fact I have not :stuck_out_tongue: Thanks for mentioning it. After some trying around, I found that I had a long forgotten rewrite rule that forced any unencrypted DNS requests to an encrypted server. What seemed smart then was not at all.

Long story short, that solved it! I also re-added the generic interface configuration options and it seems that even with them, pi-hole remains reachable. So it was only my local machine that was the problem. Sorry about that and thanks for the help!

1 Like
7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.