Unbound issues on boot
-
You'll have to provide far more detail than that. screenshots/XML of the unbound settings, your interface configuration/status/routing/etc.
The only case to be made so far is to prevent IPv6 link-local selected or used automatically by unbound. The other parts don't make sense.
-
The scope is required. And if that doesn't work in unbound any more, it needs to be fixed upstream. The relevant bug for this was https://redmine.pfsense.org/issues/4062 BTW.
-
Ok I will register on the redmine site, and do a detailed bug report there.
I agree the suggested changes to split off IPV4/IPV6 are not important, but the link-local issue is, so I will just concentrate on that.
-
The scope is required. And if that doesn't work in unbound any more, it needs to be fixed upstream. The relevant bug for this was https://redmine.pfsense.org/issues/4062 BTW.
they seem to think its fixed on there a year ago :)
-
right ok so if the default ALL is selected then none of the outgoing interface lines get populated which does stop those errors, this may explain why it hasnt been noticed until now, I will run like this for now but do the bug report tomorrow morning.
Basically with the errored outgoing-interface the error is generated whenever a external dns lookup is performed so the log does get quite noisy.
I also retested the same option on the network interfaces setting, and it works correctly on that, it will not add the wan local-link below```
Interface IP(s) to bind to
I didnt retest if unbound works on boot up yet, will do that tomorrow morning also. -
I can confirm unbound is still dead on bootup, I even tested it again with both interface boxes set to the default ALL just to rule that out.
I also know that if it is left alone for long enough unbound eventually comes online by itself, I cannot say an exact time but I would say 30-60 minutes.Ā I found this out when the box rebooted itself earlier from a panic.
The problem also still exists on the latest snapshot with the updated unbound 1.6.0 version.
I suspect its wan interface related still as my wan does take time to come up.Ā Also pfblockerNG has dnsbl feeds configured.
-
Ok I can say why its not starting but not why this behaviour is occurring.
So as you know on ipv6.
There is a wan ipv6 link-local address on the wan interface.
For some reason and I havent been able to find out why, when unbound is started from rc.boot it tries to use the incorrect address.Ā I will not post my full address here, but its wrong on one octect.
So e.g.
Correct address is fe80::<censored>:d0e5
But its trying to bind to fe80::<censored>:d0e6I suspect this may be a bug in the sticky DUID code made by marjohn but I am not sure.
The actual WAN ip which is on the LAN interface does end in d0e6 but not the link local ip.
When I start from the GUI this issue doesnt occur.
I found some more information, will put it in the bug report I am posting now.</censored></censored>
-
Why the heck are you censoring fe80?
-
I suspect this may be a bug in the sticky DUID code made by marjohn but I am not sure.
The DUID only deals with dhcp6c, saving and restoring the duid, it's got diddly squat to do with anything else, methinks you need to look elsewhere!Ā :)
-
yeah no worries I agree with you now that was an earlier suspicion.
I now just startup unbound using the default ANY setting to get round the issue, it seems the bootup script gets confused somehow by my configuration when setting specific interfaces, I am not easy about my unbound resolver listening on my internet facing ip but its what I will have to live with for now.
-
I am not easy about my unbound resolver listening on my internet facing ip
You can always block that with a firewall ruleā¦.......
-
Which it is by default.
-
yeah I know, but its still shrewd to have it not listening as one should never rely on just one security layer.
