dhcp6c inserts link-local entries in resolv.conf without interface scope

[JS Legare]

link local addresses are submitted to /etc/wide-dhcpv6/dhcp6c-script via the $new_domain_name_servers environment variable, but there is no way to determine their scope. the end result is a nameserver entry in /etc/resolv.conf which causes libc's resolver to fail.

After a couple minutes after the network is brought up, I end up with the following in /etc/resolv.conf. After that, libc's resolver fails:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver fe80::beef
nameserver 127.0.1.1
search base

The link local name servers should be suffixed with the scope, e.g. "%eth0". From the provided /etc/wide-dhcpv6/dhcp6c-script, there is no way to accurately determine the scope. This information is not passed to the script by dhcp6c. I would suggest either making the information available via another environment variable, e.g. $interface, or have the dns server entries in $new_domain_name_servers already suffixed.

My home network is on ipv4+ipv6, behind an openwrt router. OpenWrt's default ipv6 settings is to advertise its link local address as the DNS server to hosts on its LAN. It advertises this address both in router advertisements (which are picked up by NetworkManager, it seems) and in its dhcpv6 replies. The dhcp6c daemon (started via /etc/init.d/wide-dhcpv6-client) runs simultaneously with NetworkManager's dnsmasq local resolver on my system. I'm not sure resolv.conf should even be populated by dhcp6c in this scenario -- adding the ipv6 address it gets from the dhcpv6 reply bypasses NetworkManager's 127.0.1.1 resolver. It seems better to leave DNS go through NetworkManager's dnsmasq regardless.

Package wide-dhcpv6-client
Architecture: amd64
Version: 20080615-12
Source: wide-dhcpv6

Ubuntu release:
Description: Ubuntu 14.04.5 LTS
Release: 14.04

I'm attaching my workaround script, which adds the check for link-local addresses. It suffixes them with the first interface from "$INTERFACES". This is a bandaid, until the correct interface can be selected via environment variables. The check is similar to the one done in /etc/dhcp/dhclient-enter-hooks.d/resolvconf (from pkg resolvconf).

Other bug: It also adds a check to avoid duplication of "search X" lines. In cases where /etc/resolv.conf is _not_ a symlink, without that check the file /etc/resolv.conf would grow by one line every time the timer fired.

[JS Legare (jslegare+ubuntu)]

Now that I think of it, looking at the "old" contents of /etc/resolv.conf to see if a line is already there before adding it makes less sense in a resolvconf setting. /etc/resolv.conf is a result combined from various files under /var/run/resolvconf/interface/*. A line in /etc/resolv.conf could come from dhcp6c infor or a different daemon's info.

Perhaps /etc/resolv.conf shouldn't be touched at all if resolvconf isn't running. Might be safe to assume a static config in this case.

[JS Legare (jslegare+ubuntu)]

Attaching patch which plumbs down interface name (of dhcpv6 reply) to dhcp6c-script in environment variable "ifname". The script needs to add the %<if> suffix, where appropriate.

[JS Legare (jslegare+ubuntu)]

workaround script patch to suffix link-local ipv6 addresses.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "pass ifp->ifname down to dhcp6-script" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]