Praktisk teknisk støtte

DNS forklart, uten gjetting

Forstå DNS-navn, poster, hurtigbuffere og resolvere, med skrivebeskyttet feilsøking og et klart skille mellom å løse et navn og laste inn et nettsted.

Sist gjennomgått:

DNS er ett skritt i å nå et nettsted

Når du skriver inn et vertsnavn som www.example.com, trenger enheten informasjon for å nå målet. DNS leverer poster som er tilknyttet navn. En A- post kan gi en IPv4- adresse, mens en AAAA- post kan gi en IPv6- adresse. Andre posttyper støtter andre jobber.

Et svar beviser ikke at nettstedet fungerer. Enheten trenger fortsatt en rute, en tilkobling til serveren og en gyldig kryptert økt for HTTPS. Programmet kan da returnere en feil eller kreve autentisering. “DNS løser” og “siden lastes inn” er forskjellige funn.

En nettleser eller enhet ber om et DNS-svar, og oppretter deretter en separat HTTPS-tilkobling til nettstedet.
Forenklet opprinnelig diagram. Cacher og nettleser-spesifikke resolvere kan endre oppslagsstien. Åpne bilde i full størrelse.

Dette forenklede diagrammet skiller navnespørsmålet fra nettstedsforbindelsen. En mellomlager kan allerede gi svaret. Nettleseren kan bruke en annen resolver enn operativsystemet, så en lokal kommando og en nettleser trenger ikke å følge samme DNS- sti.

Løsere, autoritative servere og hurtigbuffere

En rekursiv resolver finner svar for klienter ved å følge DNS-informasjon når den mangler et bufret svar.En autoritativ navneserver publiserer postene for en sone.En hjemmeruter kan videresende spørsmål til en resolver et annet sted i stedet for å publisere nettstedets poster selv.

En postens levetid, eller TTL, påvirker hvor lenge et svar kan beholdes. Forskjellige resolvere kan beholde svar som er oppnådd på forskjellige tidspunkter, noe som bidrar til å forklare hvorfor en tilkobling ser en redigert post før en annen.

«Propagering» betyr ikke at en global switch-flip skjer på et bestemt tidspunkt. Posten, dens tidligere TTL, delegasjonsendringer og resolveratferd påvirker hva folk ser, og gjentatte redigeringer under testing kan gjøre bevisene vanskeligere å tolke.

Start med en kontrollert sammenligning

  1. Sjekk at adressen er stavet riktig og om den krever endring. www.
  2. Prøv et ikke-relatert nettsted på samme enhet.
  3. Sammenlign en annen nettleser og, hvis mulig, en annen enhet på samme tilkobling.
  4. Prøv en annen tillatt tilkobling hvis det er nyttig. Ta opp VPN- og nettleserens sikre DNS-innstillinger.

En mobildata- sammenligning endrer både nettverksstien og sannsynligvis DNS. Et vellykket resultat der begrenser problemet, men beviser ikke at DNS forårsaket det. En annen nettleser kan også avvike i utvidelser, økter eller mellomtjeneroppsett.

Bruke et skrivebeskyttet oppslag for å støtte bevis

På Windows, nslookup kan spørre den konfigurerte DNS Noen andre operativsystemer tilbyr det også. Hvis det mangler, følg systemets egne dokumenterte verktøy i stedet for å installere ukjent feilsøkingsprogramvare.

nslookup www.example.com

Dette gjør en DNS- forespørsel for et dokumentasjonsdomene. Erstatt det med det offentlige vertsnavnet du undersøker. Ikke send konfidensielle interne navn til offentlige oppløsere eller nettverksverktøy. Et selskap kan med vilje bruke intern eller delt DNS over sitt nettverk eller VPN.

Et IPv6-svar beviser ikke at det er brukbar IPv6-tilkobling, og et IPv4-svar beviser ikke at tjeneren godtar en tilkobling.

Sammenlign den offentlige visningen med enhetens visning

WAIU domene og DNS oppslag kontroller før en spørring kjøres.
Ekte WAIU forhåndsvisning skjermbilde. Ingen levende DNS svar vises; en ekstern oppslag bruker sin egen sjekk plassering. Åpne bilde i full størrelse.

Domenet og DNS-oppslag Den gir en annen offentlig visning, inkludert registreringsinformasjon når den er tilgjengelig.Plasseringen og resolveren er ikke enhetens, og den inspiserer ikke hjemme-DNS-bufferen.

Hvis den visningen ser riktig ut mens surfing mislykkes, sammenlign det lokale oppslaget og den eksakte feilen i nettleseren. En mellomtjener, VPN, sertifikatproblem eller blokkert tilkobling kan være involvert. Rapporter disse observasjonene i stedet for å erklære hele nettstedet som sunt fordi et eksternt oppslag returnerte en adresse.

Behandle en DNS-endring som et eksperiment

På ditt eget nettverk kan en annen anerkjent navneløser hjelpe deg med å undersøke feil i navneløsningen.Noter den gamle automatiske eller manuelle innstillingen, og finn ut hvordan du gjenoppretter den. Spør IT-avdelingen før du endrer en administrert enhet, fordi DNS kan gi interne navn eller filtrering.

Gjenta den opprinnelige sammenligningen etterpå der det er hensiktsmessig. En mellomlager kan også ha utløpt eller et mål gjenopprettet. Ikke endre ruteren, nettleseren og enheten samtidig og deretter anta hvilken endring som fikset det.

En rå IP- adresse er ikke en pålitelig erstatning for et nettstedsnavn. HTTPS- sertifikater og delt hosting er avhengig av vertsnavn. Omgå aldri en sertifikatadvarsel bare fordi en adresse ser troverdig ut.

Hvis du administrerer nettstedet

Identifiser den aktive autoritative DNS-leverandøren først. Registrering, DNS-hosting og webhotell kan være separate tjenester, og redigering av en inaktiv leverandørs panel endrer ikke den aktive sonen.

Etter en tiltenkt endring, sjekk nøyaktig vertsnavn, posttype og mål. Behold ikke- relaterte poster som e- postinnstillinger. Fungerende e- post etablerer ikke fungerende web- DNS, eller omvendt.

En nyttig billett inkluderer det offentlige vertsnavnet, forventet svar, observert feil, tid, tilkobling og VPN-status.For neste trinn etter navneoppløsning, bruk Nettstedet laster ikke inn guiden.

Kilder og videre lesing

Velg ditt neste skritt