Lỗi gỡ lỗi độ phân giải DNS


11

Tôi đang gỡ lỗi lỗi độ phân giải DNS cho tên miền auth.otc.t-systems.comvới máy chủ của Cloudflare, nhưng đã bị kẹt. Điều kỳ lạ là việc tra cứu thành công / thất bại tùy thuộc vào máy chạy truy vấn, nhưng tôi không thể tìm ra cấu hình khác nhau ở đâu.

Thất bại luôn có thông báo sau: server can't find auth.otc.t-systems.com: SERVFAIL

1.1.1.1 là DNS của Cloudflare.

Những gì tôi đã cố gắng cho đến nay:

  • Chạy nslookup auth.otc.t-systems.com 1.1.1.1trên nhiều máy khác nhau:
    • Nó không hoạt động trên máy của tôi với internet công việc & gia đình (tuy nhiên, nó thành công với DNS của Google trong cả hai trường hợp).
    • Nó thất bại trên một máy đồng nghiệp với internet làm việc.
    • Nó thành công trong một phiên ssh đến một máy chủ từ xa.
  • Bây giờ tôi sẽ giả định rằng có một số cấu hình lạ trên internet công việc của chúng tôi, khiến cho việc tra cứu thất bại. Tuy nhiên tôi không biết mình nên tìm gì và tôi cũng đã tìm thấy một số dịch vụ nslookup trực tuyến cũng thất bại:

Bất kỳ gợi ý làm thế nào tôi có thể gỡ lỗi này?


Bạn cũng đã thử với 1.0.0.1hoặc nếu bạn có IPv6 2606:4700:4700::11112606:4700:4700::1001tất cả chúng đều là CloudFlare. Ngoài ra, hãy xem blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally và đoạn cuối của nó đưa ra cách để báo cáo vấn đề.
Patrick Mevzek

Câu trả lời:


10

Hãy thử sử dụng đào. Hai mươi năm trước họ đã cố gắng không dùng nslookup, nhưng nó đã ăn sâu vào bộ nhớ cơ bây giờ và không thể thoát khỏi, nhưng đào thì vượt trội hơn nhiều. Ví dụ.

dig +trace auth.otc.t-systems.com @1.1.1.1

Sẽ theo dõi độ phân giải đầy đủ cho bạn và bạn có thể thấy chúng khác nhau ở đâu.


Cảm ơn, tôi không biết điều đó về nslookup. Bây giờ tôi đã thử lệnh đào và thật lạ là nó trả về đúng ip trên máy của tôi. Tôi đã đăng kết quả đầu ra từ lệnh trên cả máy của tôi và máy cục bộ tại đây gist.github.com/thomas88/600d367387505a13223a5270c89eedda . Dù đào khác nhau, trình duyệt của tôi (Chrome trên Mac) dường như phù hợp hơn với nslookup - nó không thể giải quyết địa chỉ.
Thomas Obermüller

2
Không có bất kỳ lý do nào để mong đợi các kết quả khác nhau giữa dignslookupcho truy vấn này. Tuy nhiên, vì 1.1.1.1là một địa chỉ anycast nên kết quả có thể khác nhau tùy thuộc vào máy chủ mà truy vấn cuối cùng được phục vụ.
kasperd

Chrome, là một khách hàng web có thể đang chuyển hướng bạn. Có tiêu đề http ... curl -Tôi <trang web bạn đang cố truy cập> tiết lộ bất cứ điều gì về chuyển tiếp?
Sirch

Điểm của việc sử dụng cả hai +tracevà là @1.1.1.1gì? Bạn có chắc bạn hiểu làm thế nào các tùy chọn này làm việc cùng nhau?
Barmar

1
Vâng, tôi chắc chắn tôi hiểu làm thế nào những điều này làm việc cùng nhau. Điểm sử dụng @ <address> sẽ chỉ định các máy chủ dns mà máy khách của anh ta đang sử dụng ở hai vị trí. Trong ví dụ đã cho, đám mây của nó, nhưng nếu một máy khách khác sử dụng máy chủ dns khác, nó sẽ được chỉ định ở đó. Ví dụ: tôi đang ở đâu, địa chỉ máy chủ trong phân giải là một công ty, nhưng tôi vẫn có thể giải quyết từ 1.1.1.1
Sirch

3

Người mạng đã sử dụng cho độ tuổi 1.1.1.1 để thay thế cho một địa chỉ riêng khác trong các giao diện ngẫu nhiên của các AP / bộ định tuyến AP. (Tôi đang ở một địa điểm tại thời điểm này, nơi địa chỉ IP đối mặt công khai của hàng trăm AP không dây là 1.1.1.1)

Tôi đặt cược tiền của mình vào các máy mà bạn không thể nói chuyện với 1.1.1.1 của Cloufare rằng bạn có tuyến đường (ngay lập tức) ở đó cho giao diện như vậy.

Chẳng hạn, trong trường hợp của tôi, 1.1.1.1 đang cho tôi địa chỉ IP của tôi:

$ sudo tcpdump -i any -n host 1.1.1.1 and port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:11:51.037186 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296
13:11:51.037250 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296

4
Đây là lý do tại sao RFC 3849 và RFC 5737 phải được thi hành nghiêm ngặt.
kasperd

1
"Quá thấp" là một cơ sở khó khăn để xác định bất cứ điều gì, mặc dù. Cloudflare có rất nhiều PoP. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 mslà RTT của tôi với thực tế.
Håkan Lindqvist

@ HåkanLindqvist Giá trị của bạn vẻ như độ trễ quá thấp cho kết nối bên ngoài .... nhưng vâng, không phải là một số liệu đáng tin cậy.
Rui F Ribeiro

@RuiFRibeiro Độ trễ có vẻ phù hợp với kết nối cùng thành phố không có liên kết độ trễ cao liên quan. (Traceroute hiển thị 4 địa chỉ trong ISP của tôi, địa chỉ Cloudflare tại một sàn giao dịch internet trong thành phố của tôi, sau đó 1.1.1.1.)
Håkan Lindqvist

Dường như tôi có thể truy cập DNS Cloudflare, chỉ có điều đó không thành công cho tên miền đối với tôi. Tôi đã chạy nslookup cho auth.otc.t-systems.comserverfault.com. Đây là kết quả từ tcpdump: gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d
Thomas Obermüller
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.