Project

General

Profile

Bug #8194

BIND fails to respond after interface goes down

Added by Alfred Barnat almost 2 years ago. Updated 10 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
BIND
Target version:
-
Start date:
12/12/2017
Due date:
% Done:

0%

Estimated time:
Affected Version:
Affected Architecture:

Description

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.

History

#1 Updated by Alfred Barnat almost 2 years ago

  • "Any configuration changes…"

#2 Updated by Alfred Barnat almost 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 almost 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 10 months ago

  • Category set to BIND

Also available in: Atom PDF