Дозвіл DNS Не вдається пінг і згортання, але не копається

Я використовую DNSMasq як локальний DNS-сервер, тому я можу вирішити *.local.pcfdev.io(як обговорювалося тут, використовуючи PCF Dev Offline з Mac OS X ). Все спрацювало, коли я вперше налаштував речі.

Через пару днів, після кількох перезавантажень мого MacBook, в режимі офлайн я більше не можу вирішувати такі речі, як api.local.pcfdev.ioвикористання curlабо ping. Однак digробить правильно.

$ dig api.local.pcfdev.io

; <<>> DiG 9.8.3-P1 <<>> api.local.pcfdev.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46877
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;api.local.pcfdev.io.       IN      A

;; ANSWER SECTION:
api.local.pcfdev.io.    0       IN      A       192.168.11.11

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep  6 10:17:44 2016
;; MSG SIZE  rcvd: 53

$ curl api.local.pcfdev.io
curl: (6) Could not resolve host: api.local.pcfdev.io

Я спробував , додавши в -AlwaysAppendSearchDomainsякості аргументу /usr/sbin/mDNSResponderв /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistі перезапустив mDNSResponder з launchctl, але безрезультатно.

ОНОВЛЕННЯ 1

У правильному локальному IP-адресі напевно є щось прослуховування:

$ nslookup api.local.pcfdev.io
Server:     127.0.0.1
Address:        127.0.0.1#53

Name:   api.local.pcfdev.io
Address: 192.168.11.11

$ ping api.local.pcfdev.io
ping: cannot resolve api.local.pcfdev.io: Unknown host

$ telnet 192.168.11.11 80
Trying 192.168.11.11...
Connected to 192.168.11.11.
Escape character is '^]'.

HTTP/1.1 400 Bad Request

Connection closed by foreign host.

ОНОВЛЕННЯ 2

Спробувавши запропоновану нижче пропозицію про видалення всіх серверів DNS з мережевих налаштувань, за винятком 127.0.0.1, я нічого не можу вирішити. Мені вдалося вийти з виправлення помилок mDNSResponder:

mDNSResponder[91]:  74: DNSServiceCreateConnection START PID[32612](ping)
mDNSResponder[91]:  74: Error socket 75 created 00000000 00000001
mDNSResponder[91]:  74: DNSServiceQueryRecord(15000, 0, api.local.pcfdev.io., Addr) START PID[32612]()
mDNSResponder[91]:  74: Error socket 75 closed  00000000 00000001 (0)
mDNSResponder[91]:  74: DNSServiceQueryRecord(api.local.pcfdev.io., Addr) ADD    0 api.local.pcfdev.io. Addr
mDNSResponder[91]:  74: Cancel 00000000 00000001
mDNSResponder[91]:  74: DNSServiceQueryRecord(api.local.pcfdev.io., Addr) STOP PID[32612]()
mDNSResponder[91]:  74: DNSServiceCreateConnection STOP PID[32612](ping)

Я також зауважував, що, як пояснено у запропонованій відповіді, nslookupі digне спричиняє що-небудь реєструватись mDNSResponder, але інші інструменти ( ping, curl) роблять.

