Bug 1291449 - unbound errors out for slow IPv6 SLAAC address assignments
unbound errors out for slow IPv6 SLAAC address assignments
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: unbound (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Paul Wouters
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-14 16:41 EST by Wolfgang Rupprecht
Modified: 2016-03-09 15:12 EST (History)
5 users (show)

See Also:
Fixed In Version: unbound-1.5.8-1.fc23
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-09 10:51:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wolfgang Rupprecht 2015-12-14 16:41:27 EST
Description of problem:

When an IPv6 interface uses SLAAC to get its address it sometime takes 30 seconds after booting under fedora 23 with NetworkManager.   If unbound is configured to run on such a delayed address then it will exit instead of waiting for that interface to be created.

Version-Release number of selected component (if applicable):
unbound.x86_64                       1.5.6-1.fc23                       @updates

How reproducible:
always with a slow IPv6 router solicitation
rarely with a fast router solicitation

Steps to Reproduce:
1. Reboot
2. systemctl status unbound
3.

Actual results:

Dec 14 03:37:17.503802 arbol.wsrcc.com systemd[1]: Starting Unbound recursive Domain Name Server...
Dec 14 03:37:17.546244 arbol.wsrcc.com unbound-checkconf[1069]: unbound-checkconf: no errors in /etc/unbound/unbound.conf
Dec 14 03:37:17.658756 arbol.wsrcc.com systemd[1]: Started Unbound recursive Domain Name Server.
Dec 14 03:37:17.674293 arbol.wsrcc.com unbound[1104]: Dec 14 03:37:17 unbound[1104:0] error: can't bind socket: Cannot assign requested address for fd47:3cf0:52aa:0:a60:6eff:fe74:6fe2
Dec 14 03:37:17.674578 arbol.wsrcc.com unbound[1104]: Dec 14 03:37:17 unbound[1104:0] fatal error: could not open ports
Dec 14 03:37:17.675401 arbol.wsrcc.com systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE
Dec 14 03:37:17.677509 arbol.wsrcc.com systemd[1]: unbound.service: Unit entered failed state.
Dec 14 03:37:17.677918 arbol.wsrcc.com systemd[1]: unbound.service: Failed with result 'exit-code'.


Expected results:
no errors or exit

Additional info:

It appears that NetworkManager is slow to get a router solicitation.   I now see  from the logs that it tries several times until it succeeds. If that were working better this wouldn't be so much of an issue.

It would be nice if unbound just set a timer and tried to open the interface periodically.
Comment 1 Paul Wouters 2015-12-14 17:59:59 EST
in unbound-1.5.7 you can use:

      ip-transparent: <yes or no>

If  yes,  then  use  IP_TRANSPARENT  socket option on sockets where unbound is listening for incoming traffic.  Default no.  Allows you to bind to non-local interfaces.  For example for  non-existant  IP addresses  that  are  going  to exist later on, with host failover configuration.  This is a lot like interface-automatic, but that one services all interfaces and with this option you can  select  which (future)  interfaces  unbound provides service on.  This option needs unbound to be started with root permissions on some systems.

I have not tested this option yet. And we do not yet enable it per default.

Does that address your issue?
Comment 2 Wolfgang Rupprecht 2015-12-16 05:38:16 EST
(In reply to Paul Wouters from comment #1)
> in unbound-1.5.7 you can use:
> 
>       ip-transparent: <yes or no>

Thanks! I just tried it.  It seems to be doing the trick on a short test.   I'll update this bugzilla if I see it failing.

This option's name didn't catch my eye.   Something with "retry" or "non-existent" in the name would have been better.

It might be good to also add it to /etc/unbound/unbound.conf .

Thanks again for the quick reply.
Comment 3 Fedora Update System 2016-03-02 22:00:49 EST
unbound-1.5.8-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3a8f0c9c3c
Comment 4 Fedora Update System 2016-03-03 16:58:04 EST
unbound-1.5.8-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3a8f0c9c3c
Comment 5 Fedora Update System 2016-03-09 10:51:30 EST
unbound-1.5.8-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Comment 6 Fedora Update System 2016-03-09 15:12:05 EST
unbound-1.5.8-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.