# Frequent failures in name resolution after ISP introduced v6

## chaoscommander

A short time ago my ISP switched my cable subscription from IPv4 to IPv6 (dual stack). Since then, ONLY my Gentoo box is experiencing very frequent (every few minutes) failures in name resolution. When I check resolv.conf at the time of occurrence, it's empty. After I do a dhcpcd -n, it refills with my router IP and name resolution immediately works again. I'm using SLAAC, because with DHCPv6 enabled on my router, my Android phone is unable to obtain an IP address at all. During the DNS failure I still have full connectivity, just not using domain names.

I tried:

-setting a static DNS through /etc/conf.d/net

-setting a static DNS through /etc/dhcpcd.conf,

the former resulting in absolutely no name resolution ever, the latter not fixing the problem (but also not making it worse).

Help would be appreciated, more details can be provided if needed.

----------

## miket

The fact that both your Gentoo machine and the phone are having strange (yet distinct) configuration issues makes me think that the setup of your router/gateway/DNS configuration is not quite correct.

For years I used a Cisco gateway/NAT/router/access-point box between my network and cable modem (stock firmware) and a Gentoo machine on the network as the local name server.  Getting IPv6 required tunnelling to Hurricane Electric and so it was clunky and slow.  What happened next: the machine with the Bind server died and the router's wireless signal was increasingly spotty (on those rare times I use 802.11).  My wanting to get things back up quickly took a big change.

Got a TP-Link router, installed OpenWrt on it, set that up as name server.  Wow!  Night and day.  I had thought I ought to be getting native IPv6 on the Cisco box, and now it showed up w/o my having to do anything special.  Hosts get seamless IPv4, IPv6, and DNS configuration.  That WiFi signal is good and strong--nice, since I've been in the middle of a lot of phone setup lately.

That leaves me w/ this advice:  take a good look at your gateway/NAT-router box.  It might stand an upgrade.

----------

## UberLord

Sounds like something is stamping on resolv.conf. dhcpcd will always leave a header.

Try installing openresolv so there is a middle man for resolv.conf.

----------

## chaoscommander

I enlisted a friend's help and he spent hours troubleshooting (I think I owe him a crate of beer or something).

Replacing dhcpcd with dhclient stopped resolv.conf from getting overwritten all the time. The DNS issues were immediately gone. Getting dhclient to give me more than an IPv4 was a different story. As far as he explained it to me, he added the following two lines to /lib/netifrc/net/dhclientv6.sh in the dhclientv6_start function, right before "##Bring up DHCP for this interface":

```

sysctl -w net.ipv6.conf.${IFACE}.addr_gen_mode=3

sysctl -w net.ipv6.conf.${IFACE}.accept_ra=1

```

Now we wait if the next update breaks everything again. He suggested that upstream somehow adapt this solution and that dhclientv6 should be renamed because it a) doesn't have much to do with dhclient and b) upstream, an actual dhclientv6 does exist.

I ask for your understanding that I have little of the same. If you have any questions I will forward them to him.

Also: yes, my wi-fi AP is probably dying of old age and needs to be replaced. A new one is already on my shopping list.

----------

## UberLord

I really don't think dhcpcd is the issue. It doesn't empty resolv.conf unless all DHCP has expired.

I know, I maintain the author of dhcpcd  :Very Happy: 

----------

## chaoscommander

 *UberLord wrote:*   

> I really don't think dhcpcd is the issue. It doesn't empty resolv.conf unless all DHCP has expired.
> 
> I know, I maintain the author of dhcpcd 

 

We really couldn't figure out the reason and switched dhcp clients out of desperation, and it worked... which could be a coincidence, of course.. or rather, some weird interaction between dhcpcd and an unknown misconfigured part of my system.

----------

## mike155

We had something similar in the German forums. It turned out that dhcpcd was started twice during system boot: https://forums.gentoo.org/viewtopic-t-1116676.html

----------

## UberLord

Yeah that would do it.

Some people like a dhcpcd per interface.

This is why we have resovlconf - to act as the in-between for competing daemons over a single file.

I think I recomended installing it a few posts above  :Wink: 

dhclient on many interfaces behaves the same way btw.

----------

## nagua

Hey everyone, the troubleshooting friend here.

There was no system wide dhcpcd installed, however there was a dhcpcd per interface, but only one interface was active.

So there should only be one dhcpcd. Also looking with 

```
ps aux | grep dhcpcd
```

 ther was only the master process

and a wlp3s0 slave active.

However the router can be configured to do stateless (SLAAC) and stateful (DHCPv6) IP configuration.

Currently the stateless mode is active, but when I started  *Quote:*   

> dhclient -6

  the router responded

to DHCPv6 requests with a IP address nonetheless. So to my limited IPv6 knowledge, it seems that the router

is not really conforming to the standard here. But who knows  :Wink: 

When using 

```
dhcpcd
```

 and running 

```
while true; do cat /etc/resolv.conf; sleep 1; done
```

 one could

see that the resolv.conf was sometimes empty, sometimes normal and sometime all entries were present two times.

It could be observed, that the net.wlp3s0 service would enter a fault state sometimes with a ntp service crashing, because

it was no longer able to bind interfaces. So perhaps this lead to openrc restarting the service and dhcpcd was present two times?

But after switching to dhclient the system was much more stable. I'm not sure if ntp is still crashing, but I think that information

could be provided.

I also installed openresolv to try and solve one IPv4 and another IPv6 dhclient running in parallel. The nameserver entries were

working quite well and it even got a global IPv6 address via DHCPv6, but it did not setup any routes (I assume this is due to the

SLAAC configuration in the router instead of the DHCPv6 one). So I found out that the kernel can handle the SLAAC router announcement

itself and enabled that. After that the interface got two global IPv6 addresses however (one from the kernel and one from dhclient -6).

So I disabled the IPv6 dhclient as the IPv4 nameserver can also resolve IPv6 addresses.

And that is pretty much the current status. The system is using the DNS server it got via the dhclient's DHCP response, executes a

dhclient hook copied from debian to inform openresolv about the nameserver. The kernel is being configured to setup a link-local

address (addr_gen_mode = 3) and accept router announcements to configure the global IPv6 address and needed routes (accept_ra = 1).

I hope that some of this post makes sense to you. I don't really know how dhcpcd works internally, or if you now have an idea what

went wrong here, but perhaps you have a pointer how to fix that.

Cheers,

nagua

----------

## chaoscommander

Supplemental: There are no more ntpd crashes in my log.

----------

## UberLord

 *nagua wrote:*   

> When using 
> 
> ```
> dhcpcd
> ```
> ...

 

Let us look at the dhcpcd source for this:

https://roy.marples.name/cgit/dhcpcd.git/tree/hooks/20-resolv.conf

Without resolvconf, dhpcd maintains DNS information per interface per protocol.

/etc/resolv.conf is never deleted. Instead a temporary file is built up from our interface definitions which always contains a header - this is the default:

```
# Generated by dhcpcd from eth0.dhcp
```

Then if this file is different from /etc/resolv.conf then it's copied across.

openresolv (resolvconf) works the same way - it always puts a header in. I know, I wrote this as well.

So if the file is, as you say, empty then something else must be emptying it.

----------

