DHCP does not advertise router as DNS server after installing unbound

Hi there,

Before I installed unbound I just had dnsmasq running for DNS.
The WAN interface uses the peer DNS and the LAN interface had not DHCP options set, it was happily running dynamic DHCP and advertising the router as DNS server.

DHCP stopped advertising the router as DNS server after I installed unbound (i think in serial to dnsmasq, also to support DHCP). I used the config option Link to dnsmasq in LUCI UI.

Sure I can put in 6,"router-ip" as DHCP option to fix it, but that is not really elegant.
How can the old default behavior be restored? Was any configuration inadvertantly changed by the installation?

Any help appreciated.

Some version info and relevant bits from /etc/config/unbound and /etc/config/dhcp may help.

1 Like

so which bits would you like?

Unconfirmed in code, but it isn’t unreasonable that if dnsmasq is not providing DNS on the interface that it wouldn’t advertise that interface’s IP as the DNS server without explicit configuration.

Edit: xref

That may be true for IPv4 where dnsmasq (by default) manages the DHCP server too. But for IPv6, odhcpd does the job and it should advertise the DNS server correctly.

@jus7incase, have you noted if the IPv6 DNS is correctly configured in your clients?

1 Like

DHCPv6 advertises a DNS recursive name server.

DHCP(v4) only if I put the IP address into DHCP options. Is that the right way to do it? Better suggestions?

This seems to be a known issue. There is an article (What is DNS Privacy and how to set it up for OpenWRT) that mentions it and a more elegant solution than hardcoding a static IP for each internal interface:

example for lan:
uci add_list "dhcp.lan.dhcp_option=option:dns-server,$(uci get network.lan.ipaddr)"

list dhcp_option 'option:dns-server,0.0.0.0'
1 Like

Please don't tell me that this work. I've been fighting against Unbound when using two LAN networks and that looks like the perfect solution :man_facepalming:

I don't understand what would be the problem with 2 interfaces. The DHCP options are defined per interface, not globally. on the UI just go to Network>Interfaces>LAN>Advanced Setting>DHCP Server>Advanced Settings>DHCP Options. Same from DMZ or what ever internal lan. Take a look at this UCI example for 2 lans called lan and DMZ:

uci add_list "dhcp.lan.dhcp_option=option:dns-server,0.0.0.0"
uci add_list "dhcp.DMZ.dhcp_option=option:dns-server,0.0.0.0"

gives in /etc/config/dhcp:

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv6 'server'
	option ra 'server'
	option ra_management '1'
	list dhcp_option 'option:dns-server,0.0.0.0'

config dhcp 'DMZ'
	option start '100'
	option leasetime '12h'
	option limit '150'
	option interface 'DMZ'
	option ra 'server'
	option dhcpv6 'server'
	option ra_management '1'
	list dhcp_option 'option:dns-server,0.0.0.0'

Thanks I tested it with wireshark. the DHCP server will really replace the 0.0.0.0 with the IP of the respective interface from where it is sending the packet. That's awsome advice!

-- Maybe I was a bit too fast or too enthusiastic. Acually I received some DHCP ACK not containing the DNS Server option when it was set to 0.0.0.0 Setting it back to the actual IP made the option re-appear. But also setting it to 0.0.0.0 then worked again - I guess I have to keep an eye on it for now.

Just to be clear for the people wondering: the problem that @jus7incase doesn't understand is that some people doesn't use DNSMASQ, making this solution useless for odhcpd. Not trying to say this does not work, don't get me wrong. But people using odhcpd will lost their DHCP server without reason and it's worth saying it.

1 Like

OK, I did not get that you are not running dnsmasq. I m actually running odhcpd, dnsmasq and unbound in parallel. Is dnsmasq obsolete here or odhcpd?

Neither of both. I replaced DNSMASQ with odhcpd and unbound to keep attack surface, ROM and RAM as tidy as possible. It's well documented in the wiki but I'm mainly here to say people to not try this with odhcpd because it will make it immediately crash and then enter in a crash loop.

This problem is not present when using odhcpd, by the way so it's not worth trying.

2 Likes

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