Slik fikser du NXDOMAIN-feilen i Chrome

DNS_PROBE_FINISHED_NXDOMAIN betyr at DNS-oppslaget ble fullført med svaret NXDOMAIN: navnet finnes ikke. Det kan skyldes en skrivefeil eller lokal resolver, men hvis alle brukere får feilen, ligger årsaken ofte i domeneregistrering, delegering eller den aktive DNS-sonen.

Start med dette skillet:

Hvem får feilen?	Mest sannsynlig område	Første test
Bare én nettleser	sikker DNS, profil eller lokal tilstand	annen nettleser på samme enhet
Én enhet, flere nettlesere	enhetens DNS-cache, VPN eller innstilling	annen enhet på samme nett
Alle enheter på ett nettverk	ruter eller nettverkets resolver	mobilnett uten Wi-Fi
Én adresse feiler overalt	DNS-posten eller delegeringen	`dig +trace` og autoritativt oppslag
Flere underdomener feiler overalt	sone, navnetjenere eller registrering	NS-, SOA- og domenestatus

Ikke bytt navnetjenere, slett DNSSEC eller legg inn tilfeldige poster før du vet hvilket lag som gir NXDOMAIN.

Hvis du bare prøver å besøke siden

1. Kontroller hele adressen

Sjekk hvert ledd i vertsnavnet. www.eksempel.no, eksempel.no og butikk.eksempel.no er tre forskjellige DNS-navn. Én kan virke mens en annen mangler.

Fjern unødvendig tekst etter domenet når du tester:

https://www.eksempel.no/

En feil i stien etter skråstreken gir normalt HTTP-feil, ikke NXDOMAIN. En feil før første skråstrek etter https:// endrer derimot DNS-navnet.

2. Test en annen enhet og et annet nettverk

Bruk denne korte matrisen:

Samme adresse i en annen nettleser.
Samme adresse på en annen enhet på samme Wi-Fi.
Samme adresse på telefon over mobilnett, med Wi-Fi slått av.

Hvis bare ett lokalt miljø feiler, bør du ikke kontakte nettstedseieren og be om DNS-endringer ennå. Undersøk VPN, sikkerhetsprogram, foreldrekontroll, bedriftsfilter, ruter og valgt DNS-tjeneste.

Hvis adressen feiler på mobilnett og flere uavhengige resolvere, er det mer sannsynlig at domeneeieren må rette offentlig DNS.

3. Kontroller sikker DNS i Chrome

Chrome kan bruke en kryptert DNS-leverandør som er forskjellig fra operativsystemets resolver. Gå til:

Innstillinger → Personvern og sikkerhet → Sikkerhet → Bruk sikker DNS

Kontroller om en egendefinert leverandør er valgt. Test automatisk modus eller en annen kjent leverandør for å avgrense feilen. Ikke slå av sikker DNS permanent bare fordi ett domene er feilkonfigurert.

Googles veiledning for sikker DNS i Chrome forklarer at automatisk modus kan falle tilbake til ukryptert oppslag, mens en egendefinert leverandør ikke gjør det.

4. Tøm lokal DNS-cache etter at årsaken er rettet

På Windows kan du åpne ledetekst og kjøre:

ipconfig /flushdns

På nyere macOS kan du kjøre i Terminal:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Dette fjerner lokal cache på enheten. Det tømmer ikke cache hos internettleverandøren, en offentlig resolver eller resten av verden. Hvis autoritativ DNS fortsatt svarer NXDOMAIN, kommer feilen bare tilbake.

Hvis du administrerer domenet

1. Bekreft at domenet fortsatt er registrert

Kontroller status hos domeneforhandleren. For .no kan Norids domeneoppslag vise registrering, siste endring, domeneforhandler og navnetjenere.

Et utløpt, slettet eller ikke ferdig registrert domene kan mangle fungerende delegering. Har bedriften mistet tilgang, bruk gjenopprettingsguiden for domenekonto før du forsøker tekniske omveier.

2. Følg DNS-kjeden fra roten

Kjør:

dig +trace eksempel.no A

Se hvor kjeden stopper:

Får du henvisning fra .no til forventede navnetjenere?
Svarer navnetjenerne?
Svarer de autoritativt for domenet?
Gir de NXDOMAIN for selve domenet eller bare for ett underdomene?

Finn først de delegerte serverne med guiden til navnetjeneroppslag . Et kontrollpanel er ikke fasit hvis domenet peker til en annen DNS-leverandør.

