DNS-oppslag — Spør alle domeners DNS-poster i sanntid
Diagnostiser e-postleveringsfeil, bekreft domenemigreringer og kontroller sikkerhetspolicyer – uten å installere dig eller nslookup.
Hva er et DNS-oppslag?
Et DNS-oppslag spør Domain Name System for å hente postene knyttet til et domene – fungerer som en telefonbok for internett, og oversetter menneskelesbare domenenavn til de tekniske datanettverkene trenger for å rute trafikk og levere tjenester. Hvert domene har flere posttyper: En post peker til IP-adresser, MX-poster ruter e-post, TXT-poster har sikkerhetspolicyer, og NS-poster delegerer autoritet til en navneserver.
Når du utløser et DNS-oppslag, går spørringen til en rekursiv resolver (drevet av din ISP, eller en offentlig resolver som 8.8.8.8 eller 1.1.1.1). Hvis løseren har et bufret svar i postens TTL-vindu, returnerer den den bufrede verdien. Hvis ikke, spør den den autoritative navneserveren - serveren som har domenets offisielle poster. Dette verktøyet omgår hurtigbufring og spør autoritative servere direkte, slik at resultatene gjenspeiler den nåværende publiserte tilstanden til sonen, ikke hva nettleseren din har bufret.
Nettleseren din utfører DNS-oppslag automatisk i bakgrunnen - men viser deg ingenting. Dette verktøyet avslører hele postsettet: ikke bare IP-adressen, men hver posttype som er knyttet til domenet, inkludert TTL-verdier som avslører hvor lenge hver post vil vedvare i cachen før resolvere kontrollerer den autoritative kilden på nytt.
Slik fungerer det
Skriv inn et domene
Skriv inn et domenenavn — for eksempel google.com eller github.com. Du kan spørre etter et rotdomene eller et underdomene.
Velg oppføringstype
Velg DNS-oppføringstypen du vil inspisere — A, MX, TXT, NS, CNAME, SOA, CAA — eller velg Alle oppføringer.
Se resultatene
Resultatene returneres i sanntid fra autoritative DNS-servere. Hver rad viser posttype, verdi, TTL (hvor lenge posten bufres av resolvere), og - for MX-poster - prioritetsnummeret. Kopier hvilken som helst post til utklippstavlen med ett klikk.
Slik leser du DNS-oppslagsresultatene
Når et oppslag er fullført, inneholder hver resultatrad flere felt. Her er hva hvert felt betyr og hva du skal se etter.
| Felt | Hva den forteller deg |
|---|---|
TTL (Time To Live) | Antall sekunder denne posten bufres av løsere før de spør den autoritative serveren på nytt. TTL 300 = endringer forplanter seg på ~5 minutter. TTL 86400 = den gamle posten kan vedvare i opptil 24 timer etter at du endret den. |
MX prioritet | Kun til stede på MX-plater. Lavere tall har høyere prioritet. Et oppsett på 10 (primær) og 20 (backup) skaper en failover-kjede. Like prioritetsverdier betyr at begge serverne deler belastningen likt. |
Rekordverdi | De faktiske dataene posten inneholder — en IP-adresse for A/AAAA-poster, et vertsnavn for MX/NS/CNAME, eller en tekststreng for TXT-poster. Dette er verdien som DNS-resolvere bruker når de ruter trafikk eller verifiserer policyer. |
CNAME kjede | Når en CNAME peker på en annen CNAME, dannes det en oppløsningskjede. Kjeder lengre enn 8 hopp vil ikke løse seg i de fleste klienter - hvis dybden blir et problem, erstatt mellomliggende CNAME-er med en direkte A-post. |
TTL og DNS forplantningstidslinje
Bruk TTL for å estimere hvor raskt løsere bør fange opp en endring og når det er verdt å sjekke på nytt.
| TTL (Time To Live) | Forventet forplantningsvindu | Når skal du sjekke på nytt |
|---|---|---|
| 300 | ~15-30 minutter over hele verden | Hvert 5-10 minutt |
| 3600 | ~1-2 timer | Hvert 30-60 minutt |
| 86400 | Opptil 24 timer | Sjekk etter 12 timer, så igjen etter 24 timer |
DNS-posttyper: Hva hver enkelt kontrollerer
Tilordner et domene til en IPv4-adresse – den mest grunnleggende DNS-posten. Eksempelutgang: 93.184.216.34, TTL 3600 (bufret 1 time). Når A-posten mangler eller er feil, blir domenet utilgjengelig fra nettlesere.
Tilordner et domene til en IPv6-adresse for moderne nettverksruting. Eksempel: 2606:2800:220:1:248:1893:25c8:1946. Hvis det mangler, kan ikke IPv6-klienter nå domenet – selv om IPv4 (A record) fallback vanligvis gjelder.
Angir hvilke e-postservere som aksepterer e-post for domenet. Hver post inkluderer et prioritert tall – lavere verdier har forrang. Eksempel: prioritet 10 er den primære serveren; prioritet 20 er reserven. Hvis ingen MX-post eksisterer, vil e-post til dette domenet bli avvist.
Lagrer vilkårlige tekstdata. Primære bruksområder: SPF (v=spf1 include:_spf.google.com ~all) autoriserer hvilke servere som kan sende e-post; DKIM gir en offentlig nøkkel for signaturverifisering; DMARC (v=DMARC1; p=reject) setter policyen for uautentisert e-post. Flere TXT-poster kan eksistere side om side på ett domene.
Identifiserer de autoritative navneserverne for domenet – serverne som har de offisielle DNS-postene. Hvis NS-poster endres, overføres soneautoriteten til de nye navneserverne etter utbredelse.
Oppretter et alias som peker ett domene til et annet, som deretter løses til en IP. Brukes for underdomener (www, cdn, mail) og CDN ruting. Kritisk begrensning: CNAME-poster kan ikke settes på rotdomenet (apex) – bruk en A-post eller ALIAS-post ved rot i stedet.
Inneholder sonemetadata: primær navneserver, adminkontakt (kodet som admin.example.com i stedet for [email protected]), serienummer i YYYYMMDDNN-format og tidsparametere. Serienummeret øker med hver DNS endring – bekrefter at en oppdatering er utført.
Begrenser hvilke sertifiseringsinstanser som kan utstede SSL/TLS-sertifikater for domenet. Eksempel: '0 issue letsencrypt.org' begrenser utstedelsen til kun Let's Encrypt. Hvis det ikke finnes noen CAA-post, kan enhver CA utstede et sertifikat for domenet ditt.
Hva er DNSSEC og validerer dette verktøyet det?
DNSSEC (DNS Security Extensions) legger til kryptografiske signaturer til DNS-poster, slik at resolvere kan bekrefte at poster ikke har blitt tuklet med under overføring. Dette verktøyet returnerer rå DNS-poster fra autoritative servere, men utfører for øyeblikket ikke DNSSEC-signaturvalidering. For DNSSEC-validering, bruk en dedikert DNSSEC-analysator.
Når skal du bruke et DNS-oppslagsverktøy
E-postkonfigurasjon og feilsøking
Spør etter MX-poster for å bekrefte e-postserverruting, sjekk TXT-poster for SPF-, DKIM- og DMARC-policyer, og bekreft at DMARC-policyen er satt til p=reject eller p=quarantine – ikke p=none.
Domeneoverfløtting og spredning
Etter å ha oppdatert DNS-innstillingene, kontroller A- og NS-postene for å bekrefte utbredelsen. Reduser TTL til 300 sekunder minst 24 timer før en planlagt migrering for å minimere nedetid når du bytter.
DNS Sikkerhetsrevisjon
Sjekk om SPF-, DKIM- og DMARC TXT-postene er korrekt publisert for å forhindre e-postforfalskning. Se gjennom NS-postene for å bekrefte at domenet ditt ikke peker til en navneserver du ikke lenger kontrollerer – et vanlig tegn på eksponering for overtakelse av underdomene.
DevOps og stagingbekreftelse
Før du distribuerer til produksjon, må du kontrollere at posting underdomene A-poster peker til de riktige serverne, CNAME-aliaser løses til den tiltenkte CDN-opprinnelsen, og TXT-poster for tjenesteverifisering er tilstede.
CDN og underdomenekonfigurasjon
Bekreft at CDN-rutede underdomener (cdn, assets, static) har de riktige CNAME-målene. Kontroller at www peker til rotdomenet eller CDN-endepunktet ditt, og kontroller at lastbalanserte underdomener viser alle tiltenkte IP-adresser.
Online DNS-oppslag vs dig og nslookup: Når skal du bruke hver
Utviklere strekker seg ofte etter dig eller nslookup fra kommandolinjen. Her er hvordan dette nettbaserte verktøyet sammenlignes på tvers av de vanligste brukstilfellene.
| Funksjon | Dette verktøyet | dig | nslookup |
|---|---|---|---|
| Ingen installasjon nødvendig | Ja | Nei | Nei |
| Spør alle posttyper samtidig | Ja | Delvis | Nei |
| Spørrer autoritative navneservere direkte | Ja | Ja | Delvis |
| Viser TTL-verdier | Ja | Ja | Delvis |
| Viser MX-prioritet | Ja | Ja | Ja |
| Resultater som kan deles | Ja | Nei | Nei |