Problems with mix of IPv4 and IPv6 entries in /etc/resolv.conf causing occationally failed resolving

[Tobias Brox]

This bug is reproducable on precise and trusty, but not on xenial, neither on EL6/EL7.

Steps to reproduce:

1) Ensure /etc/resolv.conf contains both IPv6 and IPv4 entries, starting with an IPv6 entry:

    # echo -e "nameserver 2001:4860:4860::8888\nnameserver 2001:4860:4860::8844\nnameserver 8.8.8.8\nnameserver 4.4.4.4\n" > /etc/resolv.conf

2) Block the traffic from the (first) name server

    # ip6tables -A INPUT -j DROP -p udp --sport 53

3) Fire up tcpdump on port 53 (preferably in a different window)

    # tcpdump -n port 53 &

4) Try to resolve some DNS entry

    # ping google.com

Expected behaviour: the resolver will try all name servers in /etc/resolv.conf and will succeed when trying the IPv4 servers.

Observed behaviour: the resolver will only try the IPv6 servers.

5) Change the ordering in the resolv.conf file like this:

    # echo -e "nameserver 2001:4860:4860::8888\nnameserver 8.8.8.8\nnameserver 2001:4860:4860::8844\nnameserver 4.4.4.4\n" > /etc/resolv.conf

6) Retry step #4

Notice that now the resolver will only try the first entry in /etc/resolv.conf and not the other one.

Our setup is like #5, and one single dropped package would cause resolving to fail.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Simon Déziel (sdeziel)]

The bug was reported to affect releases prior to Xenial (16.04) only. Both Precise (12.04) and Trusty (14.04) are out of standard support now so I'll mark the bug as fix released. Please open a new bug if you still have issues on a supported Ubuntu release, thank you!

Update: Trusty still receives ESM support so maybe this will be SRU'ed