DNS

Historien om DNS

Tilbage i 70'erne blev folk trætte af at huske IP-adresserne på de servere, de ønskede at få adgang til. Samtidig opstod ideen om at bruge et enklere og mere mindeværdigt navn i stedet for en numerisk værtsadresse.

Arbejdere ved Stanford Research Institute kom op med en tekstfil HOSTS.TXT , som indeholdt en liste over strengnavne og deres tilsvarende numeriske adresser på computere på ARPANET.

Adresser blev tildelt manuelt. For at anmode om et værtsnavn og en adresse eller føje en computer til masterfilen kontaktede brugere Stanfords netværksinformationscenter via telefon i åbningstiden.

I begyndelsen af ​​1980'erne var vedligeholdelsen af ​​en enkelt, centraliseret værtstabel blevet langsom og besværlig, og det voksende netværk havde brug for et automatisk navngivningssystem til at håndtere tekniske og personalemæssige problemer.

I 1984 skrev fire UC Berkeley-studerende den første version af det hierarkiske domænenavnssystem. Det er nu meget brugt, især på Unix-systemer, og er stadig den mest udbredte DNS-software på internettet.

Introduktion til DNS

Domain Name System (DNS) er et distributionssystem til lagring og hentning af information om domæner. Det er mest almindeligt brugt til at få en IP-adresse fra et værtsnavn (computer eller enhed), få ​​oplysninger om e-mail-routing og/eller betjene værter for protokoller i et domæne.

Systemet er organiseret i form af et bestemt hierarki af DNS-servere, der interagerer i henhold til en bestemt protokol. Grundlaget for at forstå DNS ​​er forståelsen af ​​den hierarkiske struktur af navnet og zonerne.

Hver server med ansvar for en domænezone kan overføre ansvaret for en yderligere del af domænet til en anden server, hvilket gør det muligt at tildele ansvaret for relevansen af ​​information til serverne i forskellige organisationer, der kun er ansvarlige for "deres" del af domænenavn.

DNS-systemet indeholder et hierarki af DNS-servere svarende til zonehierarkiet. Hver zone understøttes af mindst én autoritativ DNS-server, der hoster oplysninger om domænet.

Vigtig! Navnet og IP-adressen relaterer ikke nødvendigvis til hinanden som én til én. Én IP-adresse kan have mange domænenavne, hvilket giver dig mulighed for at understøtte mange websteder på én computer (dette kaldes delt hosting ).

Det kan også være omvendt - mange IP-adresser kan tilknyttes ét domænenavn: Dette giver dig mulighed for at skabe belastningsbalancering og bruges aktivt i CDN-netværk .

For at øge stabiliteten af ​​systemet bruges mange servere, der indeholder identisk information, og protokollen har midler til at opretholde synkroniseringen af ​​information, der er placeret på forskellige servere. Der er 13 rodservere, deres adresser ændres praktisk talt ikke.

Interessant! DNS-protokollen bruger TCP- eller UDP-port 53 til at svare på forespørgsler. Traditionelt sendes anmodninger og svar som et enkelt UDP-datagram. TCP bruges, når svardatastørrelsen overstiger 512 bytes.

DNS optegnelser

DNS-serveren gemmer et sæt parametre for hvert domænenavn. Disse er registreringer om domænenavnet, dets IP-adresse samt diverse serviceoplysninger.

Der er flere dusin sådanne poster i alt, så vi vil kun overveje de mest populære af dem:

De mest interessante her er:

• A- posten giver dig mulighed for at angive en IP-adresse, der svarer til et domæne.
• CNAME giver dig mulighed for at angive et synonym for navnet, for eksempel www.codegym.cc == codegym.cc.
• MX- posten indeholder oplysninger om mailserveren: hvad skal man gøre, hvis et brev ankommer til xxx@codegym.cc.
• NS - angiver adressen på DNS-serveren, som indeholder oplysninger om dette domæne. Nyttigt, når poster cachelagres og gemmes på ikke-native noder.

IP-adressesøgning

Lad os se, hvordan DNS-systemet fungerer.

Lad os sige, at du har skrevet api.codegym.cc i din browser. Browseren vil kontakte den lokale DNS-tjeneste og bede dig om at give den en IP-adresse for api.codegym.cc-domænet. Her er, hvad der vil ske næste gang...

