Diferente comportamento de pesquisa reversa 'ping6' usando servidores dv ipv4 vs ipv6 em /etc/resolv.conf

5

Espero que alguém possa ajudar a esclarecer o comportamento diferente que ping6 está demonstrando em uma caixa GNU / Linux.

A máquina é um host Linode que recebeu um endereço IPv4 e IPv6. Está sendo executado em uma configuração de pilha dupla. O pessoal do Linode forneceu dois resolvedores IPv4 e dois resolvedores IPv6. (para esta pergunta eu vou usar apenas um de cada tipo).

Quando configuro meu arquivo /etc/resolv.conf para usar um resolvedor IPv4;

# /etc/resolv.conf
nameserver 72.14.179.5

ping6 executa uma pesquisa inversa para cada resposta de eco e exibe o endereço de acordo. (Isso é o que eu espero.)

$ ping6 -c 6 google.com
PING google.com(dfw06s33-in-x05.1e100.net) 56 data bytes
64 bytes from dfw06s33-in-x05.1e100.net: icmp_seq=1 ttl=49 time=34.7 ms
64 bytes from dfw06s33-in-x05.1e100.net: icmp_seq=2 ttl=49 time=34.7 ms
64 bytes from dfw06s33-in-x05.1e100.net: icmp_seq=3 ttl=49 time=34.7 ms
64 bytes from dfw06s33-in-x05.1e100.net: icmp_seq=4 ttl=49 time=34.7 ms
64 bytes from dfw06s33-in-x05.1e100.net: icmp_seq=5 ttl=49 time=34.7 ms
64 bytes from dfw06s33-in-x05.1e100.net: icmp_seq=6 ttl=49 time=34.7 ms

Se eu executar tcpdump , enquanto executo o comando ping6 , posso ver a pesquisa direta 1 e 6 pesquisas inversas conforme o esperado.

$ sudo tcpdump -n -i eth0 udp port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:00:23.128883 IP 23.239.30.203.37353 > 72.14.179.5.53: 18114+ AAAA? google.com. (28)
21:00:23.129194 IP 72.14.179.5.53 > 23.239.30.203.37353: 18114 1/0/0 AAAA 2607:f8b0:4000:805::1003 (56)
21:00:23.129380 IP 23.239.30.203.58841 > 72.14.179.5.53: 32482+ PTR? 3.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.5.0.8.0.0.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. (90)
21:00:23.129661 IP 72.14.179.5.53 > 23.239.30.203.58841: 32482 1/0/0 PTR dfw06s33-in-x03.1e100.net. (129)
21:00:23.164677 IP 23.239.30.203.47867 > 72.14.179.5.53: 30527+ PTR? 3.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.5.0.8.0.0.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. (90)
21:00:23.165086 IP 72.14.179.5.53 > 23.239.30.203.47867: 30527 1/0/0 PTR dfw06s33-in-x03.1e100.net. (129)
21:00:24.166410 IP 23.239.30.203.55723 > 72.14.179.5.53: 37565+ PTR? 3.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.5.0.8.0.0.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. (90)
21:00:24.167221 IP 72.14.179.5.53 > 23.239.30.203.55723: 37565 1/0/0 PTR dfw06s33-in-x03.1e100.net. (129)
21:00:25.166735 IP 23.239.30.203.52095 > 72.14.179.5.53: 15353+ PTR? 3.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.5.0.8.0.0.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. (90)
21:00:25.167138 IP 72.14.179.5.53 > 23.239.30.203.52095: 15353 1/0/0 PTR dfw06s33-in-x03.1e100.net. (129)
21:00:26.167883 IP 23.239.30.203.60999 > 72.14.179.5.53: 48567+ PTR? 3.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.5.0.8.0.0.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. (90)
21:00:26.168327 IP 72.14.179.5.53 > 23.239.30.203.60999: 48567 1/0/0 PTR dfw06s33-in-x03.1e100.net. (129)
21:00:27.169385 IP 23.239.30.203.33681 > 72.14.179.5.53: 42354+ PTR? 3.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.5.0.8.0.0.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. (90)
21:00:27.169847 IP 72.14.179.5.53 > 23.239.30.203.33681: 42354 1/0/0 PTR dfw06s33-in-x03.1e100.net. (129)
21:00:28.170818 IP 23.239.30.203.36738 > 72.14.179.5.53: 15194+ PTR? 3.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.5.0.8.0.0.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. (90)
21:00:28.171221 IP 72.14.179.5.53 > 23.239.30.203.36738: 15194 1/0/0 PTR dfw06s33-in-x03.1e100.net. (129)

