Hva er mDNSResponder på Mac? Bonjour, DNS og høyt nettverksforbruk forklart

mDNSResponder er en systemdaemon innebygd i macOS og signert av Apple. Det er ikke skadevare, ikke et tillegg og ikke noe du har installert: den følger med operativsystemet og starter automatisk.

Den utfører to ulike oppgaver, og å blande dem er kilden til det meste av forvirringen rundt den. Den første er multicast DNS og tjenesteoppdagelse: dette er Apples Bonjour, teknologien som lar Mac-en din finne skrivere, AirPlay-mottakere, Chromecasts, delte stasjoner, HomeKit-tilbehør og andre Mac-er på det lokale nettverket uten noen manuell konfigurasjon. Denne trafikken sendes til en multicast-adresse på UDP-port 5353, som er standard mDNS-port.

Den andre oppgaven er den de fleste forklaringer hopper over: i macOS er mDNSResponder også den systemomfattende DNS-oppløseren. Når en hvilken som helst app på Mac-en din trenger å gjøre om et vertsnavn til en IP-adresse, håndteres forespørselen vanligvis av mDNSResponder på appens vegne i stedet for av appen selv.

Begge oppgavene kjører i samme prosess. Så når du ser mDNSResponder opptatt, ser du det samlede resultatet av lokal nettverksoppdagelse og hvert navneoppslag Mac-en din utfører.

Dette er delen som alarmerer folk, og det har en hverdagslig forklaring. Fordi mDNSResponder løser navn på vegne av andre prosesser, ser nesten alle DNS-oppslagene på Macen din ut til å komme fra mDNSResponder, ikke fra appen som faktisk ville ha adressen.

Nettleseren din laster inn en side med et dusin tredjepartsressurser, e-postklienten sjekker kontoer, en bakgrunnsoppdaterer kjører, en chat-app kobler til på nytt: ingen av disse vises som seg selv i en DNS-visning. De vises som mDNSResponder som snakker med DNS-serverne du har konfigurert. Utenfra ser det ut som om én prosess er interessert i en enorm og stadig skiftende liste over domener.

Det ene faktumet forklarer det meste av mistanken. At du ser mDNSResponder kontakte mange verter betyr ikke at mDNSResponder gjør noe mistenkelig. Den er en mellommann. Aktiviteten tilhører programvaren som ba om oppslaget, mDNSResponder er bare komponenten som utfører det.

Det forklarer også hvorfor prosessen sjelden blir stille. En moderne Mac har en jevn bakgrunnsbrumming av programvare som sjekker inn, synkroniseringstjenester, push-varsler, oppdateringssjekker, telemetri fra apper du har installert. Alle disse trenger navneoppslag først, og alt går gjennom samme daemon.

mDNSResponder er en legitim del av macOS. Det finnes ingen reell historikk for at den har vært et skalkeskjul for noe ondsinnet, og på en Mac som fungerer normalt, bør du forvente å se nøyaktig én instans av den kjørende.

Du trenger ikke å ta det på tro. I Activity Monitor velger du prosessen og åpner inspektøren for å se detaljene, inkludert stien til den kjørbare filen den ble startet fra. Apples systemdemoner ligger i beskyttede systemkataloger, ikke i hjemmemappen din, Nedlastinger eller Programmer. En prosess som bruker navnet mDNSResponder, men kjører fra et uvanlig sted, er verdt å undersøke, selve navnet er ikke bevis på noe.

Den sterkere kontrollen er kodesignaturen. macOS leveres med verktøyet codesign, og kjører du en verifisering mot stien til den kjørende binærfilen, vil du se signeringsinstansen. Apples egne systemkomponenter er signert av Apple. I nyere versjoner av macOS ligger systemfilene også på et forseglet, skrivebeskyttet systemvolum, noe som gjør det betydelig vanskeligere å tukle med den ekte binærfilen enn det var før.

