6565b3c140
We are seeing a problem on Fedora where it appears on hosts without configured ipv6 unbound chooses to send queries via the ipv6 forwarders and then returns DNS failures. An upstream issue has been filed [1], but it remains unclear exactly why this happens on Fedora but not other platforms. However, having ipv6 forwarders is not always correct. Not all our platforms have glean support for ipv6 configuration, nor do all our providers provide ipv6 transit. Therefore, ipv4 is the lowest common denominator across all platforms. Even those who are "ipv6 only" still provide ipv4 via NAT -- originally it was the unreliability of this NAT transit that lead to unbound being used in the first place. It should be noted that in most all jobs, the configure-unbound role [2] called from the base-job will re-write the forwarding information and configure ipv4/6 correctly during the base job depending on the node & provider support. Thus this only really affects some of the openstack-zuul-jobs/system-config integration jobs, where we start out without unbound configured because we're actually *testing* the unbound configuration role. An additional complication is that we want to keep backwards compatability and populate the settings if NODEPOOL_STATIC_NAMESERVER_V6 is explicitly set -- this is sometimes required if you building infra-style images and are within a corporate network that disallows outbound DNS queries for example. Thus by default only populate ipv4 forwarders, unless explicitly asked to add ipv6 with the new variable or the static v6 nameservers are explicitly specified. [1] https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4188 [2] http://git.openstack.org/cgit/openstack-infra/openstack-zuul-jobs/tree/roles/configure-unbound Change-Id: If060455e163266b2c3e72b4a2ac2838a61859496 |
||
---|---|---|
.. | ||
elements | ||
scripts | ||
nb03.openstack.org.yaml | ||
nl01.openstack.org.yaml | ||
nl02.openstack.org.yaml | ||
nl03.openstack.org.yaml | ||
nl04.openstack.org.yaml | ||
nodepool.yaml |