Men-debug kesalahan resolusi DNS

Saya men-debug kesalahan resolusi DNS untuk domain auth.otc.t-systems.comdengan server Cloudflare, tetapi macet. Yang aneh adalah bahwa pencarian berhasil / gagal tergantung pada mesin yang menjalankan kueri, tapi saya tidak tahu di mana konfigurasi berbeda.

Kegagalan selalu dengan pesan berikut: server can't find auth.otc.t-systems.com: SERVFAIL

1.1.1.1 adalah DNS Cloudflare.

Apa yang saya coba sejauh ini:

Berjalan nslookup auth.otc.t-systems.com 1.1.1.1di berbagai mesin:
- Gagal di mesin saya dengan internet kantor & rumah (namun berhasil dengan DNS Google dalam kedua kasus).
- Gagal pada mesin rekan dengan internet kerja.
- Berhasil dalam sesi ssh ke server jauh.
Sekarang saya akan berasumsi bahwa ada beberapa konfigurasi aneh di internet kantor kami, yang menyebabkan pencarian gagal. Namun saya tidak tahu apa yang harus saya cari dan saya juga menemukan beberapa layanan nslookup online yang gagal juga:
- Gagal: https://network-tools.com/nslook/Default.asp?domain=auth.otc.t-systems.com&type=1&server=1.1.1.1&class=1&port=53&timeout=5000&go.x=21&go.y=13
- Bekerja: http://www.kloth.net/services/nslookup.php

Adakah petunjuk bagaimana saya dapat men-debug ini lebih lanjut?

networking domain-name-system

— Thomas Obermüller
sumber

Apakah Anda juga mencoba dengan 1.0.0.1atau jika Anda memiliki IPv6 2606:4700:4700::1111dan 2606:4700:4700::1001, mereka semua juga CloudFlare. Lihat juga blog.cloudflare.com/fixing-reachability-to-1-1-1-1-1- secara global dan paragraf terakhirnya memberikan cara untuk melaporkan masalah.

— Patrick Mevzek

Jawaban:

Coba gunakan gali. Dua puluh tahun yang lalu mereka mencoba untuk tidak menggunakan nslookup, tetapi sekarang sudah tertanam dalam memori otot dan tidak mungkin untuk disingkirkan, tetapi penggalian jauh lebih unggul. Sebagai contoh.

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

Akan melacak resolusi sepenuhnya untuk Anda, dan Anda dapat melihat di mana mereka berbeda.

— Sirch
sumber

Terima kasih, saya tidak tahu tentang nslookup. Saya sekarang sudah mencoba perintah menggali dan anehnya mengembalikan ip yang benar pada mesin saya. Saya telah memposting output dari perintah pada mesin saya dan mesin lokal di sini gist.github.com/thomas88/600d367387505a13223a5270c89eedda . Apa pun penggalian yang berbeda, browser saya (Chrome pada Mac) tampaknya lebih sesuai dengan nslookup - itu tidak dapat menyelesaikan alamat.

— Thomas Obermüller

Tidak ada alasan untuk mengharapkan hasil yang berbeda antara digdan nslookupuntuk permintaan ini. Namun karena 1.1.1.1merupakan alamat anycast, hasilnya dapat berbeda tergantung pada server mana permintaan akhirnya dilayani.

— kasperd

Chrome, menjadi klien web mungkin mengarahkan Anda. Apakah tajuk http ... curl -Saya <laman web Anda mencoba> mengungkapkan sesuatu tentang penerusan?

— Sirch

Apa gunanya menggunakan keduanya +tracedan @1.1.1.1? Apakah Anda yakin memahami cara kerja opsi ini?

— Barmar

Ya, saya yakin saya mengerti bagaimana ini bekerja bersama. Tujuan menggunakan @ <alamat> adalah menentukan server dns yang digunakan kliennya di dua lokasi. Dalam contoh yang diberikan, cloudflare-nya, tetapi jika klien lain menggunakan server dns yang berbeda, itu akan ditentukan di sana. Misalnya, di mana saya berada, alamat server di resolv.conf adalah alamat perusahaan, tetapi saya masih bisa menyelesaikannya dari 1.1.1.1

— Sirch

Orang-orang jaringan telah menggunakan untuk usia 1.1.1.1 sebagai pengganti ke alamat pribadi lain di antarmuka acak switch / router AP. (Saya sendiri berada di lokasi saat ini di mana publik menghadapi alamat IP dari ratusan AP nirkabel adalah 1.1.1.1)

Saya bertaruh uang saya di mesin Anda tidak dapat berbicara dengan 1.1.1.1 Cloufare bahwa Anda memiliki rute (segera) di sana untuk antarmuka tersebut.

Misalnya, dalam kasus saya, 1.1.1.1 memberi saya alamat IP saya:

$ 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

— Rui F Ribeiro
sumber

Inilah sebabnya mengapa RFC 3849 dan RFC 5737 harus ditegakkan dengan ketat.

— kasperd

"Terlalu rendah" adalah dasar yang sulit untuk menentukan apa pun. Cloudflare memiliki banyak PoP. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 msadalah RTT saya untuk hal yang nyata.

— Håkan Lindqvist

@ HåkanLindqvist Nilai Anda tampaknya keterlambatan terlalu rendah untuk koneksi eksternal .... tapi ya, bukan metrik yang dapat diandalkan.

— Rui F Ribeiro

@RuiFRibeiro Latency tampaknya tepat untuk konektivitas kota yang sama tanpa melibatkan tautan latensi tinggi. (Traceroute menunjukkan 4 alamat dalam ISP saya, alamat Cloudflare di pertukaran internet di kota saya, lalu 1.1.1.1.)

— Håkan Lindqvist

Tampaknya saya dapat mencapai Cloudflare DNS, hanya saja domain saya gagal. Saya telah menjalankan nslookup untuk auth.otc.t-systems.comdan serverfault.com. Inilah hasil dari tcpdump: gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d

— Thomas Obermüller