Jeg sluttet endelig å gjette på DNS-problemer etter å ha lært disse Windows-kommandoene

I lang tid betydde et DNS-problem at et nettsted ikke ville laste, eller at det ville laste på telefonen min, men ikke på PC-en min, og jeg begynte å jobbe meg gjennom en rekke Windows-kommandoer for å fikse internett. Jeg ville også starte ruteren på nytt, bytte til en annen DNS-server, eller starte Windows på nytt og håpe. Noen ganger fungerte en av dem, men jeg kunne aldri fortelle deg hvilken eller hvorfor, fordi jeg aldri egentlig så på problemet.

En bedre måte å håndtere et DNS-problem på er imidlertid å lære seg noen få Windows-kommandoer som viser deg hva DNS gjør. I stedet for å gjette om hurtigbufferen var utdatert, om DNS-serveren var utilgjengelig, eller om selve ruten var ødelagt, kan du sjekke hva som faktisk skjer under panseret.

ipconfig /displaydns

Viser deg alle adresser Windows for øyeblikket husker

Den første kommandoen jeg kjører når internett slutter å fungere er ipconfig /displaydns. Windows holder en lokal DNS-cache, en liste over nettnavn den nylig har slått opp, sammen med IP-adressene de ble løst til. Dette sparer PC-en din fra å spørre en DNS-server om det samme spørsmålet hver gang du åpner et nettsted. Problemet er at et cachet svar kan bli utdatert, og et utdatert svar er en av de vanligste årsakene til at et nettsted laster overalt unntatt på din maskin.

Å kjøre ipconfig /displaydns i Windows Terminal eller Kommandoprompt viser alle poster i denne cachen. Hver post viser postens navn, posttype, en Time To Live-verdi som teller ned sekunder til posten utløper, og den faktiske IP-adressen Windows har registrert. Det siste er det jeg er interessert i. Hvis et nettsted oppfører seg rart, kan jeg se nøyaktig hvilken adresse PC-en min tror den skal kommunisere med.

Her er stedet der gjettingen stopper. Hvis den bufrede IP-en ser feil ut, vet jeg at cachen er problemet før jeg rører noe annet. PowerShell går et skritt videre med Get-DnsClientCache-kommandoen, som lar deg filtrere cachen etter navn eller posttype.

nslookup

Spør en DNS-server direkte, slik at du slutter å gjette på hva som blir løst

ipconfig /displaydns forteller meg hva PC-en allerede tror. nslookup forteller meg hva som faktisk er sant akkurat nå. Det er et kommandolinjeverktøy som spør en DNS-server direkte og rapporterer tilbake IP-adressen knyttet til et vertsnavn slik at jeg kan sammenligne et ferskt svar med det utdaterte i hurtigbufferen min.

Det klareste tegnet på at DNS er problemet ditt, er når et nettsted nekter å laste, men pinging av en rå IP-adresse fungerer fint. Den splittelsen betyr at forbindelsen din er sunn, men oversettelsen fra navn til adresse feiler et sted. Å kjøre nslookup example.com bekrefter det. Hvis kommandoen returnerer en IP-adresse, gjør DNS jobben sin. Hvis den returnerer "Ikke-eksisterende domene" eller rett og slett går ut på tid, er selve oppslaget ødelagt.

Utdataene forteller deg også hvilken DNS-server som svarte. Et normalt resultat er merket "ikke-autoritativt," noe som betyr at svaret kom fra en servers cache i stedet for domenets offisielle poster, hvilket er forventet. Du kan også undersøke nærmere. Å legge til -type=mx henter e-postposter, nyttig når det er e-posten som er problemet, og -type=ns lister opp et domene sine navneservere. For daglig feilsøking er en vanlig nslookup vanligvis nok til å si om resolveren er synderen.

tracert

Viser deg nøyaktig hvor forbindelsen bryter sammen

Når nslookup bekrefter at et vertsnavn løser seg til en IP, er neste spørsmål om pakker faktisk kan nå den IP-en. Det er jobben til tracert. Den sporer ikke DNS-oppslaget i seg selv; den kartlegger banen dataene dine tar mot den løste adressen og viser hvor den banen blir treg eller stopper.

Det mest nyttige Tracert gjør for DNS-feilsøking, er å utelukke eller bekrefte DNS. Kjør tracert example.com, og hvis du umiddelbart ser "Unable to resolve target system name," kunne ikke Windows få en IP for det vertsnavnet i det hele tatt. Problemet er definitivt DNS eller vertsfilen din, ikke ruting. Men hvis sporet kommer forbi det første hoppet, har vertsnavnet allerede blitt løst med suksess, noe som betyr at DNS fungerte, og det som er feil, ligger lenger ned på stien.

