Get around DNS restart and still have client register?

iorx

Hi,

By design enabling client to register their hostname restarts Unbound.
Is there any solution to prevent this restart?

bingo600

@iorx
To my knowledge - Not within pfSense

I'm using ISC-DHCP on a Linux Server with Bind9 (Linux DNS) DDNS (Dynamic Dns) to avoid that issue.
I then use the pfSense DHCP forwarder to forward the DHCP requests to my Linux , and have set unbound to forward all queries to my Linux Bind9 DNS server.

Warning .... That's NOT a beginners task on Linux.

A Microsoft DHCP server would be easier to setup.
But might be $$$$ , as it is M$

/Bingo

iorx

@bingo600

Got a couple of Windows Server (stand alone; no AD) running (Hyper-V guests, pfsense also a guest in Hyper-V) but I kind of want this "basic network function" to be available on the firewall as it's convenient to have all stuff there related to look up and hosts.

Thank you for a possible way to achieve it. I do some research before going that route.

So, how can pfBlocker update Unbound without restart?
From the GUI of pfBlocker, an option:

Resolver Live Sync
Enable
When enabled, updates to the DNS Resolver DNSBL database will be performed Live without reloading the Resolver.
This will allow for more frequent DNSBL Updates (ie: Hourly) without losing DNS Resolution.
This option is not required when DNSBL python blocking mode is enabled.

Shouldn't is be possible to use the same technique with DHCP-registrations within pfSense?

bingo600

@iorx
I have no pfBlocker experience , dont use it

iorx

@bingo600

OK, the question should maybe be towards someone here a bit in to development and the inner workings of pfSense.
Thank you anyway for your response.

Brgs,

Gertjan

@iorx said in Get around DNS restart and still have client register?:

Is there any solution to prevent this restart?

The DHCP servers still works just fine.
The /var/dhcpd/var/db/dhcpd.leases file still contains the actual state of all leases on the LAN"s.

Unbound doesn't use or read "/var/dhcpd/var/db/dhcpd.leases"
The process dhcpleases was created to read from the file /var/dhcpd/var/db/dhcpd.leases and outputs in the classic /etc/hosts file and /var/unbound/dhcpleases_entries.conf file. This on is sourced by the unbound config file.

The thing is : unbound only reads its config during startup.
It can not (re)read this file, or any other file when it's doing what unbiound does : resolving.
if it did, resolving would get limited to disk IO speed. Resolving will take a huge hit in speed.

51741  -  Ss       0:00.01 /usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d my-local-domain.tld -p /var/run/unbound.pid -u /var/unbound/dhcpleases_entries.conf -h /etc/hosts

What it does : if wait for a file event on "-l /var/dhcpd/var/db/dhcpd.leases". If that event happens, it get parsed, and "-u /var/unbound/dhcpleases_entries.conf" ( and -h /etc/hosts) are re created.
Then, if "-p /var/run/unbound.pid" exists, then unbound is actually running, so dhcpleases send a signal to it.
This is the message :
Drop dead, and resurrect.

This is how new leases get registered ion the DNS.
Actually quit elegant, even I could have written it.
Its actually not bad at all as an implementation.

Now, with our modern day networks filled up with all the Chinese ** connected gadgets that execute a DHCP every x seconds or so and/or behave as of their lease is 1 second, no matter what.
You've just nuked your unbound (DNS) process.

A problem like this couldn't exist in the past. When a new device was added, (dhcp) log files were closely observed, to be sure nothing out of the ordinary shows up.
Local bandwith wasn't an close to unlimited resource back then. We didn't have Multi tera flops processors to handle nice stuff like web servers for GUI's.

** you know what I mean. admin's these day can also use bad cables, lousy switches, or use bad power, or messed up wifi signals. All these are good ingredients in the "let's chain gun pfSense with DHCP requests".

keyser

@gertjan The funny thing is this has been an issue for years, and unbound has long since adopted a dynamic update feature - while running - using the python integration that pfBlockerNG uses.

There is just no developers or netgate people that finds it important enough to actually fix the dhcpleases process to use the new integration instead of the 1990’s style full restart.

Seems most are content - like you - with just creating static DHCP leases for everything (which is a horrible solution and doesn’t scale at all).

I cannot fix it myself because I have no coding or scripting skills.

Wonder if we could make a petition to actually get an idea of how many would like this fix to be bumped to the top of the “to-do” list @ netgate.

iorx

@gertjan

Thank you for the good, educational and informative read!

What I can see I don't suffer much of the machine gunning you're mentioning. But now and then, once in a bluemoon, I hit the restart window and get a timed out request, I think.
Those 5s in the log here is when Unbound is restarting I presume.

So to give an idea of how it looks here.

See attached txt-file (I was considered spaming... trying with inline logs)

log-dhcp-unbound.txt