No entanto , se eu configurar /etc/resolv.conf para usar um resolvedor IPv6;

# /etc/resolv.conf
nameserver 2600:3c00::3

ping6 realiza uma pesquisa inversa para todos os outros pedidos de eco. (Estou confuso)

$ ping6 -c 6 google.com
PING google.com(2607:f8b0:4000:803::1000) 56 data bytes
64 bytes from dfw06s27-in-x00.1e100.net: icmp_seq=1 ttl=49 time=33.1 ms
64 bytes from 2607:f8b0:4000:803::1000: icmp_seq=2 ttl=49 time=33.2 ms
64 bytes from dfw06s27-in-x00.1e100.net: icmp_seq=3 ttl=49 time=33.2 ms
64 bytes from 2607:f8b0:4000:803::1000: icmp_seq=4 ttl=49 time=33.2 ms
64 bytes from dfw06s27-in-x00.1e100.net: icmp_seq=5 ttl=49 time=33.1 ms
64 bytes from 2607:f8b0:4000:803::1000: icmp_seq=6 ttl=49 time=33.2 ms

Confirmo isso observando tcpdump output enquanto executo ping6 . Eu vejo a pesquisa direta, mas apenas 3 pesquisas inversas.

$ sudo tcpdump -n -i eth0 udp port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:10:12.163444 IP6 2600:3c00::f03c:91ff:fe73:ee8f.35982 > 2600:3c00::3.53: 47249+ AAAA? google.com. (28)
21:10:12.164457 IP6 2600:3c00::3.53 > 2600:3c00::f03c:91ff:fe73:ee8f.35982: 47249 1/0/0 AAAA 2607:f8b0:4000:803::1000 (56)
21:10:12.198491 IP6 2600:3c00::f03c:91ff:fe73:ee8f.37631 > 2600:3c00::3.53: 18439+ PTR? 0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.3.0.8.0.0.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. (90)
21:10:12.207233 IP6 2600:3c00::3.53 > 2600:3c00::f03c:91ff:fe73:ee8f.37631: 18439 1/0/0 PTR dfw06s27-in-x00.1e100.net. (129)
21:10:14.201780 IP6 2600:3c00::f03c:91ff:fe73:ee8f.55836 > 2600:3c00::3.53: 9503+ PTR? 0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.3.0.8.0.0.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. (90)
21:10:14.202272 IP6 2600:3c00::3.53 > 2600:3c00::f03c:91ff:fe73:ee8f.55836: 9503 1/0/0 PTR dfw06s27-in-x00.1e100.net. (129)
21:10:16.204599 IP6 2600:3c00::f03c:91ff:fe73:ee8f.46736 > 2600:3c00::3.53: 38520+ PTR? 0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.3.0.8.0.0.0.0.4.0.b.8.f.7.0.6.2.ip6.arpa. (90)
21:10:16.205006 IP6 2600:3c00::3.53 > 2600:3c00::f03c:91ff:fe73:ee8f.46736: 38520 1/0/0 PTR dfw06s27-in-x00.1e100.net. (129)

Qualquer ideia é muito apreciada.

    
por Pablo Maurin 07.07.2014 / 04:21

1 resposta

0

O código do ping e do ping6 usam uma função compartilhada char * pr_addr(void *sa, socklen_t salen) ping.c para formatar hostname (address) substring na saída. pr_addr chama getnameinfo() , que é uma função típica da biblioteca, fornecida pelo SO . Portanto, não há diferença no comportamento de pesquisa

    
por 20.02.2017 / 17:41

Tags