Det er en smart liten trikse her. Kjør tracert mot et vertsnavn, og kjør det deretter igjen mot den rå IP-adressen som nslookup ga deg. Hvis IP-versjonen fullfører mens vertsnavnversjonen ikke engang starter, har du isolert feilen til DNS-oppløsning samtidig som du bekrefter at generell tilkobling fungerer fint. Du kan også peke tracert direkte mot en offentlig resolver som tracert 8.8.8.8. Hvis tilgangen til DNS-serveren selv er treg eller full av tidsavbrudd, vil oppslagene dine føles trege, uansett hvor god resten av forbindelsen din er, noe som noen ganger er et tegn på at ruteren din stille hemmer hastigheten.

ipconfig /flushdns

Fjerner den utdaterte bufferen som stadig sender deg ingen steder

På dette tidspunktet vet jeg vanligvis hva som er galt, og oftere enn ikke er det en utdatert cacheoppføring som peker PC-en min mot en gammel adresse. Løsningen er ipconfig /flushdns. Det tømmes hele den lokale DNS-cachen, slik at Windows henter ferske oppføringer neste gang du besøker et nettsted.

Dette er mest viktig etter at et nettsted flytter til en ny server. Nettstedet befinner seg nå på en ny IP, men PC-en din holder fortsatt på den gamle og sender deg pliktoppfyllende til en adresse som ikke lenger svarer. Å tømme cache fjerner denne utdaterte oppføringen. Det samme gjelder etter at du endrer DNS-serveren din eller mistenker at cachen har blitt ødelagt av skadelig programvare som omdirigerer oppslagene dine. Det er også en sikker kommando, sammenlignbar med rutinemessig nettverksvedlikehold, og den vil ikke skade ytelsen eller innstillingene.

En ting som er verdt å vite er at tømming ikke alltid vil tømme hurtigbufferen helt. Oppføringer fra din lokale hosts-fil blir ikke slettet, og bakgrunnsapper kan umiddelbart utløse nye oppslag som fyller den på nytt innen noen sekunder. Så hvis du kjører ipconfig /displaydns rett etter en tømming og fortsatt ser oppføringer, er det normalt. Hvis en tømming løser problemet, var problemet en foreldet oppføring. Hvis den ikke gjør det, har du eliminert hurtigbufferen som årsak og kan gå videre. Å bytte til en mer pålitelig oppløser etterpå er verdt å vurdere, og det å endre DNS-en din er ikke bare for PC-en din.

netsh winsock tilbakestill

Løsningen å prøve når ingenting annet virker

Hvis cachen er ren, vertsnavnet løses, og ruten er i orden, men nettverket fortsatt er ødelagt, kan problemet være dypere enn DNS. Dette er når jeg tar frem netsh winsock reset.

Winsock er Windows-nettverkskomponenten som sitter mellom applikasjonene dine, som nettleseren din, og selve nettet. Konfigurasjonen finnes i noe som kalles Winsock-katalogen, og den katalogen kan bli ødelagt av skadelig programvare, dårlig installert nettverksprogramvare, eller gjenværende oppføringer fra en enhet du fjernet. Når det skjer, får du rare feil: DNS-oppslag mislykkes til tross for riktige innstillinger, eller nettlesere rapporterer begrenset tilkobling uten åpenbar grunn.

Å kjøre netsh winsock reset i et forhøyet Kommandoprompt tilbakestiller den katalogen til standardtilstanden, og deretter må du starte på nytt for å fullføre prosessen. Før jeg kjører det, tar jeg et øyeblikksbilde med netsh winsock show catalog > winsock-before.txt, slik at jeg har en oversikt over hva som ble endret. Hvis problemet handler mer om IP-konfigurasjon enn Winsock, bygger den relaterte netsh int ip reset-kommandoen opp TCP/IP-innstillingene dine på samme måte. Ingen av dem er en garantert løsning, men som siste utvei før man kontakter support, fjerner en tilbakestilling korrupsjon som ingen mengde cache-tømming vil berøre.

Å fikse DNS-problemet er enkelt hvis du vet hvor du skal se

Jeg støter fortsatt på DNS-problemer, fordi alle gjør det. Men i stedet for å bruke alle triksene i boka på tilkoblingen min, kjører jeg to eller tre kommandoer, leser hva de forteller meg, og bruker riktig løsning. Når du vet hva som er årsaken, er løsningen den enkle delen.