Først ser DNS-tjenesten efter, om dette domæne er i den lokale værtsfil på din computer. Hvis der er, tager den IP-adressen fra den. Hvis ikke, sender den en anmodning til den kendte DNS-server: "Hvad er IP-adressen på api.codegym.cc?".

Dog ved DNS-serveren muligvis ikke kun noget om det anmodede navn, men endda om hele codegym.cc-domænet. I dette tilfælde kontakter serveren rodserveren - for eksempel 198.41.0.4. Denne server siger: "Jeg har ingen oplysninger om denne adresse, men jeg ved, at 204.74.112.1 er ansvarlig for ru-zonen."

Så sender DNS-serveren sin anmodning til 204.74.112.1, men den svarer: "Jeg har ingen oplysninger om denne server, men jeg ved, at 207.142.131.234 er ansvarlig for codegym.cc-zonen." Endelig sendes den samme anmodning til en tredje DNS-server og modtager et svar - en IP-adresse, som sendes til klienten, det vil sige browseren.

I dette tilfælde, i processen med at søge efter en IP ved navn, fungerede følgende regler:

• Browseren sendte en rekursiv anmodning til en kendt DNS-server (som svar på denne type anmodning skal serveren returnere en IP-adresse eller et tomt svar og en NXDOMAIN-fejlkode).
• Den DNS-server, der modtog anmodningen fra browseren, sendte ikke-rekursive anmodninger i rækkefølge, hvortil den modtog svar fra andre DNS-servere, indtil den modtog et svar fra den server, der var ansvarlig for den anmodede zone.
• Resten af ​​de nævnte DNS-servere behandlede anmodninger ikke-rekursivt (og ville højst sandsynligt ikke have behandlet anmodninger rekursivt, selvom et sådant krav var i anmodningen).

Det er nogle gange muligt for den anmodede server at sende en rekursiv forespørgsel til en "upstream" DNS-server og vente på et klart svar.

Vigtig! Med rekursiv forespørgselsbehandling går alle svar gennem DNS-serveren, og den får mulighed for at cache dem. En gentagen anmodning om de samme domænenavne går normalt ikke ud over serverens cache, og opkald til andre servere forekommer slet ikke.

Den tilladte cachetid for svar følger med svarene (TTL-feltet i ressourceposten).

hosts-fil

Vi har bemærket, at den første søgning er i den lokale værtsfil. Dette er arvingen til HOSTS.TXT-filen, som blev opfundet i ARPANETs dage. Ja, den eksisterer stadig og er stadig i brug.

Det er placeret langs stien:

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

Typisk indeholder filen en placeringsdefinition for den lokale værtsknude:

127.0.0.1   	localhost

Dens struktur er meget enkel: først kommer IP-adressen, derefter domænenavnet.

Nyttig

Ved at bruge hosts-filen er det muligt at filtrere annoncer ved at omdirigere domæneadresser på bannere til adressen 127.0.0.0, 127.0.0.1 eller 0.0.0.0.

Brugen af ​​127.0.0.1 anbefales generelt ikke, da det resulterer i en responstimeout og tilhørende forsinkelser, hvis serveren ikke eksisterer eller er forkert konfigureret. Og hvis du kortlægger et annoncedomæne til IP-adressen 0.0.0.0, vil alle anmodninger til det straks falde fra).

Offentlige DNS-servere

Du får normalt en DNS-server sammen med din internettjeneste, når du tilslutter den. Men sådan en gratis DNS-server er ikke altid den bedste mulighed. Desuden vil du måske ikke sende en forespørgsel med domænenavnet, hver gang du besøger et websted til din internetudbyders DNS-server.

Derfor foretrækker mange mennesker at skifte til offentlige gratis DNS-servere. For det første er de meget hurtige og har en stor cache af domænenavne. Du får hurtigere sideindlæsning og oppetid med en minimal chance for tekniske problemer.

For det andet sikkerhed. Nogle DNS-tjenester kan blokere adgangen til phishing og ondsindede websteder og tilbyde indholdsfiltrering for at beskytte børn mod upassende indhold online.

Sådanne DNS-servere kan endda bekæmpe svindlere. For eksempel går du til et falsk bankwebsted, og DNS-serveren giver dig ikke svindlernes IP-adresse, men dens sikkerhedstjeneste.

Liste over sådanne servere