DNS

Historien om DNS

Tilbake på 70-tallet ble folk lei av å huske IP-adressene til serverne de ønsket å få tilgang til. Samtidig kom ideen om å bruke et enklere og mer minneverdig navn i stedet for en numerisk vertsadresse.

Arbeidere ved Stanford Research Institute kom opp med en tekstfil HOSTS.TXT , som inneholdt en liste over strengnavn og deres tilsvarende numeriske adresser til datamaskiner på ARPANET.

Adresser ble tildelt manuelt. For å be om vertsnavn og adresse eller legge til en datamaskin i hovedfilen, kontaktet brukere Stanfords nettverksinformasjonssenter på telefon i åpningstidene.

På begynnelsen av 1980-tallet hadde vedlikeholdet av et enkelt sentralisert vertsbord blitt tregt og tungvint, og det voksende nettverket trengte et automatisk navnesystem for å håndtere tekniske og personellmessige problemer.

I 1984 skrev fire UC Berkeley-studenter den første versjonen av det hierarkiske domenenavnsystemet. Den er nå mye brukt, spesielt på Unix-systemer, og er fortsatt den mest brukte DNS-programvaren på Internett.

Introduksjon til DNS

Domain Name System (DNS) er et distribusjonssystem for å lagre og hente informasjon om domener. Det er oftest brukt til å skaffe en IP-adresse fra et vertsnavn (datamaskin eller enhet), skaffe e-postrutingsinformasjon og/eller betjene verter for protokoller i et domene.

Systemet er organisert i form av et visst hierarki av DNS-servere som samhandler i henhold til en bestemt protokoll. Grunnlaget for å forstå DNS ​​er forståelsen av den hierarkiske strukturen til navnet og sonene.

Hver server som er ansvarlig for en domenesone kan overføre ansvaret for en ytterligere del av domenet til en annen server, noe som gjør det mulig å tildele ansvaret for relevansen av informasjon til serverne til ulike organisasjoner som kun er ansvarlige for "sin" del av domenenavn.

DNS-systemet inneholder et hierarki av DNS-servere som tilsvarer sonehierarkiet. Hver sone støttes av minst én autoritativ DNS-server som er vert for informasjon om domenet.

Viktig! Navnet og IP-adressen er ikke nødvendigvis knyttet til hverandre som én til én. Én IP-adresse kan ha mange domenenavn, noe som lar deg støtte mange nettsteder på én datamaskin (dette kalles delt hosting ).

Det kan også være omvendt - mange IP-adresser kan knyttes til ett domenenavn: dette lar deg lage lastbalansering og brukes aktivt i CDN-nettverk .

For å øke stabiliteten til systemet brukes mange servere som inneholder identisk informasjon, og protokollen har midler for å opprettholde synkroniseringen av informasjon som ligger på forskjellige servere. Det er 13 rotservere, adressene deres endres praktisk talt ikke.

Interessant! DNS-protokollen bruker TCP- eller UDP-port 53 for å svare på spørsmål. Tradisjonelt sendes forespørsler og svar som et enkelt UDP-datagram. TCP brukes når svardatastørrelsen overstiger 512 byte.

DNS-poster

DNS-serveren lagrer et sett med parametere for hvert domenenavn. Dette er registreringer om domenenavnet, dets IP-adresse, samt diverse tjenesteinformasjon.

Det er flere dusin slike oppføringer totalt, så vi vil bare vurdere de mest populære av dem:

De mest interessante her er:

• A- posten lar deg spesifisere en IP-adresse som tilsvarer et domene.
• CNAME lar deg angi et synonym for navnet, for eksempel www.codegym.cc == codegym.cc.
• MX- posten inneholder informasjon om e-postserveren: hva du skal gjøre hvis et brev kommer til xxx@codegym.cc.
• NS - indikerer adressen til DNS-serveren, som inneholder informasjon om dette domenet. Nyttig når poster bufres og lagres på ikke-native noder.

IP-adressesøk

La oss se hvordan DNS-systemet fungerer.

La oss si at du skrev inn api.codegym.cc i nettleseren din. Nettleseren vil kontakte den lokale DNS-tjenesten og be deg om å gi den en IP-adresse for api.codegym.cc-domenet. Her er hva som vil skje videre...

Først ser DNS-tjenesten for å se om dette domenet er i den lokale vertsfilen på datamaskinen din. Hvis det er det, tar den IP-adressen fra den. Hvis ikke, sender den en forespørsel til DNS-serveren kjent for den: "Hva er IP-adressen til api.codegym.cc?".

