Aren’t new version enabling (some.host) to not race ? On Thu, Jul 4, 2019 at 7:26 AM Andy Lemin <andrew.le...@gmail.com> wrote:
> 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 > > > > -- -- --------------------------------------------------------------------------------------------------------------------- Knowing is not enough; we must apply. Willing is not enough; we must do
