การดีบักข้อผิดพลาดการแก้ไข DNS

ฉันกำลังแก้ไขข้อผิดพลาดในการแก้ไข DNS สำหรับโดเมนที่auth.otc.t-systems.comมีเซิร์ฟเวอร์ของ Cloudflare แต่ติดขัด สิ่งที่แปลกคือการค้นหาประสบความสำเร็จ / ล้มเหลวขึ้นอยู่กับเครื่องที่รันการสืบค้น แต่ฉันไม่สามารถคิดได้ว่าการกำหนดค่าแตกต่างกันอย่างไร

ความล้มเหลวอยู่เสมอพร้อมกับข้อความต่อไปนี้: server can't find auth.otc.t-systems.com: SERVFAIL

1.1.1.1 เป็น DNS ของ Cloudflare

สิ่งที่ฉันลองมาแล้ว:

ทำงานnslookup auth.otc.t-systems.com 1.1.1.1บนเครื่องต่างๆ:
- มันล้มเหลวในเครื่องของฉันกับอินเทอร์เน็ตที่ทำงาน & ที่บ้าน (แต่มันก็ประสบความสำเร็จกับ DNS ของ Google ในทั้งสองกรณี)
- มันล้มเหลวในเครื่องเพื่อนร่วมงานกับอินเทอร์เน็ตทำงาน
- มันประสบความสำเร็จในเซสชั่น ssh ไปยังเซิร์ฟเวอร์ระยะไกล
ตอนนี้ฉันจะสมมติว่ามีการกำหนดค่าแปลก ๆ บนอินเทอร์เน็ตงานของเราซึ่งทำให้การค้นหาล้มเหลว อย่างไรก็ตามฉันไม่รู้ว่าฉันควรมองหาอะไรและฉันก็พบบริการออนไลน์ nslookup ที่ล้มเหลวเช่นกัน:
- ล้มเหลว: 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
- ผลงาน: http://www.kloth.net/services/nslookup.php

คำแนะนำใด ๆ ที่ฉันสามารถแก้ไขข้อบกพร่องนี้ต่อไปได้?

networking domain-name-system

— โทมัสObermüller
แหล่งที่มา

คุณลองด้วย1.0.0.1หรือไม่ถ้าคุณมี IPv6 2606:4700:4700::1111และ2606:4700:4700::1001ทั้งหมดเป็น CloudFlare ด้วย ดูที่blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globallyและย่อหน้าสุดท้ายให้วิธีรายงานปัญหา

— Patrick Mevzek

คำตอบ:

ลองใช้ขุด ยี่สิบปีที่แล้วพวกเขาพยายามที่จะเลิกใช้ nslookup แต่มันฝังแน่นในหน่วยความจำของกล้ามเนื้อในขณะนี้และเป็นไปไม่ได้ที่จะกำจัด แต่ขุดอยู่เหนือกว่า ตัวอย่างเช่น.

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

จะติดตามความละเอียดอย่างเต็มที่สำหรับคุณและคุณสามารถดูว่าพวกเขาแตกต่างกันอย่างไร

— Sirch
แหล่งที่มา

ขอบคุณฉันไม่รู้เกี่ยวกับ nslookup ตอนนี้ฉันได้ลองใช้คำสั่ง dig แล้วก็ส่งคืน ip ที่ถูกต้องบนเครื่องของฉัน ผมได้โพสต์เอาท์พุทจากคำสั่งได้ทั้งบนเครื่องและเครื่องท้องถิ่นของฉันที่นี่gist.github.com/thomas88/600d367387505a13223a5270c89eedda ไม่ว่าการขุดจะแตกต่างกันอย่างไรเบราว์เซอร์ของฉัน (Chrome บน Mac) ดูเหมือนจะสอดคล้องกับ nslookup มากขึ้น แต่ไม่สามารถแก้ไขที่อยู่ได้

— โทมัสObermüller

ไม่มีเหตุผลใด ๆ ที่จะคาดหวังผลลัพธ์ที่แตกต่างระหว่างdigและnslookupสำหรับแบบสอบถามนี้ อย่างไรก็ตามเนื่องจาก1.1.1.1เป็นที่อยู่ของการออกอากาศใด ๆ ผลลัพธ์อาจแตกต่างกันไปขึ้นอยู่กับเซิร์ฟเวอร์ที่แบบสอบถามได้รับการบริการ

