Здійснення DNS-пошуку не відбувається, наприклад, "ping", але працюють з `host`


34

Я використовую pfSense 2.0rc3, і я встановив його як DNS експедитор і включив "Реєстрація DHCP оренди в DNS експедитора" і те, що я розумію, є всі відповідні налаштування для отримання DNS-сервера для локальних пошуків.

Він працює, як і очікувалося, з Linux, і, зокрема, я можу запускати host abcі ping abc(і інші програми), і всі вони працюють так, як очікувалося.

Однак у Mac OS X Lion 10.7 він не працює, як очікувалося. Зокрема, hostвиглядають тільки пошуки з командою, тобто

$ ping abc
ping: cannot resolve abc: Unknown host

$ host abc
abc.local has address 192.168.1.128

$ ping abc.local
ping: cannot resolve abc.local: Unknown host

$ host abc.local
abc.local has address 192.168.1.128

Чому пошук для abcроботи при використанні hostкоманди, але не з ping(та інших програм)?

Дякуємо за читання.


Я закінчився з такою ж ситуацією на новому Йосеміті (10.10) MBP. Після довгих пошуків і конфігурації, ось відповідь , який працював: apple.stackexchange.com/a/152892 Для запису це без будь - або зміни --AlwaysAppendSearchDomains
Стен Kurdziel

Відповіді:


26

Чому вони зробили цю зміну, я не знаю, але це змусило мене звести з розуму на деякий час.

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

Рекурсивний резольвер від Apple - це mDNSResponder. З якоїсь причини версія mDNSResponder у Lion потребує опції командного рядка "-AlwaysAppendSearchDomains", щоб вести себе так, як це було у Snow Leopard (принаймні).

Нижче наведено швидкий спосіб її усунення:

sudo sed -i .orig '/ProgramArguments/,/<\/array>/ {
s/\(<string>-launchd<\/string>\)/\1\
                <string>-AlwaysAppendSearchDomains<\/string>/
}' /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

(На початку другого-останнього рядка має бути два символи табуляції, але я не міг зрозуміти, як додати цей невеликий редактор до вкладок, тому я додав 16 пробілів. краще підійти до інтервалу вихідного файлу.)

Цей аргумент додасть аргумент "-AlwaysAppendSearchDomains" до файлу запуску PLD mDNSResponder (і збереже резервну копію), але оскільки це контролюється запуск launchd, цій системі потрібно повідомити, щоб перезавантажити mDNSResponder.

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

Тепер, якщо ви перевіряєте запущений процес mDNSResponder, ви повинні побачити його запуск з новим аргументом:

ps auxww | grep mDNSResponder

(Реквізити до http://www.makingitscale.com/2011/fix-for-broken-search-domain-resolution-in-osx-lion.html та http://kavassalis.com/2011/07/wtf-bug -in-os-x-10-7 / , де я знайшов відповіді на цю проблему.)


Це виправлення також працює для Mountain Lion (10.8). Я тільки що застосував його до мого ноутбука.
Sigsegv

Cool! Рада, що я міг допомогти.
Sigsegv

1
FYI: Це не працювало під Йосеміті. Якщо вам потрібні AlwaysAppendSearchDomains на Yosemite, спробуйте: apple.stackexchange.com/a/157017/65787 Це не вирішило проблему .local для мене на Yosemite, але це зробило =) apple.stackexchange.com/a/152892
Stan Kurdziel

Не працює в El Captain. І простіший спосіб зробити здаєтьсяsudo defaults write /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist ProgramArguments -array-add "–AlwaysAppendSearchDomains"
Дмитро Верхотуров

9

З головної сторінки користувача (1):

ПРИМІТКА до Mac OS X

Команда хоста не використовує ім'я хосту та розв'язання адреси, або механізми маршрутизації запитів DNS, що використовуються іншими процесами, запущеними в Mac OS X. Результати запитів імені або адреси, надрукованих хостом, можуть відрізнятися від знайдених іншими процесами, які використовують Mac Механізми рідної назви та адреси адреси OS X. Результати запитів DNS також можуть відрізнятися від запитів, які використовують бібліотеку маршрутизації DNS Mac OS X.

На жаль, немає інформації про те, як саме команда хосту вирішує імена хостів. Така поведінка робить його трохи марним для налагодження, IMHO.


6

Основна історія ... nslookup була командою, але вона мала свою власну реалізацію всіх процедур розв'язання. Те, що почалося, полягало в тому, що системні резольвери на різних платформах працювали інакше, ніж nslookup. Іноді це призведе до певних результатів.

Команди host і dig були створені як "rewrite" для nslookup. Вони статично з'єднуються в функції системи резольвера. Системний резольвер являє собою набір функцій у стандартній бібліотеці C UNIX або UNIX-подібної системи (на Mac OS X ці функції є частиною бібліотеки netdb). Роблячи це, команди хосту та копання завжди функціонують так само, як і системний резольвер для будь-якої ОС, для якої вони побудовані, але вони не покладаються на нього. Таким чином, вони є відмінними засобами діагностики у випадках, коли системний резольвер не працює.

ПРИМІТКА. Хост і копати обидва читають список серверів імен з /etc/resolv.conf, якщо їм не надається конкретний сервер імен, з яким можна поговорити. Лише команда хосту використовує список пошуку у файлі /etc/resolv.conf; dig не має, тому треба завжди давати копати FQDN, щоб вирішити все. Обидві команди цілком самодостатні; Наприклад, файл /etc/resolv.conf є єдиним, що не використовується у двійковому файлі.

