Where to find DNS settings in MacOS
Hello!
Recently, I faced the task of debugging the DNS resolver resolving process in MacOS. I did not find a full-fledged material on how exactly it happens, I had to collect information myself.
Here is what was found out.
For tasks related to DNS in macOS, is responsible for the daemon named mDNSResponder. There were adventures in his life - a demon discoveryd (Yosemite) came to replace him, who broke a lot and created a lot of problems. A year later, Apple came to its senses and returned (El Capitan) a proven mDNSResponder, which immediately fixed about 300 bugs and returned stability.
mDNSResponder is part of Bonjour , a set of technologies aimed at operating a device on a network without the need for configuration, includes searching for services, auto-assigning addresses and resolving names. It is Bonjour that is used when you take out your iPhone and are looking for an Apple TV or printer.
Bonjour is open source, and mDNSResponder respectively. This simplifies the task if you need to get to the ultimate truth and show all that is hidden. The archive already has ready-made implementations for Windows, Posix and VxWorks.
The daemon processes unicastDNS and multicastDNS. UnicastDNS is the usual DNS to which we are used and know. MulticastDNS is a protocol for using DNS in local networks that does not require a server. If the device needs someone to find - it sends the question - a “question” multicast package and receives an answer from the device with the requested name (if it exists of course). The protocol itself is described in detail in the RFC of the same name.
It is the features MulticastDNS that is abused by the Responder - software for attacks on the local network. After launch, he insidiously begins to respond to all mDNS requests, luring unsuspecting victims into his paws.
It was a digression - and now to the main question - how to see the current DNS cache and the general status of the DNS settings.
So, perform the following steps:
The status of the DNS settings is a large canvas, divided into sections. The most interesting of them are:
Cache - DNS cache is directly stored here:
The contents of the / etc / hosts file - just in case:
Statistics on mDNS - duplicate names, number of packets, interface events:
List of network interfaces:
List of DNS servers:
The world of internal and external interactions of the MacOS subsystems is vast and full of mysteries. Working with domain names is only a small part of it. For further reading, I recommend:
Recently, I faced the task of debugging the DNS resolver resolving process in MacOS. I did not find a full-fledged material on how exactly it happens, I had to collect information myself.
Here is what was found out.
For tasks related to DNS in macOS, is responsible for the daemon named mDNSResponder. There were adventures in his life - a demon discoveryd (Yosemite) came to replace him, who broke a lot and created a lot of problems. A year later, Apple came to its senses and returned (El Capitan) a proven mDNSResponder, which immediately fixed about 300 bugs and returned stability.
mDNSResponder is part of Bonjour , a set of technologies aimed at operating a device on a network without the need for configuration, includes searching for services, auto-assigning addresses and resolving names. It is Bonjour that is used when you take out your iPhone and are looking for an Apple TV or printer.
Bonjour is open source, and mDNSResponder respectively. This simplifies the task if you need to get to the ultimate truth and show all that is hidden. The archive already has ready-made implementations for Windows, Posix and VxWorks.
The daemon processes unicastDNS and multicastDNS. UnicastDNS is the usual DNS to which we are used and know. MulticastDNS is a protocol for using DNS in local networks that does not require a server. If the device needs someone to find - it sends the question - a “question” multicast package and receives an answer from the device with the requested name (if it exists of course). The protocol itself is described in detail in the RFC of the same name.
It is the features MulticastDNS that is abused by the Responder - software for attacks on the local network. After launch, he insidiously begins to respond to all mDNS requests, luring unsuspecting victims into his paws.
It was a digression - and now to the main question - how to see the current DNS cache and the general status of the DNS settings.
So, perform the following steps:
- In the terminal we write:
sudo log config --mode "private_data:on"
this command will allow us to see the output, otherwise it will be hidden under a private stub - Open the console, choose our device:
and in the filter we write mDNSResponder
- Perform in the terminal:
sudo killall -INFO mDNSResponder - Open the console back and get a great conclusion, which we now analyze a little:
The status of the DNS settings is a large canvas, divided into sections. The most interesting of them are:
Cache - DNS cache is directly stored here:
------------ 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. The contents of the / etc / hosts file - just in case:
--------- /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 Statistics on mDNS - duplicate names, number of packets, interface events:
--- 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 List of network interfaces:
------ 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 AM 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 AM 169.254.150.120 00007FA2FE008C00 7, 00007FA2FE008C00, v4 en0 F4:5C:89:8E:9D:C1 E4:8D:8C:61:7F:5C Active v4 AM p 192.168.1.73 List of DNS servers:
--------- 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 The world of internal and external interactions of the MacOS subsystems is vast and full of mysteries. Working with domain names is only a small part of it. For further reading, I recommend:
- Apple official documentation
- The blog of a malware researcher and * OS enthusiast Patrick Wardle
- The site and books of the researcher and practice * OS Johnatan Levin
Source: https://habr.com/ru/post/436484/