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

mDNSResponder er en systemdæmon som er innebygd i macOS og signert av Apple. Det er ikke skadelig programvare, ikke et tillegg, og ikke noe du har installert — det følger med operativsystemet og starter automatisk.

Det utfører to distinkte oppgaver, og å forvirre dem er kilden til mesteparten av forvirringen rundt det. 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 manuell konfigurasjon. Denne trafikken sendes til en multicast-adresse på UDP-port 5353, som er standard mDNS-port.

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

Begge oppgavene kjører i samme prosess. Så når du ser mDNSResponder opptatt, ser du den samlede effekten av lokal nettverksoppdagelse og hver navneoppløsning Mac-en din utfører.

Dette er delen som skremmer folk, og det har en enkel forklaring. Fordi mDNSResponder løser navn på vegne av andre prosesser, ser det ut til at alle DNS-oppløsningene på Mac-en din stammer fra mDNSResponder i stedet for fra appen som faktisk ønsket adressen.

Din nettleser laster en side med et dusin tredjepartsressurser, e-postklienten din sjekker kontoer, en bakgrunnsoppdatering kjører, en chat-app kobler til igjen — ingen av disse vises som seg selv i en DNS-visning. De vises som mDNSResponder som snakker med dine konfigurerte DNS-servere. Utenfra ser det ut som om én prosess er interessert i en enorm og stadig skiftende liste over domener.

Dette ene faktumet forklarer mesteparten av mistilliten. Å se mDNSResponder kontakte mange verter betyr ikke at mDNSResponder gjør noe mistenkelig. Det er en proxy. Aktiviteten tilhører den programvaren som spurte om oppslaget; mDNSResponder er bare komponenten som utfører det.

Det forklarer også hvorfor prosessen sjelden blir stille. En moderne Mac har en jevn bakgrunnslyd av programvare som sjekker inn — synkroniseringstjenester, push-varsler, oppdateringssjekker, telemetri fra apper du har installert. Hver av disse trenger først navneoppløsning, og alt går gjennom den samme dæmonen.

mDNSResponder er en legitim del av macOS. Det finnes ingen meningsfull historikk for at det har blitt brukt som forkledning for noe ondsinnet, og på en normalt fungerende Mac bør du forvente å se nøyaktig én forekomst av den som kjører.

Du trenger ikke å ta det for god fisk. I Activity Monitor, velg prosessen og åpne inspektøren for å se detaljene, inkludert stien til kjørbar filen den ble startet fra. Apples systemdemoner ligger inne i beskyttede systemkataloger, ikke i hjemmemappen din, Nedlastinger eller Programmer. En prosess med navnet mDNSResponder som kjører fra et uvanlig sted, vil være noe verdt å undersøke — selve navnet er ikke bevis på noe.

Den sterkere sjekken er kodesignaturen. macOS leveres med verktøyet codesign, og å kjøre en verifikasjon mot den kjørende binærens sti vil vise deg signeringsmyndigheten. Apples egne systemkomponenter er signert av Apple. På nyere versjoner av macOS ligger systemfilene også på et forseglet, skrivebeskyttet systemvolum, noe som gjør det betydelig vanskeligere å tukle med den ekte binæren enn det var før.

En siste sjekk for å få ro i sjelen: høy aktivitet fra mDNSResponder er normalt, men vedvarende høy CPU-bruk over timer er det ikke. Det er vanligvis et symptom på noe annet på nettverket ditt eller på Macen din, noe som de neste avsnittene dekker.

Når mDNSResponder virkelig oppfører seg rart, er årsaken nesten alltid ekstern for den. De vanlige mistenkte: et travelt lokalt nettverk med mye Bonjour-trafikk, en skriver eller NAS som annonserer seg aggressivt, VPN eller tredjeparts DNS-programvare som konflikter med systemløseren, captive-portal-sjekk på et hotell- eller kafé-nettverk, eller en enkelt app på Macen din som utfører oppslag i en tett løkke.

Arbeid deg gjennom det i rekkefølge etter innsats. Først, slå Wi-Fi av og på, eller koble fra nettverket kort — dette rydder opp i et overraskende antall midlertidige tilstander. Hvis det ikke hjelper, start på nytt; en omstart tilbakestiller dæmonen sammen med alt den får data fra. Hvis problemet bare oppstår på ett nettverk, er det nettverket som er variabelen, ikke Macen din: prøv et annet for å bekrefte, og se 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 midlertidig å deaktivere det fortelle deg raskt om det er utløseren. Hvis problemet følger deg på tvers av nettverk og overlever en omstart, mistenk en spesifikk applikasjon og start med å avslutte nylig installerte eller nylig oppdaterte apper én etter én.

Det du ikke bør gjøre er å blokkere det. Aldri blokkér mDNSResponder i en brannmur. Fordi det er systemomfattende løseren, vil blokkering stoppe navneoppløsning for hele Macen — nettlesere, Mail, App Store, programvareoppdateringer, og alt annet som berører nettverket vil feile, vanligvis med forvirrende feil som ikke peker tilbake på brannmurregelen du la til. Det er ett av få prosesser hvor blokkering forårsaker langt mer skade enn trafikken den var ment å stoppe.

Hvis målet ditt er mindre lokalnettverk-trafikk, bør du heller målrette funksjonene i stedet for løseren. Å slå av AirPlay-mottaker, skriverdeling, fil-deling, og andre Bonjour-avhengige tjenester du ikke bruker, reduserer hva Macen din annonserer og lytter etter, uten å bryte DNS. Det er den riktige tilnærmingen.

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

Svar på det krever et verktøy som overvåker tilkoblinger per prosess og kartlegger aktivitet tilbake til den opprinnelige appen i stedet for til hvilken dæmon som utførte oppslaget. Det er gapet NetMute er bygget for å lukke: det viser sanntidstrafikk per app og per prosess, og holder domenenivålogger per app — hvilke domener en applikasjon kontaktet, når, og hvor mye data som ble overført. I stedet for en enkelt travel dæmon, får du et per-app-bilde av hva Macen din faktisk snakker med.

Derfra er svaret målrettet. NetMute's per-app brannmur lar deg blokkere en spesifikk applikasjon med ett klikk, eller bruke en selvutløsende midlertidig regel når du bare vil tie noe i en periode. Nettverksprofiler lar regler variere mellom hjem, kontor, og uautoriserte nettverk, og Tracker Shield dekker en liste over over 1 100 kjente tracker-domener. Ingen av disse involverer å forstyrre mDNSResponder — du lar løseren være i fred og handler på appen som genererte forespørslene, noe som er den eneste løsningen som ikke bryter resten av Macen din.