Làm thế nào có thể tôi có thể thực hiện tra cứu máy chủ nhưng không phải là một cuộn tròn?

Đã có ai thấy điều này trước đó chưa? Lưu ý rằng điều này xảy ra không chỉ với google.com, mà với mọi tên miền tôi thử. Đó là kết nối không dây (WEP), nhưng tôi không chắc nó có liên quan như thế nào:

$ curl -v google.com
# This takes about 60s to return
* getaddrinfo(3) failed for google.com:80
* Couldn't resolve host 'google.com'
* Closing connection #0
curl: (6) Couldn't resolve host 'google.com'

$ wget google.com
--2011-11-28 14:44:08--  http://google.com/
Resolving google.com... failed: Name or service not known.
wget: unable to resolve host address `google.com'

$ ping google.com
PING google.com (209.85.148.147) 56(84) bytes of data.
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=2 ttl=54 time=136 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=3 ttl=54 time=34.0 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=4 ttl=54 time=34.3 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=5 ttl=54 time=42.5 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=6 ttl=54 time=44.7 ms
64 bytes from fra07s07-in-f147.1e100.net (209.85.148.147): icmp_req=7 ttl=54 time=34.5 ms
^C
--- google.com ping statistics ---
8 packets transmitted, 6 received, 25% packet loss, time 7007ms
rtt min/avg/max/mdev = 34.063/54.376/136.026/36.758 ms


$ host google.com
google.com has address 209.85.148.106
google.com has address 209.85.148.147
google.com has address 209.85.148.99
google.com has address 209.85.148.103
google.com has address 209.85.148.104
google.com has address 209.85.148.105
google.com mail is handled by 30 alt2.aspmx.l.google.com.
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.

$ host google.com 192.168.1.201
Using domain server:
Name: 192.168.1.201
Address: 192.168.1.201#53
Aliases: 

google.com has address 209.85.148.103
google.com has address 209.85.148.104
google.com has address 209.85.148.105
google.com has address 209.85.148.106
google.com has address 209.85.148.147
google.com has address 209.85.148.99
google.com mail is handled by 40 alt3.aspmx.l.google.com.
google.com mail is handled by 50 alt4.aspmx.l.google.com.
google.com mail is handled by 10 aspmx.l.google.com.
google.com mail is handled by 20 alt1.aspmx.l.google.com.
google.com mail is handled by 30 alt2.aspmx.l.google.com.

$ cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.1.201

$ cat /etc/hosts
127.0.0.1       localhost
::1             localhost

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG        0 0          0 wlan0
127.0.0.0       127.0.0.1       255.0.0.0       UG        0 0          0 lo
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0

Về cơ bản, bất kỳ ứng dụng nào, bao gồm cả Firefox, không thể hoạt động để tìm kiếm tên. Hơn nữa, nếu tôi lấy wifi ngoại tuyến và cắm cáp ethernet, mọi thứ đều ổn.

Có lẽ bạn có một số quy tắc SELinux (hoặc bảo mật ...) rất kỳ lạ và hạn chế?

Nếu không, hãy thử strace -o /tmp/wtf -fF curl -v google.comvà cố gắng phát hiện từ /tmp/wtftệp đầu ra những gì đang diễn ra.

Sử dụng cái này: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=39343

Tôi tìm thấy một lệnh chính giúp tôi khắc phục sự cố:

[root @ localhost ~] # wget -6 URL không thành công

[root @ localhost ~] # wget -4 URL đã hoạt động

Đó là một cái gì đó để làm với ngăn xếp ipv6 mặc định gây ra vấn đề với một số tiện ích nhất định. Vô hiệu hóa ipv6 để giải quyết.

Kiểm tra của bạn /etc/nsswitch.conf. Nếu hostsdòng nói gì đó như

hosts:      files dns

Tôi cũng bối rối như bạn. Nhưng nếu nó nói một cái gì đó như

hosts:      files

sau đó, thực tế là DNS đang hoạt động (xem đầu ra của hostlệnh) sẽ không giúp curl, đang thực hiện phân giải tên thông qua các thư viện hệ điều hành tiêu chuẩn, được thông báo không sử dụng DNS.

Tôi đã có cùng một vấn đề - máy chủ lưu trữ, nslookup giải quyết ok, curl - không thể trên cùng tên máy chủ.

Sau khi giao tiếp tcpdumping tôi thấy rằng curl cố gắng thiết lập kết nối TCP (ngoài UDP) với cổng DNS, được đóng trong bộ định tuyến của tôi. Sau khi cổng tcp 53 được kích hoạt, curl bắt đầu hoạt động hoàn hảo.

Một điều kỳ lạ là vấn đề này không xuất hiện nếu máy chủ dns được cài đặt liên kết thường xuyên. Nếu tôi sử dụng nhúng vào máy chủ DNS của bộ định tuyến, curl đột nhiên cố gắng sử dụng các cổng TCP ngay cả khi câu trả lời đã nhận được (!) Qua UDP 2ms trước đó. Tôi cho rằng đây là lỗi.

Tôi đã gặp vấn đề tương tự trên VE của tôi (chạy trên máy tính xách tay của tôi) ngày hôm nay, và thấy nó khá đáng ngạc nhiên. Dig và NSlookup hoạt động, nhưng curl thất bại.

Ví dụ:

# curl -v google.com
* getaddrinfo(3) failed for google.com:80
* Couldn't resolve host 'google.com'
* Closing connection #0
curl: (6) Couldn't resolve host 'google.com'

Nhưng khi tôi thấy bài viết của David T ở đây, tôi đã quyết định thử nó với curl. Vì vậy, trong khi điều này thất bại:

# curl  google.com -6
curl: (6) Couldn't resolve host 'google.com'

Điều này thành công:

# curl  google.com -4
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>

-6 chỉ định rằng curl sử dụng IPv6 và -4, để sử dụng IPv4. Tôi gặp lỗi tương tự khi sử dụng wget, vì vậy chắc chắn một số vấn đề với ngăn xếp IPv6 trên Máy chủ.

Tất cả các sửa đổi khác đối với tệp nsswitch.conf và các tệp conf BIND khác không giúp ích được vì vấn đề không nằm ở tiện ích này.

Nếu điều này xảy ra đối với bất kỳ ai đang cố gắng thiết lập DNS cho phiên bản AWS EC2, hãy đảm bảo cũng bật quy tắc IPv6 (:: / 0) cho HTTP và HTTPS trong nhóm bảo mật được sử dụng bởi trường hợp đó.

Cài đặt curl của bạn có trơn tru không? Nếu có thể hãy thử cài đặt lại curl.

Cố gắng curl -v google.comđể có được đầu ra dài dòng hơn để gỡ lỗi.

ví dụ:

curl -v dnserror.test
* getaddrinfo(3) failed for dnserror.test:80
* Couldn't resolve host 'dnserror.test'
* Closing connection #0
curl: (6) Couldn't resolve host 'dnserror.test'

Bạn có nhận được đầu ra tương tự?

Có thể có một lỗi trong tệp /etc/resolv.conf của bạn mà nslookup chấp nhận nhưng curl thì không.

Câu hỏi được đặt ra là "Làm thế nào có thể tôi có thể thực hiện tra cứu máy chủ nhưng không phải là một cuộn tròn?"

Điều này là có thể bởi vì curl sử dụng getaddrinfo () để giải quyết FQDN, trong khi nslookup thì không. Thay vào đó, tôi tin rằng nslookup phân tích cú pháp /etc/resolv.conf bằng cách sử dụng một số chức năng hoặc thư viện khác hoặc thông qua mã tùy chỉnh của riêng mình. Tôi đã không nhìn vào mã nguồn để xác minh điều này, nhưng bạn có thể chứng minh nó bằng cách thêm khoảng trắng phía trước mã thông báo máy chủ tên trong /etc/resolv.conf. nslookup có thể phân tích cú pháp này nhưng getaddrinfo () thì không thể.

Example /etc/resolv.conf
 nameserver 8.8.8.8

Nếu độ phân giải của bạn có lỗi này hoặc các lỗi khác được nslookup chấp nhận nhưng không phải là getaddrinfo (), thì bạn có thể giải quyết FQDN bằng nslookup, nhưng bạn sẽ không thể sử dụng curl trên FQDN đó.

Khắc phục: với quyền root, chỉnh sửa /etc/resolv.conf và xóa mọi khoảng trắng hàng đầu trên dòng máy chủ tên.