Re: DNS Race Condition on Boot
Aren’t new version enabling (some.host) to not race ? On Thu, Jul 4, 2019 at 7:26 AM Andy Lemin 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 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
Re: DNS Race Condition on Boot
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 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 >
Re: DNS Race Condition on Boot
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
DNS Race Condition on Boot
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? 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. Cheers, Andy. Sent from a teeny tiny keyboard, so please excuse typos