Imidlertid vet DNS-serveren kanskje ingenting, ikke bare om det forespurte navnet, men til og med om hele codegym.cc-domenet. I dette tilfellet kontakter serveren rotserveren - for eksempel 198.41.0.4. Denne serveren sier: "Jeg har ingen informasjon om denne adressen, men jeg vet at 204.74.112.1 er ansvarlig for ru-sonen."

Deretter sender DNS-serveren sin forespørsel til 204.74.112.1, men den svarer: "Jeg har ingen informasjon om denne serveren, men jeg vet at 207.142.131.234 er ansvarlig for codegym.cc-sonen." Til slutt sendes den samme forespørselen til en tredje DNS-server og mottar et svar - en IP-adresse, som overføres til klienten, det vil si nettleseren.

I dette tilfellet, i prosessen med å søke etter en IP ved navn, fungerte følgende regler:

• Nettleseren sendte en rekursiv forespørsel til en kjent DNS-server (som svar på denne typen forespørsel, må serveren returnere en IP-adresse, eller et tomt svar og en NXDOMAIN-feilkode).
• DNS-serveren som mottok forespørselen fra nettleseren sendte ikke-rekursive forespørsler i rekkefølge, som den mottok svar fra andre DNS-servere til, inntil den mottok et svar fra serveren som var ansvarlig for den forespurte sonen.
• Resten av de nevnte DNS-serverne behandlet forespørsler ikke-rekursivt (og ville mest sannsynlig ikke ha behandlet forespørsler rekursivt, selv om et slikt krav var i forespørselen).

Det er noen ganger mulig for den forespurte serveren å sende en rekursiv spørring til en "oppstrøms" DNS-server og vente på et klart svar.

Viktig! Med rekursiv spørringsbehandling går alle svar gjennom DNS-serveren, og den får muligheten til å cache dem. En gjentatt forespørsel om de samme domenenavnene går vanligvis ikke utover serverens cache, og anrop til andre servere forekommer ikke i det hele tatt.

Den tillatte hurtigbuffertiden for svar følger med svarene (TTL-feltet i ressursposten).

hosts-fil

Vi la merke til at det første søket er i den lokale vertsfilen. Dette er arvingen til HOSTS.TXT-filen, som ble oppfunnet i ARPANETs dager. Ja, den eksisterer fortsatt og er fortsatt i bruk.

Den ligger langs stien:

• /etc/hosts på Linux.
• %SystemRoot%\system32\drivers\etc\hosts på Windows.
• /system/etc/hosts i Android.

Vanligvis inkluderer filen en plasseringsdefinisjon for den lokale vertsnoden:

127.0.0.1   	localhost

Strukturen er veldig enkel: først kommer IP-adressen, deretter domenenavnet.

Nyttig

Ved å bruke vertsfilen er det mulig å filtrere annonser ved å omdirigere domeneadresser til bannere til adressen 127.0.0.0, 127.0.0.1 eller 0.0.0.0.

Bruk av 127.0.0.1 anbefales generelt ikke, da det resulterer i et svartidsavbrudd og tilhørende forsinkelser hvis serveren ikke eksisterer eller er feilkonfigurert. Og hvis du tilordner et reklamedomene til IP-adressen 0.0.0.0, vil alle forespørsler til det umiddelbart falle av).

Offentlige DNS-servere

Du får vanligvis en DNS-server sammen med internettjenesten din når du kobler den til. Men en slik gratis DNS-server er ikke alltid det beste alternativet. Dessuten vil du kanskje ikke sende en spørring med domenenavnet hver gang du besøker et nettsted til Internett-leverandørens DNS-server.

Derfor foretrekker mange å bytte til offentlige gratis DNS-servere. For det første er de veldig raske og har en stor cache av domenenavn. Du vil få raskere sidelasting og oppetid med en minimal sjanse for tekniske problemer.

For det andre, sikkerhet. Noen DNS-tjenester kan blokkere tilgang til phishing og ondsinnede nettsteder og tilby innholdsfiltrering for å beskytte barn mot upassende innhold på nettet.

Slike DNS-servere kan til og med bekjempe svindlere. For eksempel går du til et falskt banknettsted, og DNS-serveren vil ikke gi deg IP-adressen til svindlerne, men sikkerhetstjenesten.

Liste over slike servere