NetMuteWat mDNSResponder eigenlijk is
mDNSResponder is een systeemdaemon die is ingebouwd in macOS en is ondertekend door Apple. Het is geen malware, geen add-on en niets wat je zelf hebt geïnstalleerd. Het wordt meegeleverd met het besturingssysteem en start automatisch.
Het voert twee verschillende taken uit, en het verwarren daarvan is de bron van de meeste verwarring eromheen. De eerste is multicast DNS en service discovery: dit is Apple's Bonjour, de technologie waarmee je Mac printers, AirPlay-ontvangers, Chromecasts, gedeelde schijven, HomeKit-accessoires en andere Macs op je lokale netwerk kan vinden zonder handmatige configuratie. Dit verkeer wordt verzonden naar een multicast-adres op UDP-poort 5353, de standaard mDNS-poort.
De tweede taak is degene die de meeste uitleg overslaan: op macOS is mDNSResponder ook de systeemwijde DNS-resolver. Wanneer een applicatie op je Mac een hostnaam moet omzetten naar een IP-adres, wordt de aanvraag meestal afgehandeld door mDNSResponder namens die app, in plaats van door de app zelf.
Beide taken draaien binnen hetzelfde proces. Dus wanneer je mDNSResponder druk ziet, kijk je naar het gecombineerde resultaat van lokale netwerkontdekking en elke naamopzoeking die je Mac uitvoert.
Waarom het lijkt alsof het contact opneemt met zoveel hosts
Dit is het deel dat mensen alarmeert, en er is een gewone verklaring voor. Omdat mDNSResponder namen oplost namens andere processen, lijkt het alsof bijna alle DNS-opzoekingen van je Mac afkomstig zijn van mDNSResponder in plaats van van de app die het adres eigenlijk wilde.
Je browser die een pagina laadt met een dozijn bronnen van derden, je mailclient die accounts controleert, een achtergrondupdater, een chatapp die opnieuw verbinding maakt, geen van die zaken verschijnt als zichzelf in een DNS-overzicht. Ze verschijnen als mDNSResponder die praat met je geconfigureerde DNS-servers. Van buitenaf lijkt één proces geïnteresseerd te zijn in een enorme en voortdurend veranderende lijst van domeinen.
Dat ene feit verklaart het grootste deel van de verdenking. Dat je mDNSResponder met veel hosts ziet praten betekent niet dat mDNSResponder iets verdachts doet. Het is een proxy. De activiteit hoort bij de software die om de lookup vroeg; mDNSResponder is alleen het onderdeel dat die uitvoert.
Het verklaart ook waarom het proces zelden stilvalt. Een moderne Mac heeft een gestage achtergrondzoem van software die incheckt: synchronisatieservices, pushmeldingen, updatecontroles, telemetrie van apps die je hebt geïnstalleerd. Al die zaken hebben eerst naamresolutie nodig, en alles loopt via dezelfde daemon.
Is mDNSResponder veilig, en hoe kun je dat zelf controleren
mDNSResponder is een legitiem onderdeel van macOS. Er is geen noemenswaardige geschiedenis van dit proces als vermomming voor iets kwaadaardigs, en op een normaal werkende Mac zou je precies één instantie ervan moeten zien draaien.
Je hoeft dat niet zomaar aan te nemen. Selecteer in Activiteitenweergave het proces en open de infovenster om de details te zien, inclusief het pad naar het uitvoerbare bestand waarmee het is gestart. Apple's systeemdaemons staan in beschermde systeembestanden, niet in je thuismap, Downloads of Programma's. Een proces met de naam mDNSResponder dat vanaf een ongebruikelijke locatie draait, is iets om te onderzoeken, de naam zelf bewijst niets.
De sterkere controle is de code-ondertekening. macOS wordt geleverd met het hulpprogramma `codesign`, en als je een verificatie uitvoert op het pad van de lopende binary, zie je wie het heeft ondertekend. Apple's eigen systeemcomponenten zijn door Apple ondertekend. In recente macOS-versies staan systeembestanden ook op een verzegeld, alleen-lezen systeemvolume, waardoor knoeien met de echte binary veel lastiger is dan vroeger.
Nog een sanity check: hoge activiteit van mDNSResponder is normaal, maar langdurig hoge CPU-belasting gedurende uren is dat niet. Dat is meestal een symptoom van iets anders op je netwerk of op je Mac, en dat behandelt het volgende deel.
Oplossen van hoog CPU- of constant netwerkgebruik
Wanneer mDNSResponder echt ontspoort, ligt de oorzaak bijna altijd buiten het proces zelf. De gebruikelijke verdachten: een druk lokaal netwerk met veel Bonjour-verkeer, een printer of NAS die zich agressief meldt, VPN- of DNS-software van derden die botst met de systeemresolver, captive-portalcontrole op een hotel- of café-netwerk, of een enkele app op je Mac die in een strakke lus opzoekt.
Pak het aan in volgorde van moeite. Zet eerst wifi uit en weer aan, of verbreek de verbinding even, dit lost verrassend veel tijdelijke toestanden op. Helpt dat niet, herstart dan, een herstart zet de daemon en alles wat hem voedt opnieuw. Treedt het probleem alleen op één netwerk op, dan is dat netwerk de variabele, niet je Mac: probeer een ander netwerk om dat te bevestigen en kijk daarna wat daar zichzelf meldt. Heb je onlangs een VPN-client, een DNS-filtertool of iets anders geïnstalleerd dat een netwerkextensie toevoegt, schakel dat dan tijdelijk uit om snel te zien of dat de oorzaak is. Volgt het probleem je over netwerken heen en blijft het na een herstart bestaan, verdenk dan een specifieke app en begin met het afsluiten van recent geïnstalleerde of recent bijgewerkte apps, één voor één.
Wat je niet moet doen, is het blokkeren. Blokkeer mDNSResponder nooit in een firewall. Omdat het de systeem-brede resolver is, stopt blokkeren de naamresolutie voor de hele Mac, browsers, Mail, de App Store, software-updates en praktisch alles wat het netwerk aanraakt vallen dan uit, meestal met verwarrende fouten die niet terug te voeren zijn op de firewallregel die je hebt toegevoegd. Het is een van de weinige processen waarbij blokkeren veel meer schade veroorzaakt dan het verkeer dat het moest stoppen.
Als je echte doel minder lokaal netwerkverkeer is, richt je dan op de functies in plaats van op de resolver. Schakel AirPlay-ontvanger, printerdeling, bestandsdeling en andere Bonjour-afhankelijke services die je niet gebruikt uit, dan adverteert en luistert je Mac minder, zonder DNS te breken. Dat is de juiste knop.
Uitzoeken welke app daadwerkelijk een lookup heeft getriggerd
Het gevolg van gecentraliseerde resolutie is een toeschrijvingsprobleem. Als je verbindingen op systeemniveau volgt, wordt een groot deel van het interessante DNS-verkeer gelabeld als mDNSResponder, en je kunt alleen aan dat label niet zien of het domein is opgevraagd door je browser, een achtergrondupdater of een app die stilletjes naar huis belt.
Om dat te beantwoorden heb je een tool nodig die verbindingen per proces volgt en activiteit terugkoppelt naar de oorspronkelijke app in plaats van naar de daemon die de lookup uitvoerde. Dat is de kloof die NetMute is gebouwd om te dichten: het toont realtime verkeer per app en per proces, en houdt domeinlogboeken per app bij, dus welke domeinen een applicatie heeft aangeroepen, wanneer en hoeveel data er is verplaatst. In plaats van één drukke daemon krijg je een per-app beeld van wat je Mac echt aan het praten is.
Van daaruit is de reactie gericht. Met de per-app firewall van NetMute blokkeer je een specifieke applicatie met één klik, of pas je een tijdelijke regel toe die vanzelf vervalt als je iets alleen even wilt stilleggen. Netwerkprofielen laten regels verschillen tussen thuis, kantoor en onbetrouwbare netwerken, en Tracker Shield dekt een lijst van meer dan 1.100 bekende tracker-domeinen. Niets daarvan grijpt in op mDNSResponder zelf, je laat de resolver met rust en pakt de app aan die de verzoeken genereerde, en dat is de enige oplossing die de rest van je Mac niet breekt.