But how is pfBlocker able to inform Unbound of changes and not restarting it? It's "Resolver Live Sync" thingy?
(I read and reread your reply but couldn't parse if this was answered, as me not fully understanding... )

thiasaef

@gertjan said in Get around DNS restart and still have client register?:

Its actually not bad at all as an implementation.

It actually is the worst possible way of doing it: https://redmine.pfsense.org/issues/5413

Gertjan

@thiasaef said in Get around DNS restart and still have client register?:

@gertjan said in Get around DNS restart and still have client register?:

Its actually not bad at all as an implementation.

It actually is the worst possible way of doing it: https://redmine.pfsense.org/issues/5413

That "worse" implementation can be undone.

There :

and done.

Doing what the redmine proposes :

Should be changed to something like this:
$unbound_cmd .= "unbound-control local_data {$host['fqdn']} {$type} {$host['ipaddr']}";

is a no go because command line parameters are only read during startup.
Ok, Netgate could re write (fork) unbound. But unbound it's as big as bind, it's still a big project.

A far better method could be : use unbond-control (very comparable with the rndc tool from bind) : it can change in memory 'cache' items on the fly, during unbound execution.

Or, as I said earlier : adding a python extension (like pfBlockerNG-devel did) that consults the DHCP leases list every 60 seconds or so, extract new leases, remove expired leases.

It surprises me that it hasn't been done yet.
Btw : unbound was written with a stand alone device in mind, that needs a resolver, as forwarding is something of the past. A resolver also open the DNSSEC door.
unbound was never meant to be used ( my impression) on a router firewall that also has a DHCP server, with the DHCP clients on the LANs lease info put into the local DNS system.
Every decent router firewall has (should have) such a functionality.

thiasaef

@gertjan said in Get around DNS restart and still have client register?:

A far better method could be : use unbond-control

You do realize that the Redmine Ticket suggests exactly that?

iorx

@iorx

I circle back to the original problem here. Interrupt free DNS.

I went for this route:

Pi-Hole in a VM in DietPi
Forwarders in Pi-Hole for my local domains pointing to pfSense
Changed DHCP option to point at the Pi-Hole

Got local name resolution for registered devices and a rather pretty GUI to check whats been going down in the name resolution swamp.

The subject on Unbound restarts seems a potato

bingo600

@iorx said in Get around DNS restart and still have client register?:

@iorx

I circle back to the original problem here. Interrupt free DNS.

I went for this route:

Pi-Hole in a VM in DietPi

Nice workaround
I use Pi-Hole too on a Debian VM (instead of pfBlockerNG)
Do you use the PI-Hole as DHCP server now , instead of pfSense or ??

Forwarders in Pi-Hole for my local domains pointing to pfSense
Why ???

What local domains do you need to have resolved on the pfSense , if everything uses the PI-Hole ?

Changed DHCP option to point at the Pi-Hole

I suppose you mean the DHCP DNS option , handed out to clients ?

Got local name resolution for registered devices and a rather pretty GUI to check whats been going down in the name resolution swamp.

The subject on Unbound restarts seems a potato

Do you have multivlan (IP-Net) DHCP scopes on the pihole or ?

/Bingo

iorx

@bingo600 said in Get around DNS restart and still have client register?:

@iorx said in Get around DNS restart and still have client register?:

@iorx

I circle back to the original problem here. Interrupt free DNS.

I went for this route:

Pi-Hole in a VM in DietPi

Nice workaround
I use Pi-Hole too on a Debian VM (instead of pfBlockerNG)
Do you use the PI-Hole as DHCP server now , instead of pfSense or ??

No, pfSense is still DHCP server.

Forwarders in Pi-Hole for my local domains pointing to pfSense
Why ???

Got a couple of VLANs. work, kids, iot and guest. These domains are forwarded to pfSense to find hosts there.
Also got like 5 VPN-tunnels and overrides in pfSense Unbound to query DNS server on the other side of those.

What local domains do you need to have resolved on the pfSense , if everything uses the PI-Hole ?

You're probably right here. pfSense it self doesn't need to resolve hostnames in all subnets/tunnels. Haven't decided yet if I'm going to populate PiHole with overrides or keep them in pfSense.

Changed DHCP option to point at the Pi-Hole

I suppose you mean the DHCP DNS option , handed out to clients ?
Correct! Bad wording here.

Got local name resolution for registered devices and a rather pretty GUI to check whats been going down in the name resolution swamp.

The subject on Unbound restarts seems a potato

Do you have multivlan (IP-Net) DHCP scopes on the pihole or ?

Yes to VLANs. No to DHCP in Pi-hole , haven't checked out that feature yet. Pretty new to Pi-hole, looks interesting, will investigate.

/Bingo

Brgs, iorx

DLFerguRD

My solution is similar to @bingo600

DHCP server is on pfsense. Handles LAN IOT and Guest networks
Bind9 is on my internal linux server.
I use the dynamic dns updates section of the DHCP server to update the Bind9 server using the rndc-key. Use a host override in unbound to point my local networks to the internal Bind9 server.
I use pfblocker and for me this gives internal name resolution on all the pfblocker reports.

keyser

@dlfergurd Simple enough workarounds, but completely hopeless/stupid that this is necessary, for a feature that has worked in standard products for almost 20 years now.
Worse still - it has no priority to get fixed i pfSense….

iorx

@keyser

https://redmine.pfsense.org/issues/5413
But I read this thread correctly? To me it looks like a solution has been delivered there, tested and committed?

keyser

@iorx said in Get around DNS restart and still have client register?:

@keyser

https://redmine.pfsense.org/issues/5413
But I read this thread correctly? To me it looks like a solution has been delivered there, tested and committed?

Yeah, I thought that as well until i read the thread carefully - including inspecting the dates on posts.
The proposed code based on the high level code has never been adopted beyond a proposal. The proposed fix thread then stopped once that happened (more than a years ago).
The reason we misread the thread is because someone suggests you just disable DHCP registrations, and another poster confirms that fix works well. But he’s not talking about the code, he’s talking about the workaround to disable DHCP registrations.

So it’s still a dead end…..