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 <otto@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
>