Make conditional forwarder handle unqualified names

I’ve been trying to fine-tune my local DNS setup:

  • I have the pi-hole running on a Raspberry Pi,
  • pointing to a Pfsense box for DNS,
  • with the Pfsense box resolving the external requests using DNS over TLS,
  • and have a conditional forwarder setup on the Pi-hole to forward requests for the local domain to a Windows domain controller.

But, I’ve tried deselecting “Never forward non-FQDNs,” since my intuition expected that this would forward the non-FQDNs to the local DNS server. It doesn’t work this way; requests seem to be forwarded to the Pfsense box and out to the Internet if they arrive at the pihole without a suffix. Normally I wouldn’t notice it since clients have a DNS suffix search order correctly set, but some Linux systems and WSL don’t have the local domain set, and they actually exercise this feature.

I noticed in the dnsmasq manpage that you can specify this situation to configure dnsmasq to forward unqualified name requests to a specific server. Seeing this, I tried manually adding this to the 01-pihole.conf entry for the conditional forwarder. But, when I make this change and restart the DNS server, FTL crashes.

I have two questions here.

  1. Could we make a simple tweak to pi-hole to assume that when a conditional forwarder is specified, that that server is where unqualified name requests should be routed (making the dnsmasq configuration file change to support this)?
  2. Does anyone know of a way to allow this with a configuration file tweak that won’t crash FTL?

The change should be made to a new file in the /etc/dnsmasq.d directory. Any changes you make to 01-pihole.conf will be overwritten on an update or repair to Pi-Hole.

This may indicate a problem with that command line. What is the exact configuration line entry you were using?

Thanks for the tip on the new configuration file. I’ll keep that in mind.

The manpage for dnsmasq indicated an empty // would be interpreted as handling unqualified names. So, the line I modified came out looking essentially like this one (second from the end in the 01-pi-hole.conf file, just above the server line for local reverse-DNS lookups (pointing to the same server):
server=//local.domain/192.168.0.16
(To clarify, I edited the line above by adding one / before the already-existing ‘local.domain’ entry to add an empty domain entry)

Another tip - when you make dnsmasq configuration changes, this command will check syntax:

pihole-FTL dnsmasq-test

Thanks for that one, too! When I run that command with my config file changes, the syntax check reports:

dnsmasq: syntax check OK.

But when restarting the DNS server, the pihole-FTL.log file shows (sorry, I should’ve thought to include this sooner but I was just assuming something about the pi-hole customizations to dnsmasq weren’t expected to work with the configuration change):

[2020-01-17 14:53:35.636 729] ########## FTL started! ##########
...
[2020-01-17 14:53:35.933 731] Listening on port 4711 for incoming IPv4 telnet connections
[2020-01-17 14:53:35.933 731] Listening on port 4711 for incoming IPv6 telnet connections
[2020-01-17 14:53:35.934 731] Listening on Unix socket
[2020-01-17 14:53:35.936 731] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[2020-01-17 14:53:35.936 731] ---------------------------->  FTL crashed!  <----------------------------
[2020-01-17 14:53:35.936 731] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[2020-01-17 14:53:35.936 731] Please report a bug at https://github.com/pi-hole/FTL/issues
[2020-01-17 14:53:35.936 731] and include in your report already the following details:
[2020-01-17 14:53:35.936 731] FTL has been running for 0 seconds
[2020-01-17 14:53:35.936 731] FTL branch: master
[2020-01-17 14:53:35.936 731] FTL version: v4.3.1
[2020-01-17 14:53:35.936 731] FTL commit: b60d63f
[2020-01-17 14:53:35.936 731] FTL date: 2019-05-25 21:37:26 +0200
[2020-01-17 14:53:35.936 731] FTL user: started as pihole, ended as pihole
[2020-01-17 14:53:35.937 731] Received signal: Segmentation fault
[2020-01-17 14:53:35.937 731]      at address: 0
[2020-01-17 14:53:35.937 731]      with code: SEGV_MAPERR (Address not mapped to object)
[2020-01-17 14:53:35.937 731] Backtrace:
[2020-01-17 14:53:35.937 731] B[0000]: /usr/bin/pihole-FTL(+0x1a25c) [0x4d325c]
[2020-01-17 14:53:35.937 731] B[0001]: /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0) [0xb6de6130]
[2020-01-17 14:53:35.937 731] B[0002]: /usr/bin/pihole-FTL(check_servers+0x87) [0x4fe7c4]
[2020-01-17 14:53:35.937 731] B[0003]: /usr/bin/pihole-FTL(main_dnsmasq+0xeab) [0x4fb5a8]
[2020-01-17 14:53:35.937 731] B[0004]: /usr/bin/pihole-FTL(main+0x87) [0x4d1e18]
[2020-01-17 14:53:35.937 731] B[0005]: /lib/arm-linux-gnueabihf/libc.so.6(__libc_start_main+0x10c) [0xb6dd0718]
[2020-01-17 14:53:35.937 731] Thank you for helping us to improve our FTL engine!
[2020-01-17 14:53:35.937 731] FTL terminated!

You discovered a bug in the embedded dnsmasq. I already submitted a bugfix upstream. Meanwhile, you can simply split the line you’re using into:

server=//192.168.0.16
server=/local.domain/192.168.0.16

Thanks! When I put up that stack trace it reminded me this was open-source, so I looked at check_servers() a bit and tried toggling things in there that impact how it operates, but the only thing that mattered I think was having both the empty domain and a specified domain. I did set it up last night to split those lines up like you suggested but I wasn’t sure it was working until pretty late because the WSL I was using to send requests without a suffix seemed to learn the correct suffix to submit at some point. I figured out to switch to using dig afterwards, and that does appear to work.

So I added a second config file to be parsed after the one pi-hole generates and added the top line there. While I was at it I added a reverse-DNS lookup for separate subnets the same way. :slight_smile:

Thanks for the help/workaround! I’m sure everyone says it but you guys put together a great project here.

1 Like

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