Where to find DNS settings in MacOS
Hello!
Recently, I faced the task of debugging the resolv process of DNS names 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. Bonjour is used when you take out your iPhone and are looking for an Apple TV or printer.
At Bonjour open source, and mDNSResponder respectively , too . 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 the Responder abuses.- software for attacks in 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 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 resolv process of DNS names 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. Bonjour is used when you take out your iPhone and are looking for an Apple TV or printer.
At Bonjour open source, and mDNSResponder respectively , too . 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 the Responder abuses.- software for attacks in 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 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.255Statistics 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 0List 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 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.73List 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 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