Тож здається, що з будь-якої причини або dnsmasqне працює (я можу встановити TCP-з'єднання 127.0.0.1:53), або mDNSResponderне використовує його.

ОНОВЛЕННЯ 3

etc/resolve.confперестає існувати, коли мій адаптер wifi активний, але я не підключений до мережі. Чи може це бути, чому інструменти CLI не використовують локальний dnsmasqсервер?

macos yosemite dns

— EngineerBetter_DJ
джерело

Чи випадково вимкнеться ваш мережевий адаптер? Якщо ви перейдете до "Мережі" в системних налаштуваннях, чи є зелена крапка біля адаптера, який налаштовано для використання dnsmasq?

— манго

Що ж, я в поїзді без Wi-Fi, так мабуть.

— EngineerBetter_DJ

Зокрема, вимкнено адаптер wifi? Якщо так, спробуйте ще раз із увімкненим адаптером Wi-Fi (навіть якщо він насправді не підключений до Інтернету). Для установки на роботу, Dnsmasq повинен бути DNS - сервер на мережевому інтерфейсі в використанні .

— манго

Дякуємо, що спробували відстежити це. Я також борюся з цим, не розумію, чому "curl foo: 8989" не може знайти хоста, але може "копати foo". Так, "curl 172.20.0.17:8989" працює чудово. Як і ви, у мене для DNS-мережі Wi-Fi встановлено 127.0.0.1 (dnsmasq, що працює в контейнері докера). FWIW в моїй ситуації зараз проблема характерна для мережі Wi-Fi, до якої я підключаюсь - працює чудово на моїй персональній точці доступу, проблема - на Wi-Fi у кафе.

— джамшид

Я не інженерно розробив ці програми, але я сподіваюся, що вони викликають зовсім інші бази кодів роздільної здатності DNS, і тому ви бачите поломку - деякі вказують локально, інші - ні. Я б , ймовірно , копатися curlабо wgetабо отримати їх в інструменти / Профілювальники / відладчик і подивитися , що на насправді відбувається , щоб викликати не може дозволити помилку.

— bmike

Відповіді:

Був цей самий випуск. Я думаю, що локальний кеш DNS мав погані дані з мого попереднього тестування. Це було швидко виправлено:

sudo killall -HUP mDNSResponder

— cmcginty
джерело

Я помітив , що pingі digіноді повертаю різні IP - адреса (зазвичай з роздільним горизонтом DNS) і ця команда виправляє його. У чому першопричина, на жаль, не впевнений.

— Джеймс

копати з одного боку, а curl / ping з іншого - отримувати дані від різних хостів:

викопайте запити сервера DNS - у вашому випадку ваш localhost (127.0.0.1) - для запису бази даних: IP-адреса, пов'язана з FQDN api.local.pcfdev.io. Сам хост зовсім не повинен запускатись або навіть існувати.

curl / ping спробуйте вирішити IP-адресу за допомогою mDNSResponder або іншими способами і, нарешті, працювати з / віддаленим хостом. Якщо хост 192.168.11.11 не працює або взагалі не існує, обидва вийдуть з ладу.

Тепер або запис DNS неправильний (api.local.pcfdev.io має інший IP, ніж 192.168.11.11), або запис DNS є правильним, але хост 192.168.11.11 не працює.

Додавання -AlwaysAppendSearchDomains як аргумент до / usr / sbin / mDNSResponder в /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist не рекомендується. Замість цього слід додати його до /Library/Preferences/com.apple.mDNSResponder.plist (джерело:) man mDNSResponder:

Щоб змусити mDNSResponder запускатися з цими необов'язковими аргументами при його запуску на OS X 10.11 (El Capitan) та пізніших версій, встановіть бутові ключі AlwaysAppendSearchDomains або NoMulticastAdvertisitions в true /Library/Preferences/com.apple.mDNSResponder.plist та перезавантажте.

У вашому випадку взагалі не потрібно встановлювати цей ключ, оскільки це не є причиною вашої проблеми.

Після заглиблення у VirtualBox, PCF Dev (невдача декількох із "неправильними обліковими даними", намагаючись увійти у віртуальну машину) та dnsmasq, я рекомендую перенести запити DNS лише у dnsmasq:

У системних налаштуваннях> Мережа> Інтерфейс> DNS-сервер видаліть усі DNS-сервери, крім 127.0.0.1, та застосуйте зміни. Ви також можете налаштувати друге місце з установкою лише 127.0.0.1 і зберегти поточний DNS-сервер в іншій конфігурації.

додайте файл /usr/local/etc/resolv.dnsmasq.conf із вмістом

#use your preferred DNS servers here. In the example I use some Google name servers
nameserver 8.8.8.8
nameserver 8.8.4.4

додати resolv-file=/usr/local/etc/resolv.dnsmasq.confв рядок ~ 46 з /usr/local/etc/dnsmasq.conf
додайте або перемістіться address=/.local.pcfdev.io/192.168.11.11на / до рядка ~ 80 з /usr/local/etc/dnsmasq.conf

перезапустити dnsmasq за допомогою:

sudo launchctl stop homebrew.mxcl.dnsmasq
sudo launchctl start homebrew.mxcl.dnsmasq

— кланомат
джерело

Дякуємо, що знайшли час для відповіді. Напевно щось слухається 192.168.11.11; фактичний загальнодоступний запис DNS *.local.pcfdev.ioзавжди вказує на той самий локальний IP-адресу, тому щойно я підключаюсь до інформаційних веб-сторінок, я curlповинен отримувати відповідь від цього DNS-сервера і може зрозуміти, яку IP-адресу використовувати.

— EngineerBetter_DJ

Схоже curl, pingі інші виконувані файли , я хочу , щоб вразити цю річ використовує один засіб відриваючись записи DNS (який не використовується dnsmasqсервером на локальному хості), а також nslookupі digвикористовують інші засоби. Я думаю, мені потрібно дізнатися більше про mDNSResponder!

— EngineerBetter_DJ

@EngineerBetter Чи є у вас інші записи в системних налаштуваннях> Мережа> Інтерфейс> DNS, ніж 127.0.0.1? - Я встановлю весь пакет (VBox, PCF Dev тощо) і перевірте це ... Будь-який спеціальний конфігурація?

— кланомат

Ще раз дякую, що знайшли час, щоб допомогти мені в цьому. Питання оновлено, і все ще не пощастило.

— EngineerBetter_DJ

Мені знадобилося набагато більше часу, щоб вирішити це, ніж це повинно було. Після перезапуску mDNSResolver десятки разів, як рекомендовано в інших потоках:

sudo killall -HUP mDNSResponder

Нарешті я спробував щось інше. Я відключив Wi-Fi та видалив усі мої уподобані мережі. Потім я відновив Wi-Fi-з'єднання, і все працювало нормально:

Меню Apple -> Налаштування системи -> Wi-Fi (зліва)
"Вимкнути Wi-Fi", а потім виберіть "Додатково"
Видаліть з’єднання Wi-Fi, у якого виникають проблеми (або всі, якщо вам це потрібно). Зробіть це, вибравши мережу Wi-Fi, яку потрібно видалити, і натиснувши "-"
Натисніть "Застосувати" та "ОК"
Увімкніть Wi-Fi знову.
Виберіть свою мережу Wi-Fi та увійдіть знову.

YMMV, але саме це нарешті працювало для мене. Це, мабуть, мало бути першим, що я спробував.

— Джоел Гріффітс
джерело