Wat is mDNSResponder op Mac? Bonjour, DNS en hoog netwerkgebruik uitgelegd

mDNSResponder is een systeemdaemon ingebouwd in macOS en ondertekend door Apple. Het is geen malware, geen add-on en niet iets dat je hebt geïnstalleerd — het wordt meegeleverd met het besturingssysteem en start automatisch.

Het voert twee verschillende taken uit, en het verwarren ervan 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 uitleggen overslaan: op macOS is mDNSResponder ook de systeemwijde DNS-oplosser. Wanneer een applicatie op je Mac een hostnaam moet omzetten in een IP-adres, wordt het verzoek 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.

Dit is het deel dat mensen alarmeert, en het heeft een eenvoudige verklaring. Omdat mDNSResponder namen oplost namens andere processen, lijken bijna alle DNS-opzoekingen van je Mac afkomstig te zijn van mDNSResponder in plaats van van de app die daadwerkelijk het adres wilde.

Je browser die een pagina laadt met een stuk of twaalf resources van derden, je mailclient die accounts controleert, een achtergrondupdate, een chatapp die opnieuw verbinding maakt — geen van deze verschijnt als zichzelf in een DNS-overzicht. Ze verschijnen als mDNSResponder die contact opneemt met je geconfigureerde DNS-servers. Van buitenaf lijkt één proces geïnteresseerd te zijn in een enorme en voortdurend veranderende lijst van domeinen.

Dat enkele feit beantwoordt het grootste deel van de verdenking. Het zien dat mDNSResponder contact opneemt met veel hosts betekent niet dat mDNSResponder iets verdachts doet. Het is een proxy. De activiteit behoort toe aan de software die om de lookup heeft gevraagd; mDNSResponder is slechts de component die het uitvoert.

Het verklaart ook waarom het proces zelden stil wordt. Een moderne Mac heeft een constante achtergrondgeluid van software die controleert — synchronisatieservices, pushmeldingen, updatecontroles, telemetrie van apps die je hebt geïnstalleerd. Al deze activiteiten vereisen eerst naamresolutie, en alles stroomt door hetzelfde daemon.

mDNSResponder is een legitiem onderdeel van macOS. Er is geen betekenisvolle geschiedenis dat het een vermomming is voor iets kwaadaardigs, en op een normaal functionerende Mac zou je precies één instantie ervan moeten zien draaien.

Je hoeft dat niet op dat vertrouwen te doen. In Activity Monitor selecteer je het proces en open je de inspector om de details te bekijken, inclusief het pad naar de executable waarmee het is gestart. Apple's systeem daemons bevinden zich in beschermde systeembestanden, niet in je thuismap, Downloads of Applications. Een proces met de naam mDNSResponder dat vanaf een ongebruikelijke locatie draait, zou het waard zijn om te onderzoeken — de naam zelf is geen bewijs van iets.

De sterkere controle is de codehandtekening. macOS wordt geleverd met het codesign-gereedschap, en het uitvoeren van een verificatie tegen het pad van de lopende binary toont je de ondertekeningsautoriteit. Apple's eigen systeemcomponenten worden ondertekend door Apple. Op recente versies van macOS bevinden systeembestanden zich ook op een verzegeld, alleen-lezen systeemvolume, wat het tamperen met de echte binary aanzienlijk moeilijker maakt dan vroeger.

Nog een sanity check: hoge activiteit van mDNSResponder is normaal, maar langdurig hoge CPU-gebruik over uren is dat niet. Dat is meestal een symptoom van iets anders op je netwerk of op je Mac, wat het volgende gedeelte behandelt.

Wanneer mDNSResponder echt slecht functioneert, ligt de oorzaak bijna altijd buiten het. De gebruikelijke verdachten: een druk lokaal netwerk met veel Bonjour-verkeer, een printer of NAS die zichzelf agressief adverteert, VPN of software van derden die conflicteert met de systeemresolver, captive-portal probing op een hotel- of café-netwerk, of een enkele app op je Mac die in een strakke lus zoekt.

Werk het in volgorde van inspanning. Zet eerst Wi‑Fi uit en weer aan, of verbreek de verbinding kort — dit lost een verrassend aantal tijdelijke toestanden op. Als dat niet helpt, herstart; een herstart zet de daemon terug samen met alles wat eromheen draait. Als het probleem alleen op één netwerk voorkomt, is dat het variabele element, niet je Mac: probeer een ander netwerk om te bevestigen en kijk wat zich daar adverteert. Als je onlangs een VPN‑client, een DNS‑filtertool of iets anders hebt geïnstalleerd dat een netwerkextensie toevoegt, schakel dat dan tijdelijk uit om snel te zien of dat de trigger is. Als het probleem je over netwerken heen volgt en een herstart overleeft, 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 het blokkeren ervan de naamresolutie voor de hele Mac — browsers, Mail, de App Store, software‑updates en vrijwel alles wat het netwerk gebruikt zal falen, 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 zou moeten stoppen.

Als je daadwerkelijke doel minder lokaal netwerkverkeer is, richt je je op de functies in plaats van op de resolver. Schakel bijvoorbeeld AirPlay‑ontvanger, printerdeling, bestandsdeling en andere Bonjour‑afhankelijke services uit die je niet gebruikt, zodat je Mac minder adverteert en luistert, zonder DNS te breken. Dat is de juiste aanpak.

Het gevolg van gecentraliseerde resolutie is een toeschrijvingsprobleem. Als je verbindingen op systeemniveau bekijkt, wordt een groot deel van het interessante DNS-verkeer gelabeld als mDNSResponder, en kun je uit dat label niet afleiden of het domein werd aangevraagd door je browser, een achtergrondupdate of een app die stilletjes thuisbelt.

Daarvoor heb je een tool nodig die verbindingen per proces bewaakt en activiteit terugkoppelt naar de oorspronkelijke app in plaats van naar de daemon die de lookup uitvoerde. Dat is de kloof die NetMute wil dichten: het toont realtime verkeer per app en per proces, en houdt domeinniveau-logs bij per app — welke domeinen een applicatie heeft benaderd, wanneer, en hoeveel data er is overgedragen. In plaats van één drukke daemon krijg je een per-app beeld van wat je Mac daadwerkelijk communiceert.

Van daaruit is de reactie gericht. NetMute's per-app firewall laat je een specifieke app met één klik blokkeren, of een zelf-vervalende tijdelijke regel toepassen wanneer je alleen iets voor een korte tijd 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 interfereert met mDNSResponder zelf — je laat de resolver met rust en handelt op de app die de verzoeken genereerde, wat de enige aanpak is die de rest van je Mac niet breekt.