| Domain Name System (DNS) | ||||||||
|---|---|---|---|---|---|---|---|---|
| Familie | Internett-protokollfamilie | |||||||
| Funksjon | Oppløsning av domenenavn | |||||||
| havner | 53/UDP, 53/TCP | |||||||
| Plassering i protokollstabelen | ||||||||
| ||||||||
| standarder | ||||||||
|
RFC 881 (The Domain Name Scheme and Agenda, 1983) | ||||||||
Domain Name System ( DNS ) [ 1 ] er et desentralisert hierarkisk navnesystem for enheter koblet til IP -nettverk som Internett eller et privat nettverk . Dette systemet knytter forskjellig informasjon til domenenavn som er tildelt hver av deltakerne. Dens viktigste funksjon er å "oversette" menneskelesbare navn til binære identifikatorer knyttet til datamaskiner koblet til nettverket, for å kunne lokalisere og adressere disse datamaskinene over hele verden. [ 2 ]
DNS-serveren bruker en hierarkisk , distribuert database som lagrer informasjon knyttet til domenenavn på nettverk som Internett . Selv om DNS som database er i stand til å knytte forskjellige typer informasjon til hvert navn, er de vanligste bruksområdene tilordning av domenenavn til IP-adresser og plasseringen av e-postserverne til hvert domene.
Kartleggingen av navn til IP-adresser er absolutt den mest kjente funksjonen til DNS-protokollene. Hvis for eksempel IP-adressen til Google-nettstedet er 216.58.210.163, når de fleste denne datamaskinen ved å spesifisere www.google.com og ikke IP-adressen. I tillegg til å være lettere å huske, er navnet mer pålitelig. [ 3 ] Den numeriske adressen kan endres av mange årsaker, uten at du trenger å endre navnet på nettstedet. Selv i tilfelle en nettside bruker et innholdsleveringsnettverk ( CDN , for akronymet på engelsk) gjennom DNS, vil brukeren motta IP-adressen til den nærmeste serveren i henhold til deres geografiske plassering (hver CDN har i sin tur sin egen DNS servere).
Hovedsakelig ble DNS født fra behovet for enkelt å huske navnene på alle serverne som er koblet til Internett. I utgangspunktet var SRI (nå SRI International ) vert for en fil kalt HOSTS som inneholdt alle kjente domenenavn. [ 4 ] [ 5 ]
Den eksplosive veksten av nettverket gjorde det sentraliserte navnesystemet i vertsfilen upraktisk, og i november 1983 publiserte Jon Postel planleggingen i RFC 881 og publiserte senere, sammen med Paul Mockapetris , RFC 882 og RFC 883 samme år. . I oktober 1984 og etter lange diskusjoner utstedte de RFC 920 [ 6 ] som definerte hva som i dag har utviklet seg til den moderne DNS (disse RFC - ene 882 og 883 ble erstattet i 1987 med RFC-ene 1034 og RFC 1035 ). [ 7 ]
I fravær av DNS-servere, vil brukerne måtte skrive IP-adressen til nettstedet i stedet for å skrive URL-en, noe som ville skape forvirring og Internett-navigasjon ville bli svært komplisert for brukerne.
På dette stadiet var den beste måten å gi "kontinuitet" å ha flere servere som svarer på flere spørsmål. En server var mester og de andre var slaver . Hver av slavene måtte med jevne mellomrom sjekke med masteren at dataene ikke var endret.
Omtrent 10 år senere ble det gjort noen store justeringer i DNS-protokollen. Dette var en mer dynamisk måte å holde servere oppdatert på, ved å bruke NOTIFY og inkrementelle soneoverføringer ( IXFR ). [ 8 ]
NOTIFY var en viktig endring. I stedet for å vente på at en slave skal sjekke, kan masteren sende NOTIFY-meldinger til slavene, og oppfordre dem til å innhente de nye dataene. På sin side betydde IXFR en endring i måten data ble kommunisert på. Hvis du endret bare én av hundrevis av poster, ville den opprinnelige spesifikasjonen sende hundrevis av meldinger. IXFR endret systemet, slik at bare poster som ble endret kunne sendes. [ 8 ]
Den neste utviklingen av DNS kom da dynamiske endringer ble definert i RFC 2136 . Dette gjorde det mulig for serveradministratorer å gjøre registerendringer bedre. Senere, i RFC 2671 , ble DNS-utvidelsesmekanismer (EDNS) definert , som ytterligere moderniserte systemet. [ 8 ]
Interessen for å utvide mulige domenenavn til å inkludere tegn fra andre språk ble reflektert i internasjonaliserte domenenavn som definert i RFC 5890 og RFC 5891 i 2010.
Tre hovedkomponenter brukes til den praktiske driften av DNS-systemet:
Fase 1 kunder Et DNS-klientprogram som kjører på brukerens datamaskin som genererer DNS-navneoppløsningsforespørsler til en DNS-server (for eksempel: Hvilken IP-adresse tilsvarer navn.domene?) DNS-servere De svarer på kundeforespørsler. Rekursive servere har muligheten til å videresende forespørselen til en annen server hvis de ikke har den forespurte adressen. myndighetssoner Det er en del av domenenavnet som er ansvarlig for en DNS-server, som kan ha autoritet over flere soner. (For eksempel: subdomain.Wikipedia.ORG, subdomain.COM, etc.)Et domenenavn består vanligvis av to eller flere deler (teknisk "etiketter"), atskilt med punktum når det er skrevet som tekst. For eksempel www.example.com eller en.wikipedia.org
DNS består av et hierarkisk sett med DNS-servere. Hvert domene eller underdomene har en eller flere "autoritetssoner" som publiserer informasjon om domenet og navnetjenestene til et inkludert domene. Hierarkiet av autoritetssoner faller sammen med hierarkiet av domener. På toppen av det hierarkiet er rotserverne - serverne som reagerer når de søker å løse et domene på første og andre nivå.
Brukere kommuniserer vanligvis ikke direkte med DNS-serveren: navneløsning gjøres transparent av klientapplikasjoner (for eksempel nettlesere , e-postklienter og andre applikasjoner som bruker Internett). Når du gjør en forespørsel som krever et DNS-oppslag, sendes forespørselen til operativsystemets lokale DNS-server. Operativsystemet, før det etablerer kommunikasjon, sjekker om svaret er i hurtigbufferen. I tilfelle den ikke blir funnet vil forespørselen bli sendt til en eller flere DNS-servere, [ 9 ] brukeren kan bruke sin ISP sine egne servere, de kan bruke en gratis domeneløsningstjeneste eller leie en avansert domeneløsningstjeneste betaling som vanligvis er tjenester inngått av selskaper for deres hastighet og sikkerheten de tilbyr.
De fleste hjemmebrukere bruker DNS-serveren som tilbys av Internett-leverandøren, bortsett fra de som tilpasser utstyret eller ruterne for visse offentlige servere. Adressen til disse serverne kan konfigureres manuelt eller automatisk gjennom DHCP (dynamisk IP). I andre tilfeller har nettverksadministratorer konfigurert sine egne DNS-servere.
I begge tilfeller ser først DNS-serverne som mottar forespørselen for å se om de har svaret i hurtigbufferen. Hvis ja, server svaret; ellers ville de starte søket rekursivt. Når svaret er funnet, vil DNS-serveren bufre resultatet for fremtidig bruk og returnere resultatet. [ 9 ]
Vanligvis transporterer DNS-protokollen forespørslene og svarene mellom klient og server ved å bruke UDP-protokollen , siden den er mye raskere. Anledningene der TCP-protokollen brukes er: når svar som er større enn 512 byte i lengde må transporteres (for eksempel ved bruk av DNSSEC) og når informasjon utveksles mellom servere (for eksempel ved soneoverføring), av pålitelighetsårsaker. [ 10 ]
Domenenavneområdet har en trestruktur . Bladene og nodene til treet brukes som medieetiketter. Et fullstendig kvalifisert domenenavn for et objekt består av sammenkoblingen av alle etikettene til en bane. Etiketter er alfanumeriske strenger (med "-" som eneste tillatte symbol), må være minst ett tegn og maksimalt 63 tegn lange, og må begynne med en bokstav (og ikke med "-"). [ 11 ] Individuelle etiketter er atskilt med punktum. Et domenenavn slutter med et punktum (selv om denne siste punktum vanligvis utelates da den er rent formell). Et riktig utformet domenenavn (FQDN, for akronymet på engelsk), er for eksempel dette: www.example.com. (inkludert perioden på slutten).
Et domenenavn må inneholde alle punktum og har en maksimal lengde på 255 tegn.
Et domenenavn skrives alltid fra høyre mot venstre. Prikken helt til høyre for et domenenavn skiller rotkoden fra hierarkiet. Dette første nivået er også kjent som et toppnivådomene (TLD).
Objektene til et DNS-domene (for eksempel datamaskinnavnet) er registrert i en sonefil som ligger på en eller flere navneservere.
Dette er typene servere i henhold til deres funksjon: [ 9 ]
Primær eller lærere lagre dataene til et navneområde i filene deres. sekundærer eller slaver de får dataene fra primærserverne gjennom en soneoverføring. Lokal eller cache de jobber med samme programvare, men de inneholder ikke databasen for navneløsning. Når et spørsmål sendes til dem, konsulterer de på sin side de tilsvarende DNS-serverne, og lagrer svaret i databasen deres for å fremskynde gjentakelsen av disse forespørslene i en kontinuerlig eller gratis fremtid.En DNS-server kan løse et domenenavn på en "rekursiv" eller "iterativ" måte. [ 12 ] I en "iterativ" spørring ber en klient en DNS-server om å hente hele svaret for seg selv (dvs. gitt domenet my.domain.com , forventer klienten å motta den tilsvarende IP-adressen). På den annen side, gitt en "rekursiv" spørring, gir ikke DNS-serveren et fullstendig svar: når det gjelder mitt.domene.com , returnerer den første serveren som spørringen gjøres til (en rotserver), IP-en. adresser fra toppnivåservere (TDL) som er ansvarlige for .com -domenet . Så klienten må nå gjøre en ny spørring til en av disse serverne, som noterer seg .domain.com- suffikset og svarer med den tilsvarende DNS-serverens IP, for eksempel dns.domain.com . Til slutt sender klienten en ny spørring til dns.domain.com for å få IP-adressen til my.domain.com .
I praksis er en verts spørring til en lokal DNS rekursiv, mens spørringer utført av den lokale DNS er iterative. Rekursive spørringer utføres også bare hvis den lokale DNS-serveren ikke har de tilsvarende bufrede dataene (eller hvis de har utløpt). Oppsummert utføres den normale oppløsningsprosessen som følger:
Opprinnelig var sikkerhetshensyn ikke store designhensyn i DNS-programvare eller annen programvare for distribusjon på det tidlige Internett, siden nettverket ikke var åpent for deltakelse av allmennheten. Utvidelsen av Internett til kommersiell sektor på 1990-tallet endret imidlertid kravene til sikkerhetstiltak for å beskytte dataintegritet og brukerautentisering .
Mange sårbarhetsproblemer ble oppdaget og utnyttet av ondsinnede brukere. Et slikt problem er DNS-bufferforgiftning , der data distribueres til hurtigbufferløsere under dekke av å være en opprinnende autoritetsserver, og dermed forurenser datalageret med potensielt falsk informasjon og lange utløpstider (tid-til-live). Deretter kan legitime søknadsforespørsler omdirigeres til nettverksutstyr som drives med skadelig innhold.
DNS-svar var tradisjonelt ikke signert kryptografisk , noe som tillot mange muligheter for angrep; DNS Security Extensions (DNSSEC) endrer DNS for å legge til muligheten til å ha kryptografisk signerte svar. DNSCurve er foreslått som et alternativ til DNSSEC. Andre utvidelser, for eksempel TSIG , legger til støtte for kryptografisk autentisering mellom pålitelige jevnaldrende og brukes ofte til å autorisere soneoverføringer eller dynamiske oppdateringsoperasjoner.
Noen domenenavn kan brukes til bedrag. For eksempel er paypal.com og paypa1.com forskjellige navn, men brukere kan kanskje ikke se forskjellen avhengig av fonten de bruker. I mange skrifttyper ser bokstaven l og tallet 1 veldig like ut eller til og med identiske. Dette problemet er alvorlig i systemer som tillater internasjonaliserte domenenavn, siden mange tegn i ISO 10646 kan vises identiske på typiske dataskjermer. Denne sårbarheten blir av og til utnyttet i phishing . [ 13 ]
Teknikker som forward-commit reverse FDNS kan også brukes til å validere DNS-resultater.
Domain Name System spesifiserer en database med informasjonselementer for nettverksressurser. Informasjonselementtyper er kategorisert og organisert med en liste over DNS-posttyper - Resource Records (RRs). Hver post har en type (navn og nummer), en utløpstid ( time to live ), en klasse og typespesifikke data. Ressursposter av samme type beskrives som et ressurspostsett (RRset) og har ikke en bestemt rekkefølge. DNS-løsere returnerer hele settet ved spørring, men servere kan implementere round-robin- bestilling for lastbalansering . Derimot fungerer Domain Name System Security Extensions (DNSSEC) på hele settet med ressursposter i kanonisk rekkefølge.
Når de sendes over et Internett-protokollnettverk , bruker alle poster det vanlige formatet spesifisert i RFC 1035 : [ 14 ]
| Landsbygda | Beskrivelse | Lengde ( oktetter ) |
|---|---|---|
| YAM | Navn på noden som posten tilhører | Variabel |
| TYPE | RR-type i numerisk form (for eksempel 15 for MX RR) | to |
| KLASSE | klassekode | to |
| TTL | Antall sekunder RR er gyldig (maksimum er 2 31 −1, som er omtrent 68 år) | 4 |
| RDLENGDE | RDATA-feltlengde (spesifisert i oktetter) | to |
| RDATA | Ytterligere RR-spesifikke data | Variabel, i henhold til RDLENGTH |
NAME er det fullt kvalifiserte domenenavnet til noden i treet. Under tilkoblingen kan navnet forkortes ved hjelp av etikettkomprimering der endene på domenenavn nevnt tidligere i pakken kan erstattes med slutten av det faktiske domenenavnet. En uavhengig @ brukes for å angi gjeldende opprinnelse.
TYPE er posttypen. Indikerer formatet på dataene og gir en ide om tiltenkt bruk. For eksempel brukes A -posten til å oversette fra et domenenavn til en IPv4-adresse , NS -posten viser hvilke navneservere som kan svare på spørsmål i en DNS-sone , og MX -posten spesifiserer e-postserveren som brukes til å håndtere e-post fra et domene. spesifisert i en e-postadresse lag av dns som er.
RDATA er relevante typespesifikke data, for eksempel IP-adresse for adresseposter, eller prioritet og vertsnavn for MX-poster. Kjente posttyper kan bruke tag-komprimering på RDATA-feltet, bortsett fra "ukjente" posttyper ( RFC 3597 ).
KLASSE er klassen til posten satt til IN (Internett) for vanlige DNS-poster som involverer vertsnavn, servere eller IP-adresser. I tillegg er det klassene Chaos (CH) og Hesiod (HS). Hver klasse er et eget navneområde med potensielt forskjellige delegeringer av DNS-soner.
I tillegg til ressurspostene som er definert i en sonefil , definerer domenenavnsystemet også ulike forespørselstyper som kun brukes i kommunikasjon med andre DNS-noder (på tilkoblingen), for eksempel ved utføring av soneoverføringer (AXFR / IXFR) eller for EDNS (OPT).
Domenenavnsystemet støtter jokertegn DNS-poster , som spesifiserer navn som begynner med stjernekoden "*", for eksempel * .example. [ 15 ] [ 16 ] DNS-poster knyttet til jokertegndomenenavn spesifiserer regler for generering av ressursposter innenfor en enkelt DNS-sone ved å erstatte etiketter med samsvarende komponenter av navnet, inkludert eventuelle spesifiserte etterkommere. For eksempel, i den følgende konfigurasjonen, spesifiserer DNS-sonen x.example at alle underdomener, inkludert underdomener til underdomener, til x.example bruker e-postutveksleren (MX) axexample . A-posten for axexample er nødvendig for å spesifisere IP-adressen til postutveksleren. Siden dette resulterer i å ekskludere dette domenenavnet og dets underdomener fra samsvar med jokertegn, må det også defineres en ekstra MX-post for axexample-underdomenet, samt en jokertegn MX-post for alle underdomenene i DNS-sonen.
x.eksempel. MX 10 akseeksempel. *.x.eksempel. MX 10 akseeksempel. *.ax eksempel. MX 10 akseeksempel. akseeksempel. MX 10 akseeksempel. akseeksempel. ÅÅÅÅ 2001:db8::1Rollen til jokertegnposter ble foredlet i RFC 4592 , fordi den opprinnelige definisjonen i RFC 1034 var ufullstendig og førte til feiltolkning av implementere. [ 16 ]
De mest brukte posttypene er:
| Type register | Betydning |
|---|---|
| EN | Adresse ( adresse ). Denne posten brukes til å oversette vertsservernavn til IPv4-adresser. |
| AAAA | Adresse ( adresse ). Denne posten brukes i IPv6 for å oversette vertsnavn til IPv6-adresser . |
| CNAME | Kanonisk navn ( kanonisk navn ). Den brukes til å lage flere vertsnavn, eller aliaser, for et domenes vertsservere. Den brukes når flere tjenester (som FTP og webserver) kjører på en server med én enkelt IP-adresse . Hver tjeneste har sin egen DNS-oppføring (som "ftp.example.com." og "www.example.com."). Dette brukes også når du kjører flere HTTP -servere , med forskjellige navn, på samme vert. Aliaset skrives først og deretter det virkelige navnet. Eks. «Eksempel1 I CNAME eksempel2» |
| NS | Navneserver ( navneserver ). Definerer assosiasjonen mellom et domenenavn og navneserverne som lagrer informasjonen for det domenet. Hvert domene kan assosieres med et hvilket som helst antall navneservere |
| MX | Postutveksling . _ Knytter et domenenavn til en liste over e-postutvekslere for det domenet. Den har en lastbalanse og prioritet for bruk av en eller flere posttjenester |
| PTR | Indikator ( peker ). Også kjent som en "omvendt post", fungerer den omvendt av A-posten, og oversetter IP-er til domenenavn. Brukes i omvendt DNS-sonekonfigurasjonsfil |
| SOA | Myndighet for området ( start av myndighet ). Gir informasjon om sonens primære DNS-server |
| SRV | Tjenestepost ( SRV-post ) |
| NOEN | All informasjon av alle typer som finnes. (Ikke en posttype, men en spørringstype) |
En "A"- og "AAAA"-post sies å være en " limpost " når den definerer et domene pekt på av en NS-post. En limpost knytter en "lim" IP-adresse til underdomenet du vil bruke som DNS-server. [ 17 ]
Anta for eksempel at vi har domenet "dittdomene.com" som jeg har underdomenene "ns1.dittdomene.com" og "ns2 for. dittdomene.com". Så kan vi lage en konfigurasjon som: [ 18 ]
dittdomene.com I NS ns1.dittdomene.com dittdomene.com I NS ns2.dittdomene.com ns1.yourdomain.com IN A 182.18.164.24 ns1.yourdomain.com I YYYY 2400:3b00:1:1::2 ns2.yourdomain.com IN A 103.231.77.204 ns2.yourdomain.com I YYYY 2400:3b00:20:4::d4De fire siste registrene sies å være limregistre.
Følgende dokumenter definerer domenenavnsystemet:
