Não é possível resolver domínios em todos os programas, exceto o ping

1

Eu tenho um servidor para uso de HPC e é RedHat. Parece ter um bug estranho. Eu tentei:

$ curl https://www.aliyun.com/ -vv
Couldn't resolve host 'www.aliyun.com'

Eu também tentei isso:

  • wget https://www.aliyun.com/
  • git clone https://github.com/my_username/my_repo
  • telnet www.aliyun.com 80
  • nc www.aliyun.com 80 , etc ...

Todos eles apresentam um erro semelhante getaddrinfo: Name or service not known. . Se eu usar o endereço IP diretamente, tudo está OK. (Exemplo: wget https://140.205.34.3/ --no-check-certificate ) No entanto, posso com sucesso ping www.aliyun.com .

Eu tentei curl http://localhost/ e funciona bem (localhost é um domínio especificado em /etc/hosts ).

Quem é provavelmente o culpado? Você tem alguma experiência semelhante e oferece alguma ajuda?

/etc/resolv.conf anexado aqui:

nameserver 11.11.4.1
nameserver 202.114.0.242
nameserver 8.8.8.8
nameserver 202.112.20.131

uname -a result:

Linux node111 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

lsb_release -a result:

LSB Version:    :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 6.2 (Santiago)
Release:    6.2
Codename:   Santiago

ip -a result: (InfiniBand ativado)

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:e0:81:e1:15:8d brd ff:ff:ff:ff:ff:ff
    inet 11.11.0.111/16 brd 11.11.255.255 scope global eth0
    inet6 fe80::2e0:81ff:fee1:158d/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:e0:81:e1:15:8e brd ff:ff:ff:ff:ff:ff
4: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP qlen 256
    link/infiniband 80:00:00:48:fe:80:00:00:00:00:00:00:46:d2:c9:20:00:00:38:b1 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
    inet 10.10.0.111/16 brd 10.10.255.255 scope global ib0
    inet6 fe80::46d2:c920:0:38b1/64 scope link 
       valid_lft forever preferred_lft forever
5: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 52:54:00:7f:dc:4b brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 500
    link/ether 52:54:00:7f:dc:4b brd ff:ff:ff:ff:ff:ff

NOTA: não tenho privilégios de root na máquina.

Conteúdo de /etc/nsswitch.conf :

#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
#   nisplus         Use NIS+ (NIS version 3)
#   nis         Use NIS (NIS version 2), also called YP
#   dns         Use DNS (Domain Name Service)
#   files           Use the local files
#   db          Use the local database (.db) files
#   compat          Use NIS on compat mode
#   hesiod          Use Hesiod for user lookups
#   [NOTFOUND=return]   Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:     files ldap
shadow:     files ldap
group:      files ldap

#hosts:     db files nisplus nis dns
hosts:      files dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files     

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files

netgroup:   files ldap

publickey:  nisplus

automount:  files ldap
aliases:    files nisplus

EDIT # 1

$ getent hosts www.microsoft.com
218.58.101.49 e13678.ca.s.tl88.net www.microsoft.com www.microsoft.com-c-3.edgekey.net www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net

$ getent hosts www.aliyun.com
2400:3200:1300::3e v6wagbridge.aliyun.com.gds.alibabadns.com www.aliyun.com www-jp-de-intl-adns.aliyun.com www-jp-de-intl-adns.aliyun.com.gds.alibabadns.com v6wagbridge.aliyun.com

EDIT # 2

getent hosts www.aliyun.com funciona muito bem, mas getaddrinfo relatórios name or service not known . (Testado em este simples programa em C )

EDIT # 3

Eu tentei dig e parece que o servidor DNS 11.11.4.1 não está funcionando para a Internet global. Aqui está o que eu encontrei.

$ dig @11.11.4.1 www.aliyun.com

; <<>> DiG 9.7.3-P3-RedHat-9.7.3-8.P3.el6 <<>> @11.11.4.1 www.aliyun.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37272
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.aliyun.com.            IN  A

;; Query time: 1 msec
;; SERVER: 11.11.4.1#53(11.11.4.1)
;; WHEN: Mon Aug 20 14:48:37 2018
;; MSG SIZE  rcvd: 32

$ dig @1.1.1.1 www.aliyun.com

; <<>> DiG 9.7.3-P3-RedHat-9.7.3-8.P3.el6 <<>> @1.1.1.1 www.aliyun.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64269
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.aliyun.com.            IN  A

;; ANSWER SECTION:
www.aliyun.com.     113 IN  CNAME   www-jp-de-intl-adns.aliyun.com.
www-jp-de-intl-adns.aliyun.com. 293 IN  CNAME   www-jp-de-intl-adns.aliyun.com.gds.alibabadns.com.
www-jp-de-intl-adns.aliyun.com.gds.alibabadns.com. 113 IN CNAME xjp.wagbridge.aliyun.aliyun.com.
xjp.wagbridge.aliyun.aliyun.com. 89 IN  CNAME   xjp-adns.aliyun.com.
xjp-adns.aliyun.com.    89  IN  CNAME   xjp-adns.aliyun.com.gds.alibabadns.com.
xjp-adns.aliyun.com.gds.alibabadns.com. 89 IN A 47.88.251.164

;; Query time: 223 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Aug 20 14:48:39 2018
;; MSG SIZE  rcvd: 256
    
por Recolic Keghart 18.08.2018 / 15:44

1 resposta

0

Isso confunde muitas pessoas, mas o comando ping tem suas próprias integrações com o arquivo /etc/resolv.conf , enquanto as outras ferramentas mencionadas utilizam o recurso do Name Server Switch. Você pode ver isso se você executar um strace <cmd> e analisar a saída das bibliotecas com as quais os comandos estão interagindo.

Por exemplo, aqui está o ping :

$ strace ping -c 3 www.aliyun.com |& grep -E "ns|resolv"
open("/lib64/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3

E aqui está o curl :

$ strace curl -v www.aliyun.com |& grep -E "ns|resolv"
open("/lib64/libnss3.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnssutil3.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnspr4.so", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("47.88.251.161")}, 16) = -1 EINPROGRESS (Operation now in progress)
getpeername(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("47.88.251.161")}, [16]) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(55876), sin_addr=inet_addr("10.0.2.15")}, [16]) = 0

