yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #38439
[Bug 1495465] [NEW] RDNSS Option should be included in ICMPv6 Router Advertisements
Public bug reported:
The ICMPv6 Router Advertisements on an IPv6 subnet handled by Neutron
does not contain the Recursive DNS Server Option, even though the subnet
has been created with an appropriate "dns_nameservers" parameter. This
means that instances on a subnet using SLAAC does not learn any DNS
servers, and thus cannot resolve any hostnames after being provisioned.
That is likely to break lots of things, such as further provisioning of
applications to the instance.
The RDNSS option is documented in RFC 6106. It can be configured in
radvd.conf using the following syntax:
interface qr-foo {
RDNSS server1 [server2 ...] {
# this is optional, but prevents problems noted in the second bullet of
# https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-02#appendix-B
AdvRDNSSLifetime infinity;
};
};
Observed on OpenStack Kilo.
Note: It might be that using DHCPv6 in some capacity would work around
this issue. I have not yet tested this, though.
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1495465
Title:
RDNSS Option should be included in ICMPv6 Router Advertisements
Status in neutron:
New
Bug description:
The ICMPv6 Router Advertisements on an IPv6 subnet handled by Neutron
does not contain the Recursive DNS Server Option, even though the
subnet has been created with an appropriate "dns_nameservers"
parameter. This means that instances on a subnet using SLAAC does not
learn any DNS servers, and thus cannot resolve any hostnames after
being provisioned. That is likely to break lots of things, such as
further provisioning of applications to the instance.
The RDNSS option is documented in RFC 6106. It can be configured in
radvd.conf using the following syntax:
interface qr-foo {
RDNSS server1 [server2 ...] {
# this is optional, but prevents problems noted in the second bullet of
# https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-02#appendix-B
AdvRDNSSLifetime infinity;
};
};
Observed on OpenStack Kilo.
Note: It might be that using DHCPv6 in some capacity would work around
this issue. I have not yet tested this, though.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1495465/+subscriptions
Follow ups