3. Spør alle autoritative navnetjenere direkte

Test sonen og det feilede navnet:

dig @ns1.leverandor.no eksempel.no SOA +norecurse
dig @ns2.leverandor.no eksempel.no SOA +norecurse
dig @ns1.leverandor.no www.eksempel.no A +norecurse
dig @ns2.leverandor.no www.eksempel.no A +norecurse

Begge serverne bør svare med samme SOA-serienummer og samme resultat for navnet. Typiske funn:

Svar	Betydning	Handling
`NXDOMAIN` for `www`	vertsnavnet finnes ikke i sonen	opprett eller rett forventet A, AAAA eller CNAME
`NOERROR`, tomt A-svar	navnet finnes, men har ikke A-post	kontroller CNAME og AAAA før du endrer
Én server gir data, én gir NXDOMAIN	sonen er ikke synkron	rett publisering eller soneoverføring
SOA mangler `aa`	serveren er ikke autoritativ for domenet	rett delegering eller soneoppsett
timeout	serveren er utilgjengelig	kontroller nett, brannmur og DNS-leverandør
`SERVFAIL` fra resolver	validering eller autoritativ kjede feiler	undersøk DNSSEC og navnetjenere

NXDOMAIN og NODATA er ikke det samme. RFC 2308 definerer NXDOMAIN som at spørsmålsnavnet ikke finnes. Et NOERROR-svar uten den forespurte posttypen betyr at navnet kan finnes, men mangler akkurat den posten.

4. Rett posten i den aktive sonen

For et vanlig nettsted trenger rotdomenet og www hver sin gyldige vei til webplattformen. Eksempler kan være:

eksempel.no      A       192.0.2.10
www.eksempel.no  CNAME   eksempel.no.

Verdiene er dokumentasjonseksempler, ikke adresser som skal kopieres. Bruk alltid webleverandørens faktiske verdi.

Kontroller spesielt:

at posten er lagt i sonen hos de aktive navnetjenerne
at navnefeltet ikke har fått domenet lagt til to ganger
at CNAME-målet er skrevet riktig
at et gammelt NS-oppsett ikke peker til en tom sone
at Cloudflare-sonen er Active, ikke bare Pending

Hvis feilen kom etter et Cloudflare-bytte, bruk guiden til Cloudflare-navnetjenere og Pending-status .

5. Ta høyde for negativ cache

En resolver kan cache et autoritativt NXDOMAIN-svar. Hvis www ble slått opp før posten fantes, kan den samme resolveren fortsette å si «finnes ikke» en stund etter at du opprettet posten.

Se SOA-delen i det negative svaret:

dig www.eksempel.no A

RFC 2308 beskriver at negativ cache styres av den laveste verdien av SOA-postens egen TTL og SOA MINIMUM. Den gjenværende TTL-en i svaret kan gi en pekepinn på hvor lenge akkurat resolveren kan beholde feilen.

Sammenlign med direkte autoritativt svar og flere resolvere:

dig @ns1.leverandor.no www.eksempel.no A +norecurse
dig @1.1.1.1 www.eksempel.no A
dig @8.8.8.8 www.eksempel.no A

Hvis autoritativ server gir riktig post mens én resolver fortsatt gir NXDOMAIN, er venting eller cachetømming relevant. Hvis autoritativ server fortsatt gir NXDOMAIN, må sonen rettes; mer venting hjelper ikke.

Når DNSSEC er årsaken

En brutt DNSSEC-kjede viser seg oftest som SERVFAIL, ikke et rent NXDOMAIN-svar. Det kan oppstå etter navnetjenerbytte når en gammel DS-post fortsatt ligger i overordnet sone.

Test en validerende resolver og den autoritative serveren hver for seg. Hvis den autoritative serveren gir data, mens validerende resolvere gir SERVFAIL, følg DNSSEC-feilsøkingen i stedet for å legge inn flere webposter.

Ikke «fiks» feilen med større endringer enn nødvendig

Unngå disse snarveiene:

bytte DNS-leverandør når bare www mangler
deaktivere DNSSEC uten å ha påvist valideringsfeil
opprette wildcard-post for å skjule skrivefeil
endre både navnetjenere, proxy og webserver samtidig
vente et fast antall timer uten å kontrollere autoritativt svar

Den korteste løsningen er den som retter første feil i kjeden. Test deretter samme navn fra autoritativ server, offentlig resolver, mobilnett og vanlig nettleser før hendelsen avsluttes.