— kasperd

Chrome ซึ่งเป็นเว็บไคลเอ็นต์อาจเปลี่ยนเส้นทางคุณ ส่วนหัว http ... curl -I <หน้าเว็บที่คุณพยายามจะไป> เปิดเผยอะไรเกี่ยวกับการส่งต่อหรือไม่

— Sirch

สิ่งที่จุดของการใช้ทั้งใน+traceและ@1.1.1.1? คุณแน่ใจหรือว่าคุณเข้าใจว่าตัวเลือกเหล่านี้ทำงานร่วมกันได้อย่างไร

— Barmar

ใช่ฉันมั่นใจว่าฉันเข้าใจการทำงานร่วมกันของเหล่านี้ จุดของการใช้ @ <address> คือการระบุเซิร์ฟเวอร์ dns ที่ไคลเอ็นต์ของเขาใช้ในสองตำแหน่ง ในตัวอย่างที่กำหนดให้ cloudflare ของมัน แต่ถ้าลูกค้าอื่นใช้เซิร์ฟเวอร์ DNS ที่แตกต่างกันก็จะมีการระบุไว้ที่นั่น ตัวอย่างเช่นที่ฉันอยู่ที่อยู่เซิร์ฟเวอร์ใน resolv.conf เป็น บริษัท หนึ่ง แต่ฉันยังคงสามารถแก้ไขได้จาก 1.1.1.1

— Sirch

ผู้คนในเครือข่ายใช้ช่วงวัย 1.1.1.1 เพื่อแทนที่ที่อยู่ส่วนตัวอื่นในส่วนต่อประสานแบบสุ่มของสวิตช์ / เราเตอร์ AP (ตอนนี้ฉันอยู่ที่สถานที่ซึ่งผู้คนหันหน้าเข้าหาที่อยู่ IP ของ AP ไร้สายนับร้อยคือ 1.1.1.1)

ฉันเดิมพันเงินของฉันในเครื่องที่คุณไม่สามารถพูดคุยกับ Cloufare's 1.1.1.1 ว่าคุณมีเส้นทาง (กลาง) ที่นั่นสำหรับส่วนต่อประสานดังกล่าว

ตัวอย่างเช่นในกรณีของฉัน 1.1.1.1 ให้ที่อยู่ IP ของฉัน:

$ 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
แหล่งที่มา

นี่คือเหตุผลที่ RFC 3849 และ RFC 5737 ต้องมีการบังคับใช้อย่างเข้มงวด

— kasperd

"ต่ำเกินไป" เป็นพื้นฐานที่ยุ่งยากในการพิจารณาทุกอย่าง Cloudflare มี PoP จำนวนมาก 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 msRTT ของฉันเป็นของจริงหรือเปล่า

— Håkan Lindqvist

@ HåkanLindqvistค่าของคุณ จะดูเหมือนมีความล่าช้าต่ำเกินไปสำหรับการเชื่อมต่อภายนอก .... แต่ใช่ไม่ได้เป็นตัวชี้วัดที่มีความน่าเชื่อถือ

— Rui F Ribeiro

@RuiFRibeiro Latency ดูเหมือนจะเหมาะสมสำหรับการเชื่อมต่อในเมืองเดียวกันโดยไม่มีลิงก์แฝงสูงที่เกี่ยวข้อง (Traceroute แสดงที่อยู่ 4 แห่งภายใน ISP ของฉันที่อยู่ Cloudflare ที่การแลกเปลี่ยนทางอินเทอร์เน็ตในเมืองของฉันจากนั้น 1.1.1.1)

— Håkan Lindqvist

ดูเหมือนว่าฉันจะสามารถเข้าถึง Cloudflare DNS ได้ แต่ล้มเหลวสำหรับโดเมนของฉันเท่านั้น ผมเคยทำงาน nslookup สำหรับและauth.otc.t-systems.com serverfault.comนี่คือผลลัพธ์จาก tcpdump: gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d

— Thomas Obermüller