En siste kontroll for å berolige deg: høy aktivitet fra mDNSResponder er normalt, men vedvarende høy CPU-bruk i timevis er det ikke. Det er som regel et symptom på noe annet på nettverket ditt eller på Macen din, og det er det neste avsnittet tar for seg.

Når mDNSResponder faktisk oppfører seg dårlig, er årsaken nesten alltid ekstern. De vanlige mistenkte er et travelt локalt nettverk med mye Bonjour-prat, en skriver eller NAS som annonserer seg aggressivt, VPN eller tredjeparts DNS-programvare som krasjer med systemløseren, captive portal-sjekking på et hotell- eller kafénettverk, eller en enkelt app på Macen din som gjør oppslag i en stram løkke.

Arbeid deg gjennom det i rekkefølge etter innsats. Først slår du Wi-Fi av og på, eller kobler fra nettverket et øyeblikk, dette rydder overraskende mange midlertidige tilstander. Hvis det ikke hjelper, starter du på nytt, en omstart tilbakestiller daemonen sammen med alt som mater den. Hvis problemet bare oppstår på ett nettverk, er nettverket variabelen, ikke Macen din, prøv et annet for å bekrefte det, og se deretter på hva som annonserer seg der. Hvis du nylig har installert en VPN-klient, et DNS-filtreringsverktøy eller noe annet som installerer en nettverksutvidelse, vil det å deaktivere det midlertidig fortelle deg raskt om det er utløseren. Hvis problemet følger deg på tvers av nettverk og overlever en omstart, mistenker du en bestemt app og begynner med å avslutte nylig installerte eller nylig oppdaterte apper én etter én.

Det du ikke bør gjøre, er å blokkere den. Aldri blokker mDNSResponder i en brannmur. Fordi den er systemets globale løser, stopper blokkering navneoppløsning for hele Macen, nettlesere, Mail, App Store, programvareoppdateringer og alt annet som berører nettverket vil feile, som regel med forvirrende feil som ikke peker tilbake til brannmurregelen du la til. Det er en av de få prosessene der blokkering gjør langt mer skade enn trafikken den var ment å stoppe.

Hvis det egentlige målet ditt er mindre støy på lokalnettet, bør du målrette funksjonene i stedet for løseren. Å slå av AirPlay-mottaker, skriverdeling, fildeling og andre Bonjour-avhengige tjenester du ikke bruker, reduserer det Macen din annonserer og lytter etter, uten å ødelegge DNS. Det er riktig grep.

Konsekvensen av sentralisert navneoppløsning er et attribusjonsproblem. Hvis du overvåker tilkoblinger på systemnivå, vil en stor del av den interessante DNS-aktiviteten være merket mDNSResponder, og du kan ikke ut fra den etiketten alene vite om domenet ble bedt om av nettleseren din, en bakgrunnsoppdaterer eller en app som stille ringer hjem.

For å svare på det trenger du et verktøy som overvåker tilkoblinger per prosess og mapper aktiviteten tilbake til den opprinnelige appen, ikke til den daemonen som utførte oppslaget. Det er gapet NetMute er laget for å lukke, det viser trafikk i sanntid per app og per prosess, og holder domenelogger per app, hvilke domener en applikasjon kontaktet, når, og hvor mye data som ble overført. I stedet for én travel daemon får du et per-app-bilde av hva Macen din faktisk snakker med.

Derfra er responsen målrettet. NetMutes per-app-brannmur lar deg blokkere en bestemt applikasjon med ett klikk, eller bruke en midlertidig regel som utløper av seg selv når du bare vil dempe noe en stund. Nettverksprofiler lar regler variere mellom hjem, kontor og upålitelige nettverk, og Tracker Shield dekker en liste med over 1 100 kjente tracker-domener. Ingenting av dette innebærer å forstyrre mDNSResponder selv, du lar løseren være i fred og handler på appen som genererte forespørslene, som er den eneste løsningen som ikke ødelegger resten av Macen din.