0

I just installed CentOs 6.3 on a server to be installed in a data center, but cannot get name resolution / curl to work.

I know this is because of it trying to use ipv6, since ping google.com works, curl -4 google.com works, but not curl google.com.

I removed the ipv6 adress from the interface and it does not change anything.

This is very problematic since most system tools like yum fail at name resolution currently. Browsers like Firefox work because they might be using another tool for name resolution than the one use by curl.

I managed to fix this on workstations by completely disabling ipv6 following tutorials like this one / hardcoding name resolution in /etc/hosts. But since I am here configuring a server which will be later installed in a remote data center, I would like not to mess up, understand what is going on and fix it properly. Besides, I will face the same issue with more servers to come so I would really appreciate your help in understanding this problem and how to solve it.

I would be happy to provide more information if needed to help understand what is going on.

The current network configuration is a small enterprise network, with a DNS server (let's call it A) configured once a long time ago. dig google.com and dig -4 google.com are both refused by the A DNS. But this is also true for my workstation on which curl is working (and yes they both use the same A DNS server). Indeed this faulty server and my workstation have multiple nameservers in /etc/resolv.conf, and the second one is working fine for both of them, so if I remove A from my resolv.conf everything works fine!

Regards,

Olivier

3
  • 1
    Can you provide the output from dig -4 google.com and dig -6 google.com? Which name servers are you using to resolve requests from this system? Aug 31, 2012 at 15:11
  • 3
    by thinking out loud why dig was failing in both cases even for a machine not affected by this problem I found the problem: my first nameserver is bullshit, thanks!
    – jolivier
    Aug 31, 2012 at 15:30
  • 2
    Great! Feel free to put an answer on your own question (there's an enforced delay, later today it should let you), as reference for people who have the same issue in the future. Aug 31, 2012 at 15:32

2 Answers 2

1

I solved this problem with the following diagnostic process, which can be applied when dealing with name resolution problems and ipv6

  • Test dig google.com and dig -4 google.com, on a machine having this problem and another one on the same network not having this problem.
  • If the four command (two by machine) fail, this mean that the first nameserver in their /etc/resolv.conf is not configured for ipv6. Remove it and retest.

One cal also use digg @nameserver google.com to test the other eventual nameservers in /etc/resolv.conf without changing this file.

1

I had to troubleshoot this, and it seems that before Centos version 6.x (so for example 5.8 and older), the default behaviour for glibc DNS resolver was like this. Client was asking the DNS server for IPv6 address (AAAA record) and DNS server only had IPv4 record it said - I don't have it (NX). Then client re-requested this 5 more times getting the same answer, until then saying - hey server, give me the IPv4 address. And then server provided the A record, and client was satisfied. In my network this whole dance was done in under 300 miliseconds, so almost not noticable for end users.

This changed in Centos 6.x, where the two queries were done in parallel - IPv6 and IPv4 record queried at the same time. If your DNS server responded with NX (I don't have it) for IPv6 address, client completely ignored the valid response with A (IPv4) address, because it came that little fraction of second later. So it queried the DNS server again (doing both IPv6 and IPv4 queries) and ended up in the same situation. So it started doing these queries by adding DNS search suffices to the search, after finally giving up.

This was fixed in Centos 6.7, where client waits for that second IPv4 response and happily accepts it, which takes about 15 miliseconds in my network. Probably this is the relevant Redhat ticket for it - https://bugzilla.redhat.com/show_bug.cgi?id=845218 (Do not fail if one of the two responses to AF_UNSPEC fails):

rpm -q --changelog glibc | sed -n '0,/2.12-1.132/p' | grep AF_UNSPEC
- Do not fail if one of the two responses to AF_UNSPEC fails (#845218).

Now, this ticket is restricted, so here is probable upstream patch: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=16b293a7a6f65d8ff348a603d19e8fd4372fa3a9

For details, here is the list of servers affected:

  • Centos 5.8 - working (glibc-2.5-81). Is doing 6 IPv6 queries, and it falls back to IPv4 which eventually succeeds
  • Centos 6.0 - not working (glibc glibc-2.12-1.7.el6.x86_64)
  • Centos 6.1 to 6.4 - not working
  • Centos 6.5 - not working (version glibc-2.12-1.132.el6.x86_64)
  • Centos 6.6 - fixed (version glibc-2.12-1.149.el6.x86_64)
  • Centos 6.7 - fixed (version glibc-2.12-1.166.el6.x86_64)
  • Centos 7.0 - not working (glibc-2.17-55.el7) - does both IPv4 and IPv6 queries, valid IPv4 response comes first, waits for IPv6 response of NX and fails name resolution
  • Centos 7.1 - fixed (glibc-2.17-78.el7) - does both IPv4 and IPv6 queries, valid IPv4 response comes first, IPv6 response of NX comes then, and name resolution succeeds to IPv4

SUSE Linux for comparison:

  • SLES 11.3 - working (only doing IPv4 lookup) - (glibc-2.11.3-17.54.1)
  • SLES 12.1 - not working (glibc-2.19-31.9.x86_64)
  • SLES 12.2 - is working (glibc-2.22-49.16.x86_64.rpm). Does IPv4 and IPv6 queries simultaneously, receives IPv6 response first with NX, but waits for following IPv4 and uses that.
  • SLES 12.3 - [to be released on September 2017] (?glibc-2.22-51.6.x86_64.rpm?)

The inet4only option for /etc/resolv.conf was never implemented, https://bugzilla.redhat.com/show_bug.cgi?id=1027452

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .