Hey guys. Thanks for the ideas. Sadly I cannot use static IPs as we don’t control the domains.
I think I’ll use Otto’s suggestion as I am already doing that to provide a black hole table for the spamhaus drop list. So I’ll just enhance that script to manage some more tables 😀 After all, the current fqdns in pf.conf can still go out of date (pf only resolves dns -> IP once during rule apply). So this solves that too. Cheers, Andy. Sent from a teeny tiny keyboard, so please excuse typos > On 4 Jul 2019, at 09:18, Otto Moerbeek <o...@drijf.net> wrote: > >> On Thu, Jul 04, 2019 at 09:14:19AM +0100, Andy Lemin wrote: >> >> Hi guys, >> >> Is anyone else aware of the Unbound and PF race condition that exists when >> FQDNs are used in pf.conf with a local Unbound server? > > Yes, it's an obvious one isn't it? > >> >> The issue occurs when pf starts before unbound, but where pf fails to start >> as it cannot resolve some DNS names.. and so unbound also fails to work when >> it is started later in the boot because pf failed to start.. >> >> The only solution I’ve found so far is to add some commands to /etc/rc.local >> (run end of boot) to temporarily disable (the failed) pf, restart unbound, >> and restart pf again now unbound is working. >> >> Just wondering if anyone knows of a cleaner workaround? PS; Using an >> external DNS server in resolv.conf is not an option in this scenario. > > Do not use DNS names in pf.conf. Use a IP addresses or a table filled > from a file. Run some script to update the file periodically. If it > changed kick pf. > > -Otto >
