You are not logged in.
You cannot access because of the great firewall or for unknown reasons?
Can you access 1.1.1.1?
Anyway, dig doesn't seem to have problems w/ vc.
Does this work ("gcc -o test_getaddrinfo test_getaddrinfo.c")
#include <stdio.h>
#include <stdlib.h>
#include <netdb.h>
#include <netinet/in.h>
#include <sys/socket.h>
#ifndef NI_MAXHOST
#define NI_MAXHOST 1025
#endif
int main(void)
{
struct addrinfo *result;
struct addrinfo *res;
freeaddrinfo(result);
int error;
/* resolve the domain name into a list of addresses */
error = getaddrinfo("mirrors.163.com", NULL, NULL, &result);
if (error != 0)
{
fprintf(stderr, "error in getaddrinfo: %s\n", gai_strerror(error));
return EXIT_FAILURE;
}
/* loop over all returned results and do inverse lookup */
for (res = result; res != NULL; res = res->ai_next)
{
char hostname[NI_MAXHOST] = "";
error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, NI_MAXHOST, NULL, 0, 0);
if (error != 0)
{
fprintf(stderr, "error in getnameinfo: %s\n", gai_strerror(error));
continue;
}
if (*hostname != '\0')
printf("hostname: %s\n", hostname);
}
freeaddrinfo(result);
return EXIT_SUCCESS;
}
Offline
You cannot access because of the great firewall or for unknown reasons?
Can you access 1.1.1.1?Anyway, dig doesn't seem to have problems w/ vc.
Does this work ("gcc -o test_getaddrinfo test_getaddrinfo.c")
#include <stdio.h> #include <stdlib.h> #include <netdb.h> #include <netinet/in.h> #include <sys/socket.h> #ifndef NI_MAXHOST #define NI_MAXHOST 1025 #endif int main(void) { struct addrinfo *result; struct addrinfo *res; freeaddrinfo(result); int error; /* resolve the domain name into a list of addresses */ error = getaddrinfo("mirrors.163.com", NULL, NULL, &result); if (error != 0) { fprintf(stderr, "error in getaddrinfo: %s\n", gai_strerror(error)); return EXIT_FAILURE; } /* loop over all returned results and do inverse lookup */ for (res = result; res != NULL; res = res->ai_next) { char hostname[NI_MAXHOST] = ""; error = getnameinfo(res->ai_addr, res->ai_addrlen, hostname, NI_MAXHOST, NULL, 0, 0); if (error != 0) { fprintf(stderr, "error in getnameinfo: %s\n", gai_strerror(error)); continue; } if (*hostname != '\0') printf("hostname: %s\n", hostname); } freeaddrinfo(result); return EXIT_SUCCESS; }
1.1.1.1 and 8.8.8.8 are both accessible now.
$ dig +vc @1.1.1.1 mirrors.163.com 1
; <<>> DiG 9.13.7 <<>> +vc @1.1.1.1 mirrors.163.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33697
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;mirrors.163.com. IN A
;; ANSWER SECTION:
mirrors.163.com. 725 IN A 59.111.0.251
;; Query time: 207 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Mar 25 22:50:48 CST 2019
;; MSG SIZE rcvd: 60
$ dig +vc @8.8.8.8 mirrors.163.com
; <<>> DiG 9.13.7 <<>> +vc @8.8.8.8 mirrors.163.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19952
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mirrors.163.com. IN A
;; ANSWER SECTION:
mirrors.163.com. 2438 IN A 59.111.0.251
;; Query time: 63 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Mar 25 22:50:56 CST 2019
;; MSG SIZE rcvd: 60
And test_getaddrinfo shows:
error in getaddrinfo: Temporary failure in name resolution
Offline
Try to use 1.1.1.1 or 8.8.8.8 in your resolv.conf (the problem seems limited to glibc getaddrinfo, the question is whether in connection w/ the particular DNS server or if this is a general bug)
Offline
Try to use 1.1.1.1 or 8.8.8.8 in your resolv.conf (the problem seems limited to glibc getaddrinfo, the question is whether in connection w/ the particular DNS server or if this is a general bug)
I set both in resolv.conf, 1.1.1.1 first, with use-vc, and pacman just worked.
Offline
Well, seems the specific DNS server doesn't react all too well to certain™ tcp requests - some consumer router?
I'd wireshark the behavior once against the getaddrinfo and then against dig +vc to see what happens (and if eg. dig silently falls back to udp for detecting some brokenenss, though I'd doubt that)
Offline
Well, seems the specific DNS server doesn't react all too well to certain™ tcp requests - some consumer router?
I'd wireshark the behavior once against the getaddrinfo and then against dig +vc to see what happens (and if eg. dig silently falls back to udp for detecting some brokenenss, though I'd doubt that)
Just did the capture, with the source you gave, ping, dig.
I think I saw two things.
1. There was response to each request. But seems like client did not accept them.
2. Only dig request had an additional record. But I could not see difference on DNS response.
I posted the pcap here: https://drive.google.com/file/d/18PH9GR … sp=sharing
Offline
Try
dig +vc +nocookie +nodnssec @192.168.3.1 mirrors.163.com
Offline
Try
dig +vc +nocookie +nodnssec @192.168.3.1 mirrors.163.com
; <<>> DiG 9.13.7 <<>> +vc +nocookie +nodnssec @192.168.3.1 mirrors.163.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55194
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mirrors.163.com. IN A
;; ANSWER SECTION:
mirrors.163.com. 3473 IN A 59.111.0.251
;; Query time: 4 msec
;; SERVER: 192.168.3.1#53(192.168.3.1)
;; WHEN: Tue Mar 26 22:14:44 CST 2019
;; MSG SIZE rcvd: 60
wireshark dump: https://drive.google.com/file/d/1waNtdC … sp=sharing
Offline
Try to add
options edns0
to /etc/resolv.conf - it would seem the DNS server hard-relies on that.
Offline
Try to add
options edns0
to /etc/resolv.conf - it would seem the DNS server hard-relies on that.
Sorry, missed the reply.
The option does not help.
Offline
Does the pcap differ in any kind from "dig +vc +nocookie +nodnssec" with this option in place?
Offline
Does the pcap differ in any kind from "dig +vc +nocookie +nodnssec" with this option in place?
From what I can see, without edns0, the answer time to live is shorter as 10. I could not see other differences.
Posted here: https://drive.google.com/file/d/1zKn1i3 … sp=sharing
Offline
All packages look equivalent, same structure - and the respose shows no error and resolves the IP… everytime.
There's "suspiciously" no IPv6 query - do the queries to 1111 or 8888 (w/ use-vc and edns0) differ?
Offline
All packages look equivalent, same structure - and the respose shows no error and resolves the IP… everytime.
There's "suspiciously" no IPv6 query - do the queries to 1111 or 8888 (w/ use-vc and edns0) differ?
I was wondering that as well. But I thought the client would just pick what responded, which seemed like not.
I did a pcap on same tool (ping), different DNS server. Finally I saw differences.
- My router DNS, response only to A request. And ping makes both A and AAAA. Ping ignores the A response.
- 1.1.1.1, response to both A and AAAA. Ping just works.
So, if this is a problem, then the problem is that why tools ignore A response when they make both A and AAAA queries.
Pcap posted here: https://drive.google.com/file/d/1doL4In … sp=sharing
Offline
Add "option single-request" and then "option single-request-reopen"
I assume w/ tcp, glibc will insist on a complete answer and timeout whereas with the less reliable UDP it will just use what it gets…
You could also just disable IPv6 altogether?
Offline
Add "option single-request" and then "option single-request-reopen"
I assume w/ tcp, glibc will insist on a complete answer and timeout whereas with the less reliable UDP it will just use what it gets…
You could also just disable IPv6 altogether?
Bad news. The two options does not help. Disable IPv6 does not help, either.
Commands to disable IPv6:
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
Offline
Ancestoral Clan https://cirrus.freevar.com/mclean.html
Offline
No luck.
Offline
Does glibc still ask for AAAA records when adding those options/disabling IPv6?
Offline
Does glibc still ask for AAAA records when adding those options/disabling IPv6?
Yes. With all 3 options in /etc/resolv.conf, and disabling IPv6.
Offline
What I got so far:
- Since client side makes A and AAAA queries, server side must reply correspondingly. In IPv4 environment, a SOA for the AAAA.
- Turning off IPv6 in client side does not help, because querying both is hardcoded in NSS DNS module, which is called by getaddrinfo.
Checking out the git logs, no clue on why it is hardcoded.
Offline
I get this problem when 1.1.1.1 is in resolv.conf but not when using 8.8.8.8
Offline