Problem with IPv6 Name Resolution

We have the following problem after replacing our first openSUSE 13.1 server by openSuse Leap 42.3.

Important to know is that on both systems IPv6 was disabled via yast global network settings.

Sometimes accessing internet resources fail for all kind of resources form different programs. E.g. curl, wget, lynx fail to access ftp or http resources on the internet.

If this happens you can see that the app tries to access the internet resource via its IPv6 address which then fails for obvious reasons. If this happens for one resource it could most often be fixed by running “service nscd restart”. So there seems to be a problem with the resolver using an IPv6 address instead of IPv4.

Any idea how to fix this an what is causing this?
I would assume that libc resolver would only offer IPv4 addresses if IPv6 was disabled.

THX.
goppi

Did you check that IPv6 is really disabled? What

grep . /proc/sys/net/ipv6/conf/*/disable_ipv6

returns?

Besides checking whether IPv6 is disabled,

Is your DNS returning IPv6 query results?
Do you need to clear your name cache (simply restart your nscd service to clear)
Do you have any IPv6 entries in your Hosts file?

TSU

/proc/sys/net/ipv6/conf/all/disable_ipv6:1
/proc/sys/net/ipv6/conf/default/disable_ipv6:1
/proc/sys/net/ipv6/conf/eth0/disable_ipv6:1
/proc/sys/net/ipv6/conf/lo/disable_ipv6:1

Seems to be OK so far.

Yes the DNS server (ISP DNS) also returns IPv6 results. Otherwise the programs would have no clue how to reach those sites via IPv6.
Yes when it once fails clearing the cache by restarting nscd cures the problem for the problematic site.
Following default IPv6 entries are in the hosts file:

# special IPv6 addresses
::1             localhost ipv6-localhost ipv6-loopback

fe00::0         ipv6-localnet

ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts

But just checked Suse 13.1 created the same entries which do not cause these issues with that version.

Your network services have to be consistent.

You need to have all your DNS and DHCP services configured for <only> IPv4 or IPv6.
Or, if you wish to support both, then enable both.

Why would you want to disable IPv6, anyway?

TSU

I used to see that (even on 13.1) before my ISP provided IPv6.

It only happened rarely.

As far as I know, the application finds an IPv6 address. When it tries to use it, it gets a “no route to destination” error. So then it tries IPv4. If the IPv4 attempt to connect fails, then some applications will report it as an IPv6 error.

It the problem is infrequent, I suggest you ignore it.

I have no influence how ISP DNS servers are configured. Having
servers with mixed IPv4/v6 zones was never a problem in the past,
neither for Suse nor for Windows.

Is there any way to display the resolver cache similar to Windows. This way
it would be possible to check if the IPv4 entry for failing site in question is simply
missing or if both are there and are maybe prioritized wrong.

Something must have changed between Suse 13.1 and Leap 42.3 on the resolver side.
I would assume a resolver within a system where IPv6 is disabled should not deliver IPv6
addresses to an application in the first place. We have about 60 servers with Suse 13.1
working flawlessly and the first Leap 42.3 server shows these strange problems.

Ipv6 is on our roadmap for 2019. There are to many systems here with potential side
effects. This has to be tested excessively and planned carefully.

You are right that this happened rarely. However here on this one server it happened 4 times within the last 2 days and then it fails constantly for that side until the TTL of DNS record times out.

Ignoring this failure here is simply impossible due to its consequences, and again Suse 13.1 never failed in this way here.

You don’t have to use your ISP’s DNS unless they’re blocking queries to others (hardly ever done).

This is the list of Tier 2 DNS OpenNIC providers which can provide services to anybody (Tier 1 are generally reserved only for LAN DNS, not individual clients). Pick one of the Ipv4 only DNS close to you, if it’s congested try another.

https://servers.opennicproject.org/

TSU

Ok that would be an option. However it may be even better then to setup a local bind DNS cache which only handles IPv4.
Following should do the trick:

NAMED_ARGS=-4
filter-aaaa-on-v4 yes;

What I will try before is setting

precedence ::ffff:0:0/96  100

in “/etc/gai.conf” to prefer IPv4 instead of IPv6 on getaddrinfo calls.
Maybe this will cure the problem.

THX for the hint on IPv4 only DNS server. :good:

goppi-