Bug #8194

BIND fails to respond after interface goes down

Added by Alfred Barnat over 2 years ago. Updated 6 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Affected Version:
Affected Architecture:


2.4.2-RELEASE with BIND 9.11_9 on SG-4860

Steps to reproduce:
1) Install pfSense 2.4.2-RELEASE and the BIND package, and setup a standard configuration with LAN and WAN port.
2) Disable built-in DNS Resolver and DNS Forwarder packages.
3) Enable BIND and configure it to listen on all interfaces. Confirm BIND responds to requests on the LAN interface IP.
4) Disconnect and reconnect cable to the router's LAN port.
5) Router no longer responds to DNS queries on its LAN interface IP.

This behavior is also triggered if an attached switch is rebooted, causing the LAN interface to go down briefly, or even when powering both the router and the switch on, if the switch is slower to come up than the router. And configuration changes to the BIND packages will cause it to once again listen on all interfaces that are up at the time of the settings change.


#1 Updated by Alfred Barnat over 2 years ago

  • "Any configuration changes…"

#2 Updated by Alfred Barnat over 2 years ago

Is there anything I can do to help diagnose and/or workaround this issue? This is kind of a showstopper for using the BIND package as-is (and I do need options available via BIND but not the built-in DNS Resolver). If an interface ever goes down or fails to come up before BIND launches, DNS resolution is permanently unavailable on that interface.

For now I have a cron job restarting BIND every couple hours just in case, but that's a terrible workaround on multiple levels. BIND is down briefly and loses any in-memory cache once every two hours, and it takes up to two hours for DNS resolution to work after an interface bounces.

#3 Updated by Alfred Barnat over 2 years ago

Just a quick note: As an alternate workaround, I attempted to run the DNS Resolver as the primary DNS server, forwarding certain requests that can't easily be handled by unbound to BIND. Ultimately I was unable to do this due to conflicting control ports (953) preventing both services from running simultaneously. If this sounds like something worth the time investment, please consider adding options to run the BIND package on alternate ports. This would actually make for a cleaner configuration than running either DNS Resolver or BIND alone, as I could take advantage of DNS Resolver's tight system integration while using BIND to handle everything outside of DHCP / static hostname resolution.

#4 Updated by Jared Dillard over 1 year ago

  • Category set to BIND

#5 Updated by Viktor Gurov 6 months ago

  • Status changed from New to Closed

no such issue on pfSense 2.4.5.r.20200128.2345 with BIND 9.14_1

Also available in: Atom PDF