Você provavelmente está se perguntando, mas espere, ambos estão exibindo uma chamada para libresolv , então qual é o problema? O motivo pelo qual o curl até sabe chamar a libresolv é porque foi direcionado para isso. Por quê? Por causa desse arquivo:

$ grep host /etc/nsswitch.conf
#hosts:     db files nisplus nis dns
hosts:      files dns myhostname 

A referência hosts: neste arquivo informa às ferramentas que fazem chamadas para o NSS (Name Server Switch) que devem consultar com files primeiro, depois chamar dns second.

A referência files significa usar o arquivo /etc/hosts , a opção dns significa consultar /etc/resolv.conf para um servidor de nomes DNS e procurar o nome do host lá.

Seu problema

Portanto, é provável que seu problema, devido ao fato de seu arquivo /etc/nsswitch.conf não ter a entrada dns , como mostrado acima.

Quais executáveis usam o NSS?

Você pode examinar os executáveis usando readelf , que mostra quais bibliotecas compartilhadas um executável requer.

$ type -f curl
curl is /bin/curl

$ readelf -d /bin/curl | grep -i shared
 0x0000000000000001 (NEEDED)             Shared library: [libcurl.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libssl3.so]
 0x0000000000000001 (NEEDED)             Shared library: [libsmime3.so]
 0x0000000000000001 (NEEDED)             Shared library: [libnss3.so]
 0x0000000000000001 (NEEDED)             Shared library: [libnssutil3.so]
 0x0000000000000001 (NEEDED)             Shared library: [libplds4.so]
 0x0000000000000001 (NEEDED)             Shared library: [libplc4.so]
 0x0000000000000001 (NEEDED)             Shared library: [libnspr4.so]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

$ type -f ping
ping is /bin/ping

$ readelf -d /bin/ping | grep -i shared
 0x0000000000000001 (NEEDED)             Shared library: [libcap.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libidn.so.11]
 0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.10]
 0x0000000000000001 (NEEDED)             Shared library: [libresolv.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

Um método semelhante pode ser usado com ldd :

$ ldd /bin/ping|grep -E "ns|resolv"
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fd144d40000)

$ ldd /bin/curl|grep -E "ns|resolv"
    libnss3.so => /lib64/libnss3.so (0x00007f9795413000)
    libnssutil3.so => /lib64/libnssutil3.so (0x00007f97951e4000)
    libnspr4.so => /lib64/libnspr4.so (0x00007f9794b9d000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f9792067000)

O DNS parece estar funcionando

Se você conseguir executar esses comandos e eles funcionarem:

$ getent hosts www.google.com
216.58.193.164  www.google.com

$ getent hosts www.aliyun.com
47.88.198.17    xjp-adns.aliyun.com.gds.alibabadns.com www.aliyun.com

Em seguida, tente usar opennssl para ver se você pode se conectar a esses serviços:

$ true | openssl s_client -connect www.aliyun.com:443
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization Validation CA - SHA256 - G2
depth=0 C = CN, ST = ZheJiang, L = HangZhou, O = "Alibaba (China) Technology Co., Ltd.", CN = *.aliyun.com
 0 s:/C=CN/ST=ZheJiang/L=HangZhou/O=Alibaba (China) Technology Co., Ltd./CN=*.aliyun.com
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
subject=/C=CN/ST=ZheJiang/L=HangZhou/O=Alibaba (China) Technology Co., Ltd./CN=*.aliyun.com
issuer=/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA - SHA256 - G2

Referências

por 18.08.2018 / 21:50