Помилка роздільної здатності 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

— Томас Обермюллер
джерело

Ви також спробували 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 та його останній абзац, який дає способи повідомити про проблему.

— Патрік Мевзек

Відповіді:

Спробуйте скопати. Двадцять років тому вони намагалися принизити nslookup, але його міцно вбудовано в м’язову пам’ять і позбутися неможливо, але копати набагато вище. Наприклад.

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

Буде повністю простежено роздільну здатність для вас, і ви можете побачити, де вони відрізняються.

— Сірч
джерело

Дякую, я не знав цього про nslookup. Зараз я спробував команду dig і дивно, що вона повертає правильний ip на моїй машині. Я опублікував вихід з команди як на моїй машині, так і на локальній машині тут gist.github.com/thomas88/600d367387505a13223a5270c89eedda . Незалежно від копання, мій браузер (Chrome на Mac) здається, що він більше відповідає nslookup - він не може вирішити адресу.

— Томас Обермюллер

Немає жодних підстав очікувати різних результатів між цим запитом digта nslookupза ним. Однак, оскільки 1.1.1.1це адреса anycast, результат може відрізнятися залежно від того, на якому сервері в результаті запит обслуговується.

— kasperd

Chrome, будучи веб-клієнтом, може переспрямувати вас. Чи заголовок http ... curl -I <веб-сторінка, на яку ви намагаєтесь дістатися,> виявляє щось про переадресацію?

— Сірч

У чому сенс використання обох +traceта @1.1.1.1? Ви впевнені, що розумієте, як ці варіанти працюють разом?

— Бармар

Так, я впевнений, що розумію, як вони працюють разом. Сенсом використання @ <adress> було б вказати сервери dns, якими користується його клієнт у двох місцях. У наведеному прикладі є його cloudflare, але якщо інший клієнт використовує інший dns-сервер, він буде вказаний там. Наприклад, там, де я перебуваю, адреса сервера в резоль.conf - це компанія, але я все ще можу вирішити питання з 1.1.1.1

— Sirch

Люди мережі використовували протягом вікових періодів 1.1.1.1 як заміну на іншу приватну адресу у випадкових інтерфейсах AP-комутаторів / маршрутизаторів. (Я зараз перебуваю в такому місці, де адреса для користувачів, що стикаються із IP-адресами сотень бездротових додатків 1.1.1.1)

Маю на сумні свої гроші на машинах, на яких ви не в змозі поговорити з 1.1.1.1 Cloufare, що у вас є такий (невідкладний) маршрут для такого інтерфейсу.

Наприклад, у моєму випадку 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 є багато PoPs. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 msце моя RTT до реальної речі.

— Хокан Ліндквіст

@ HåkanLindqvist Ваше значення дійсно , здається занадто низькою затримки для зовнішнього з'єднання .... але так, не надійний показник.

— Rui F Ribeiro

@RuiFRibeiro Latency, здається, є правильним для підключення до одного міста без участі у високому затримці. (Traceroute показує 4 адреси в моєму інтернет-провайдері. Cloudflare-адреса в інтернет-обміні в моєму місті, тоді 1.1.1.1.)

— Håkan Lindqvist

Здається, що я можу дістатись до DNS Cloudflare, тільки він не вдається для домену для мене. Я запустив nslookup для auth.otc.t-systems.comі serverfault.com. Ось результат від tcpdump: gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d

— Thomas Obermüller