mDNSresponder - Bonjour. Я не вкопався в це занадто глибоко, але я підозрюю, що ця конфігураційна установка не фіксує це або принаймні не безпосередньо. Я тільки що відчув цю ж проблему на Mac OS X 10.9.1 і просто перезавантаження mDNSresponder виправити це для мене. Я ніколи не бачив цю проблему раніше на 10.5 -> 10.8 / 10.9 на будь-якій іншій системі. Крім того, GUI-додатки не змінювалися, це тільки інструменти командного рядка, такі як ping і ssh, які розірвалися.

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


4

Я створив сценарій оболонки для автоматизації виправлення (а деінсталятор, якщо він вам потрібен пізніше), тут:

https://github.com/michthom/AlwaysAppendSearchDomains

Це полягало в тому, щоб видавати менш технічним користувачам на роботі, які можуть ухилятися від ручного редагування системних файлів.


4

.local зарезервовано для багатоадресної передачі. mDNS і DNS-сервери в одній мережі з використанням .local можуть бути проблематичними.


1
Я хотів би більше пояснення тут або посилання на деякі документи. Дякуємо за ласий шматок!
bmike

3

Хост додає суфікс .local dns. Пінг не є. Якщо ви виявите, що це занепокоєння, ви можете додати .local як суфікс за замовчуванням в налаштуваннях мережевої системи, і система додасть це при спробі вирішити імена хостів.


Це гарна точка, і вибачте, що я не говорив у цьому питанні, але ping abc.localне працює ні (хоч і host abc.localробить). Я вирішив це питання. pfSense автоматично додає локальний домен як домен пошуку, коли він відправляє оренду DHCP, тому це не було проблемою.
Брайан М. Хант

Вау - дивно. Що станеться, якщо ви повністю кваліфікуєте місцевих з кінцевою. ? ping abc.local.
bmike

1
Те ж результат. Очевидно, що в Mac є два механізми пошуку. Чому вони відрізняються, важко уявити.
Брайан М. Хант

Я не настільки змушую цю відповідь працювати на Yosemite та інших нових ОС. Можливо, ми зможемо отримати кращу відповідь ?
bmike

Існує документація, що попереджає, що файл / etc / hosts використовується тільки в однокористувацькому режимі. Неправда. Я запобігаю ненавмисному доступу до багатьох поганих хлопців, вкладаючи їхні імена в / etc / hosts, маршрутизацію до 127.0.0.1 Я не думаю, що це має значення для цього питання, хоча це, безумовно, показує, що у Apple є кілька диваків. Я також зауважив, що OS X часто міняв мій resolv.conf, тому я встановив cron завдання, щоб відновити його до того, що я хотів кожні десять хвилин.
WGroleau

2

У разі , якщо ви випробували все вище , і нічого не працює , то ви можете додати свої сервера імен та пошук шляху доSystem Preferences>Network>Advance(bottom right of the window)>DNS tab введіть опис зображення тут

Ці оновлення /etc/resolv.conf і ping тепер повинні працювати. Оновлення шляху пошуку шляхом редагування /etc/resolv.conf насправді не працює, але це з певних причин.

ОНОВЛЕННЯ:

Редагування /etc/resolv.conf не працює, оскільки операційна система перезаписує файл на основі налаштувань панелі параметрів системи.


1
"редагування /etc/resolv.conf насправді не працює", тому що операційна система повторно записує її на основі панелі pref.
WGroleau

1
Це дійсно зробило мені трюк, на відміну від прийнятої відповіді.
Артем Пяних

1

Мені бракує достатньої репутації, щоб прокоментувати посаду Ламонта Петерсона . Перезапуск mDNSresponder працював для мене на Mac OS X 10.7 (Lion). На відміну від Ламонта Петерсона, ця проблема викликала проблеми з однією програмою для мене - Safari не міг вирішити загальнодоступні чи приватні імена хостів. Ось конкретні кроки, які я зробив, і я підозрюю, що Ламонт Петерсон також зробив:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSresponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSresponder.plist

У unloadвимикається mDNSresponder і loadпочинає його знову.

Це негайно вирішило проблему; перезавантаження не потрібно.

Можна перевірити, чи успішно його перезавантажено за допомогою listкоманди:

$ sudo launchctl list | grep '^PID\|mDNSResponder'
PID     Status  Label
708     -       com.apple.mDNSResponder
-       0       com.apple.mDNSResponderHelper

Наявність ідентифікатора процесу (PID) означає, що він запущений. 708буде змінюватися, оскільки воно призначено операційною системою. Якщо статус показує щось інше, ніж дефіс або нуль, щось пішло не так.

Я не знаю, як mDNSResponderHelperвзаємодіє mDNSResponder; Мені потрібно було тільки перезавантажуватися mDNSResponder.



0

Примітка щодо назв OSX може бути нестандартною, тому для повноти:

  • FQDN є pingable
  • імена в файлах "hosts" є pingable

Імена Mac не є загалом: необхідно виконати дві виправлення: a) змінити пробіли на "-" b) додати .local

так, наприклад, MacBook Pro від Mac: ingconti

буде розміщено на сайті: ingcontis-MacBook-Pro.local

І відкриваючи префи, можна побачити:

введіть опис зображення тут

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.