Привет!
Недавно передо мной встала задача отладить процесс резолва DNS имен в MacOS. Полноценного материала, о том как именно он происходит, я не нашел, пришлось собирать информацию самому.
Вот что удалось выяснить.
За задачи, связанные с DNS в macOS, отвечает демон по имени mDNSResponder. В его жизни встречались приключения — на его смену приходил демон discoveryd (Yosemite), который много что поломал и создал кучу проблем. Через год Apple опомнилась и вернула (El Capitan) проверенный mDNSResponder, что сразу починило около 300 багов и вернуло стабильность.
mDNSResponder является частью Bonjour — набора технологий нацеленных на работу устройства в сети без необходимости конфигурации, включает в себя поиск сервисов, автоназначение адреса и резолв имен. Именно Bonjour используется когда вы достаете свой iPhone и ищете Apple TV или принтер.
У Bonjour открытый исходный код, и у mDNSResponder соответственно тоже. Это упрощает задачу, если вам нужно докопаться до конечной истины и показать все что скрыто. В архиве уже есть готовые реализации под Windows, Posix и VxWorks.
Демон обрабатывает unicastDNS и multicastDNS. UnicastDNS — это обычный DNS к которому мы привыкли и знаем. MulticastDNS — это протокол для использования DNS в локальных сетях, не требующий сервера. Если устройству нужно кого-то найти — оно отправляет вопрос — «question» мультикаст пакетом и получает ответ от устройства с запрошенным именем (если оно конечно существует). Сам протокол подробно описан в одноименном RFC.
Именно особенностями MulticastDNS злоупотребляет Responder — софт для атак в локальной сети. После запуска он коварно начинает отвечать на все mDNS запросы, заманивая ничего не подозревающих жертв в свои лапы.
Это было лирическое отступление — а теперь к главному вопросу — как увидеть текущий DNS кеш и общий статус DNS настроек.
Итак, выполняем следующие шаги:
Статус DNS настроек представляет из себя большое полотно, разделенное на секции. Наиболее интересные из них:
Cache — здесь непосредственно хранится DNS cache:
Содержимое файла /etc/hosts — на всякий случай:
Статистика по mDNS — дубликаты имен, количество пакетов, события интерфейсов:
Список сетевых интерфейсов:
Список DNS серверов:
Мир внутренних и внешних взаимодействий подсистем MacOS обширен и полон загадок. Работа с доменными именами — лишь его маленькая часть. Для дальнейшего чтения рекомендую:
Недавно передо мной встала задача отладить процесс резолва DNS имен в MacOS. Полноценного материала, о том как именно он происходит, я не нашел, пришлось собирать информацию самому.
Вот что удалось выяснить.
За задачи, связанные с DNS в macOS, отвечает демон по имени mDNSResponder. В его жизни встречались приключения — на его смену приходил демон discoveryd (Yosemite), который много что поломал и создал кучу проблем. Через год Apple опомнилась и вернула (El Capitan) проверенный mDNSResponder, что сразу починило около 300 багов и вернуло стабильность.
mDNSResponder является частью Bonjour — набора технологий нацеленных на работу устройства в сети без необходимости конфигурации, включает в себя поиск сервисов, автоназначение адреса и резолв имен. Именно Bonjour используется когда вы достаете свой iPhone и ищете Apple TV или принтер.
У Bonjour открытый исходный код, и у mDNSResponder соответственно тоже. Это упрощает задачу, если вам нужно докопаться до конечной истины и показать все что скрыто. В архиве уже есть готовые реализации под Windows, Posix и VxWorks.
Демон обрабатывает unicastDNS и multicastDNS. UnicastDNS — это обычный DNS к которому мы привыкли и знаем. MulticastDNS — это протокол для использования DNS в локальных сетях, не требующий сервера. Если устройству нужно кого-то найти — оно отправляет вопрос — «question» мультикаст пакетом и получает ответ от устройства с запрошенным именем (если оно конечно существует). Сам протокол подробно описан в одноименном RFC.
Именно особенностями MulticastDNS злоупотребляет Responder — софт для атак в локальной сети. После запуска он коварно начинает отвечать на все mDNS запросы, заманивая ничего не подозревающих жертв в свои лапы.
Это было лирическое отступление — а теперь к главному вопросу — как увидеть текущий DNS кеш и общий статус DNS настроек.
Итак, выполняем следующие шаги:
- В терминале пишем:
sudo log config --mode "private_data:on"
эта команда позволит нам увидеть вывод, иначе он будет спрятан под заглушкой private - Открываем console, выбираем наш девайс:
и в фильтре пишем mDNSResponder
- Выполняем в терминале:
sudo killall -INFO mDNSResponder
- Открываем обратно console и получаем прекрасный вывод, который мы сейчас немного разберем:
Статус DNS настроек представляет из себя большое полотно, разделенное на секции. Наиболее интересные из них:
Cache — здесь непосредственно хранится DNS cache:
------------ Cache -------------
Slt Q TTL if U Type rdlen
3 4290 en0 + PTR 33 _companion-link._tcp.local. PTR VMAC._companion-link._tcp.local.
3 4273 en0 + PTR 37 _companion-link._tcp.local. PTR VMAC\032(2)._companion-link._tcp.local.
6 107951 -U- - Addr 0 isafronov-G8WP. Addr
6 107951 -U- SOA 64 . SOA a.root-servers.net. nstld.verisign-grs.com. 2019011700 1800 900 604800 86400
6 107951 -U- - AAAA 0 isafronov-G8WP. AAAA
6 107951 -U- SOA 64 . SOA a.root-servers.net. nstld.verisign-grs.com. 2019011700 1800 900 604800 86400
9 763 -U- CNAME 37 1-courier.push.apple.com. CNAME 1.courier-push-apple.com.akadns.net.
13 8819 -U- CNAME 22 ax.itunes.apple.com.edgesuite.net. CNAME a1108.gi3.akamai.net.
Содержимое файла /etc/hosts — на всякий случай:
--------- /etc/hosts ---------
State Interface
KnownUnique LO 4 localhost. Addr 127.0.0.1
KnownUnique LO 16 localhost. AAAA ::1
KnownUnique LO 4 vmware-localhost. Addr 127.0.0.1
KnownUnique LO 16 vmware-localhost. AAAA ::1
KnownUnique LO 4 broadcasthost. Addr 255.255.255.255
Статистика по mDNS — дубликаты имен, количество пакетов, события интерфейсов:
--- MDNS Statistics ---
Name Conflicts 0
KnownUnique Name Conflicts 0
Duplicate Query Suppressions 2045
KA Suppressions 0
KA Multiple Packets 0
Poof Cache Deletions 203
--------------------------------
Multicast packets Sent 8211
Multicast packets Received 22382
Remote Subnet packets 1
QU questions received 25960
Normal multicast questions 62197
Answers for questions 4259
Unicast responses 0
Multicast responses 0
Unicast response Demotions 0
--------------------------------
Sleeps 181
Wakeups 182
Interface UP events 665
Interface UP Flap events 48
Interface Down events 817
Interface DownFlap events 16
Cache refresh queries 2876
Cache refreshed 28935
Wakeup on Resolves 0
Список сетевых интерфейсов:
------ Network Interfaces ------
Struct addr Registered MAC BSSID Interface Address
00007FA2FD834E00 11, 00007FA2FD834E00, v6 utun0 00:00:00:00:00:00 00:00:00:00:00:00 Active A fe80::ebfb:c666:8f7b:62ed
00007FA2FF01B800 9, 00007FA2FF01B800, v6 awdl0 DE:14:B1:E7:21:33 00:00:00:00:00:00 Active v6 A M fe80::dc14:b1ff:fee7:2133
00007FA2FD829C00 7, 0000000000000000, v4 en0 F4:5C:89:8E:9D:C1 E4:8D:8C:61:7F:5D 192.168.1.73 dormant for 1943 seconds
00007FA2FD00C200 13, 00007FA2FD00C200, v4 en5 42:4D:7F:A3:50:1B 00:00:00:00:00:00 Active v4 A M 169.254.150.120
00007FA2FE008C00 7, 00007FA2FE008C00, v4 en0 F4:5C:89:8E:9D:C1 E4:8D:8C:61:7F:5C Active v4 A M p 192.168.1.73
Список DNS серверов:
--------- DNS Servers(2) ----------
DNS Server . en0 127.0.0.1:53 0 Unscoped 30 18283 v4 v6 !cell !exp !clat46 !DNSSECAware
DNS Server . en0 127.0.0.1:53 0 InterfaceScoped 30 18291 v4 v6 !cell !exp !clat46 !DNSSECAware
v4answers 1
v6answers 1
Last DNS Trigger: 140697 ms ago
Мир внутренних и внешних взаимодействий подсистем MacOS обширен и полон загадок. Работа с доменными именами — лишь его маленькая часть. Для дальнейшего чтения рекомендую:
- Официальную документацию Apple
- Блог malware исследователя и *OS энтузиаста Patrick Wardle
- Сайт и книги исследователя и практика *OS Johnatan Levin
Комментарии (12)
tea
17.01.2019 22:08А может кто-то скажет почему Safari не работает с proxy.pac? Все работают, Safari нет.
К слову proxy.pac локальный файл, в Safari открытие локальных файлов разрешено.dartraiden
20.01.2019 15:31Я встречал только сведения о том, что он не понимает dhcp-option=252 (которая указывает путь к файлу автонастройки прокси).
Valsha
18.01.2019 11:06А MacBook передает вообще имя пользователя (как названа учетная запись на ноутбуке) куда то в сеть? То есть может кто то помимо меня увидеть что на моем маке есть юзер с именем XYZ (к примеру)?
NickSin
18.01.2019 15:29Насколько я видел, он передает в сеть только имя текущего пользователя в сессии. Посмотреть всех пользователей, учетки которых есть в маке — нелья.
andrew8712
Ни у кого не было такой проблемы: имя хоста на MacBook Pro 2018 самопроизвольно инкрементируется. Сначала было Andrey-MacBook-Pro.local, потом Andrey-MacBook-Pro-2.local, потом Andrey-MacBook-Pro-3.local и т.п. Похоже, Bonjour косячит, но вот как исправить — не знаю :-/
aleshkashell
Скорее всего мак переименован не во всех местах. Сделай у себя
hostname=«Andrey-MacBook-Pro.local»
scutil --set ComputerName $hostname && scutil --set LocalHostName $hostname && scutil --set HostName $hostname
andrew8712
Вроде делал уже, не помогло. Сделал на всякий случай еще раз. Только hostname нужно без `local` писать: «Andrey-MacBook-Pro»
Vitalley
Было совсем недавно такое
toor
Похожая проблема, причем возникает только в рабочем wi-fi. Если найдете решение можете написать?
andrew8712
Решение выше помогло. С 17 января имя хоста не менялось
IGHOR
Должно переименовываться только если в локальной сети это имя уже занято.
vadimr
Бывает. У меня сложилось впечатление, что эти имена как-то кеширует соседний линукс с самбой. Но это не точно ©.