Unbound stops listening on Interface

Gertjan

I'm not using vlan's myself, so can't test such a setup, but I just ripped out the connector of one of my OPTx interfaces. Unbound didn't move.
When It back in, DNS (unbound) on that interface worked.

In the logs, no messages from unbound.
Some tasks were activated as a result of the interface down/up event, like - system log :

em2: link state changed to DOWN
/rc.linkup: Hotplug event detected for PORTAL(opt1) static IP (192.168.2.1 )
em2: link state changed to UP
etc.

but nothing in the unbound / resolver log.

Workaround : put a switch between the PC and pfSense.
Is this interface part of a VLAN ?

The PC ist directly connected to a physical port. No VLAN involved on this port, but a different subnet. I can't reproduce the problem with unplugging the device for a short time too. But every morning it is broken and only this interface is not listed with an open dns socket. Maybe pfBlockerNG ist somehow involved. I'll try to disable it this night.

I can reproduce it: Connect a PC directly with a LAN port of the pfsense and boot the PC up. Stop DNS Resolver (no reload), unplug lan cable, start Resolver, wait for start, wait some seconds more, connect PC. Then I can't resolve DNS with my PC. (Maybe need two tries to get the result)

Can someone else confirm this?

Gertjan

I think I understands what happens.

@thisisme said in Unbound stops listening on Interface:

unplug lan cable, start Resolver

What happens at this very moment :
When unbound starts, it enumerates active interfaces. It will not 'bind' to interface that are not used/active. I have myself an quand Intel NIC PCI card, two of the ports are unused. These are unknown to unbound. After all, these NICs have no IP assigned.

Now for the fun part :

@thisisme said in Unbound stops listening on Interface:

wait some seconds more, connect PC

So the NIC comes on line. It was already known to pfSEnse, so an IP gets assigned
And I do presume that the assigned DHCP server process gets waked up, and start dealing out leases.
But ..... unbound does not do something as "reacting to NIC up link messages". It keeps the list of known NIC's that were on line when it started. Your NIC comes up later on. unbound doesn't care. You have to re "start" unbound.

When you restart unbound now, it will 'see' the NIC, and serve that NIC with DNS services.

As said : Workaround : put a switch between the PC and pfSense. This way, the interface won't go down anymore - unbound keeps 'seeing' it as active, and even when unbound restarts, the interface won't get lost.

Stubbs

This post is deleted!

Can I report this somewhere? Never had any problems before. This comes up with the latest update.

yao

Same here. I'm using multiple VLAN interfaces in pfSense. And just upgraded to pfSense2.5. After that the DNS resolver keep stopped working. i have to start it again and again. no logs showing why the Unbound stopped.

@thisisme said in Unbound stops listening on Interface:

. All of them work properly except one. Unbound stops listening on this interface daily. Pfsense shows an open socket (port 53)for every interface/vlan

bingo600

@yao

Have you seen this one
https://forum.netgate.com/topic/160005/unbound-crashes-periodically-with-signal-11/72

/Bingo

yao

@bingo600
Thanks so much for pointing me to that thread!
Updated Unbound to 1.13.1 by running pkg upgrade -fy unbound
And so far it is stable for at least 2 hours!
I think the problem resolved!!
Thanks again!

BTW, i have both "Register DHCP leases in the DNS Resolver" and the Register DHCP static mappings in the DNS Resolver enabled.

vbredjp

still crashing after updating to Unbound to 1.13.1
possibly just not as often
had crash around 1-2 days after upgrade that is still not acceptable.

thiasaef

Why is there still no proper fix for this issue? It is still completely broken in 2.6.0 and both patches that are supposed to "fix" this in 2.7.0 are nothing but a mere workaround:

With these patches applied every restart of a device connected to one of the in/out interface of the DNS Resolver causes a restart of the unbound service (including complete loss of cache and temporary loss of DNS resolution for all devices). This bug is going to force me to downgrade back to 2.4.5-p1 and will eventually make me chose another firewall solution in the near future.

Sorry if I sound frustrated, but major bugs like this should not be ignored like this for almost a year.