DNS

DNS
Navn Domænenavnesystem
Niveau (ifølge OSI-modellen ) Anvendt
Familie TCP/IP
Port/ID 53/ TCP , 53/ UDP
Formål med protokollen Opløsning af domænenavn
Specifikation RFC 1034 , RFC 1035 / STD 13
Vigtigste implementeringer (klienter) Indbygget i alle netværksoperativsystemer
Kerneimplementeringer ( servere ) BIND , NSD , PowerDNS eller Microsoft DNS Server
 Mediefiler på Wikimedia Commons

DNS ( engelsk  Domain Name System  "domænenavnesystem") er et computerdistribueret system til indhentning af oplysninger om domæner . Mest almindeligt brugt til at få en IP-adresse fra et værtsnavn ( computer eller enhed), få ​​mail-routing-oplysninger og/eller serverværter til protokoller i et domæne ( SRV-record ).

En distribueret DNS-database understøttes af et hierarki af DNS-servere, der interagerer over en bestemt protokol .

Grundlaget for DNS er ideen om en hierarkisk navnestruktur og zoner . Hver server ansvarlig for navnet kan overføre ansvaret for den videre del af domænet til en anden server (fra et administrativt synspunkt - til en anden organisation eller person), hvilket giver dig mulighed for at tildele ansvaret for relevansen af ​​information til serverne på div. organisationer (personer), der kun er ansvarlige for "deres" deldomænenavn.

Fra og med 2010 har DNS-systemet implementeret dataintegritetstjek kaldet DNS Security Extensions ( DNSSEC ). De transmitterede data er ikke krypteret, men deres ægthed verificeres ved hjælp af kryptografiske metoder. Den implementerede DANE- standard sikrer overførsel af pålidelig kryptografisk information ( certifikater ) ved hjælp af DNS, der bruges til at etablere sikre og sikre forbindelser mellem transport- og applikationslaget .

Nøglekarakteristika for DNS

DNS har følgende egenskaber:

DNS er vigtig for driften af ​​internettet , da information om en værts IP-adresse er nødvendig for at oprette forbindelse til en vært, og det er lettere for folk at huske alfabetiske (normalt meningsfulde) adresser end en talfølge. I nogle tilfælde tillader dette brugen af ​​virtuelle servere, såsom HTTP-servere, der adskiller dem ved anmodningsnavnet. Oprindeligt blev konverteringen mellem domæne og IP-adresser udført ved hjælp af en speciel tekstfil hosts , som blev kompileret centralt og automatisk sendt til hver af maskinerne i dets lokale netværk. Med internettets vækst var der behov for en effektiv, automatiseret mekanisme, som blev til DNS.

DNS blev udviklet af Paul Mokapetris i 1983 ; den originale beskrivelse af arbejdsmekanismerne er indeholdt i RFC 882 og RFC 883 . I 1987 ændrede udgivelsen af ​​RFC 1034 og RFC 1035 DNS-specifikationen og udfasede RFC 882 , RFC 883 og RFC 973 .

Yderligere funktioner

Historie

Brugen af ​​et enklere og mere mindeværdigt navn i stedet for en numerisk værtsadresse stammer fra ARPANET -æraen . Stanford Research Institute (nu SRI International ) vedligeholdt en tekstfil HOSTS.TXT, der kortlagde værtsnavne til numeriske computeradresser på ARPANET . Vedligeholdelsen af ​​numeriske adresser, kaldet en liste over tildelte numre, blev håndteret af Jon Postel ved University of Southern California's Information Science Institute (ISI), hvis team arbejdede tæt sammen med NII [1] .

Adresser blev tildelt manuelt. For at anmode om et værtsnavn og en adresse og tilføje en computer til masterfilen kontaktede brugere SRI Network Information Center (NIC), drevet af Elisabeth Feinler , 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. Postel satte sig selv til opgave at udarbejde et kompromis mellem fem konkurrerende forslag for at løse problemet fra Paul Mokapetris. Mokapetris skabte i stedet konceptet om et hierarkisk domænenavnssystem.

IETF Working Group offentliggjorde de originale specifikationer i RFC 882 og RFC 883 i november 1983.

I 1984 skrev fire UC Berkeley -studerende, Douglas Terry, Mark Painter, David Riggle og Songnian Zhou, den første version af BIND -navneserveren (Berkeley Internet Name Daemon) . I 1985 gennemgik DEC's Kevin Dunlap betydeligt DNS-implementeringen. Mike Karel, Phil Almquist og Paul Vixey har støttet BIND lige siden. I begyndelsen af ​​1990'erne blev BIND overført til Windows NT -platformen . Det er udbredt, især på Unix-systemer, og er stadig den mest udbredte DNS-software på internettet.

I november 1987 blev DNS-specifikationerne - RFC 1034 og RFC 1035 vedtaget . Siden da er hundredvis af RFC'er blevet vedtaget, der modificerer og supplerer DNS.

Sikkerhedsproblemer

Oprindeligt var sikkerhedsproblemer ikke store overvejelser i udviklingen af ​​DNS-software eller nogen software, der skulle implementeres på det tidlige internet, da netværket ikke var åbent for offentligheden. Væksten af ​​internettet i den kommercielle sektor i 1990'erne ændrede imidlertid kravene til sikkerhedsforanstaltninger for at beskytte dataintegritet og brugergodkendelse.

Adskillige sårbarheder er blevet opdaget og udnyttet af angribere. Et sådant problem er DNS-cache-forgiftning , hvor data udbredes til caching-resolvere under påskud af at være en autoritativ oprindelsesserver, og derved forurener datalageret med potentielt falsk information og lange udløbsdatoer (time to live). Efterfølgende kan anmodninger fra legitime applikationer omdirigeres til netværksværter, der kontrolleres af angriberen.

DNS-svar blev ikke tidligere signeret kryptografisk, hvilket giver mulighed for en række forskellige angrebsmuligheder. Moderne Domain Name Security Extensions ( DNSSEC ) ændrer DNS for at tilføje understøttelse af kryptografisk signerede svar. Andre udvidelser, såsom TSIG, tilføjer understøttelse af kryptografisk godkendelse mellem betroede peers og bruges almindeligvis til at godkende zoneoverførsler eller dynamiske opdateringsoperationer.

Nogle domænenavne kan bruges til at opnå spoofing-effekter. For eksempel er paypal.com og paypa1.com forskellige navne, men brugerne er muligvis ikke i stand til at skelne dem i GUI'en afhængigt af brugerens valgte skrifttype. I mange skrifttyper ser bogstavet l og tallet 1 meget ens eller endda identiske ud. Dette problem er akut på systemer, der understøtter internationaliserede domænenavne, fordi mange af ISO 10646 -tegnkoderne kan vises på typiske computerskærme. Denne sårbarhed bliver nogle gange udnyttet i forbindelse med phishing .

Teknikker såsom omvendt DNS med direkte registreringsvalidering kan også bruges til at validere DNS-resultater, men de er ikke kryptografisk gyldige; dette tager ikke højde for muligheden for at erstatte ruteinformation ( engelsk  BGP hijacking ).

Terminologi og driftsprincipper

Nøglebegreberne i DNS er:

DNS-systemet indeholder et hierarki af DNS-servere , svarende til et hierarki af zoner . Hver zone understøttes af mindst én autoritativ DNS-server (fra engelsk  autoritative  - autoritative), som indeholder information om domænet.

Navnet og IP-adressen er ikke identiske  - én IP-adresse kan have mange navne, hvilket giver dig mulighed for at understøtte mange websteder på én computer (dette kaldes virtuel hosting ). Det omvendte er også sandt - mange IP-adresser kan tilknyttes det samme navn: Dette giver dig mulighed for at oprette belastningsbalancering .

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. [2]

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 og til AXFR - anmodninger.

Rekursion

Udtrykket rekursion i DNS refererer til DNS-serveradfærdsalgoritmen : "udfør på vegne af klienten en komplet søgning efter de nødvendige oplysninger i hele DNS-systemet, om nødvendigt med henvisning til andre DNS-servere" .

En DNS-forespørgsel kan være rekursiv  - kræver et fuldt opslag - og ikke-rekursiv (eller iterativ ) - kræver ikke et fuldt opslag.

På samme måde kan en DNS-server være rekursiv (i stand til at udføre fulde opslag) og ikke-rekursive (ikke i stand til at udføre fulde opslag). Nogle DNS-serversoftware, såsom BIND , kan konfigureres til at forespørge nogle klienter rekursivt og forespørge andre ikke - rekursivt .

Når DNS-serveren svarer på en ikke-rekursiv forespørgsel, såvel som manglende evne eller forbud mod at udføre rekursive forespørgsler, returnerer DNS-serveren enten data om den zone, den er ansvarlig for, eller returnerer en fejl. Indstillingerne for en ikke-rekursiv server, når svaret returnerer adresserne på servere, der har flere oplysninger om den anmodede zone end den reagerende server (oftest adresserne på rodserverne), er forkerte, og en sådan server kan bruges til at organisere DoS-angreb .

I tilfælde af en rekursiv forespørgsel poller DNS-serveren serverne (i faldende rækkefølge af zoneniveauet i navnet), indtil den finder et svar eller finder ud af, at domænet ikke eksisterer (i praksis starter søgningen fra den nærmeste DNS servere til den ønskede, hvis oplysninger om dem er tilgængelige cachelagret og opdateret, kan serveren muligvis ikke forespørge andre DNS-servere).

Overvej eksemplet med driften af ​​hele systemet.

Antag, at vi har indtastet adressen i browserenru.wikipedia.org . Browseren leder efter et match mellem denne adresse og IP-adressen i værtsfilen . Hvis filen ikke indeholder et match, spørger browseren DNS-serveren: "hvad er IP-adressen på ru.wikipedia.org"? Dog ved DNS-serveren muligvis ikke kun noget om det anmodede navn, men endda om hele domænet wikipedia.org. 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 zonen org." 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 zonen wikipedia.org." Til sidst sendes den samme anmodning til den tredje DNS-server og modtager et svar - en IP-adresse, som sendes til klienten - browseren.

I dette tilfælde, når du løser et navn, det vil sige i færd med at søge efter en IP ved navn:

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.

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 navne går normalt ikke ud over serverens cache , der er slet ingen opkald til andre servere. Den tilladte cachetid for svar følger med svarene ( TTL -feltet i ressourceposten ).

Rekursive anmodninger kræver flere ressourcer fra serveren (og skaber mere trafik), så de accepteres normalt fra noder "kendt" af serverejeren (for eksempel giver udbyderen mulighed for kun at lave rekursive anmodninger til sine klienter i en virksomhed netværk, accepteres rekursive anmodninger kun fra det lokale segment). Ikke-rekursive forespørgsler modtages normalt fra alle værter på netværket (og kun forespørgsler om den zone, der hostes af værten, får et meningsfuldt svar, DNS-forespørgsler til andre zoner returnerer normalt adresser på andre servere).

Omvendt DNS-forespørgsel

DNS bruges primært til at løse symbolske navne til IP-adresser, men det kan også udføre den omvendte proces. Til dette bruges eksisterende DNS-værktøjer. Faktum er, at forskellige data kan sammenlignes med en DNS-record, inklusive et symbolsk navn. Der er et særligt domæne in-addr.arpa, hvis indtastninger bruges til at konvertere IP-adresser til symbolske navne. For f.eks. at få et DNS-navn til en adresse 11.22.33.44, kan du forespørge DNS-serveren om en post, 44.33.22.11.in-addr.arpaog den vil returnere det tilsvarende symbolske navn. Den omvendte rækkefølge af at skrive dele af IP-adressen skyldes, at i IP-adresser er de høje bits placeret i begyndelsen, og i symbolske DNS-navne er de høje bits (placeret tættere på roden) placeret i slutningen.

DNS-poster

DNS records eller ressource records ( engelsk  resource records , RR ), er enheder til lagring og transmission af information i DNS. Hver ressourcepost består af følgende felter [3] :

De vigtigste typer DNS-poster er:

Reserverede domænenavne

RFC 2606 ( Reserved Top Level DNS Names) definerer domænenavne, der skal bruges som eksempler (for eksempel i dokumentation) og også til testformål. Ud over example.com, example.orgogexample.net omfatter denne gruppe også test, invalidmv.

Internationaliserede domænenavne

Et domænenavn kan kun bestå af et begrænset sæt ASCII -tegn, hvilket gør det muligt at indtaste domæneadressen uanset brugerens sprog. ICANN har godkendt et Punycode- baseret IDNA -system , der konverterer enhver Unicode -streng til et gyldigt DNS-tegnsæt.

DNS-software

Navneservere:

Se også

Noter

  1. IEEE Annals [3B2-9] man2011030074.3d 11:54. . - 29/7/011. — Side 74 s.
  2. Den aktuelle version af rodzonen er altid placeret på: ftp://ftp.internic.net/domain/named.root
  3. 1 2 Domain Name System (DNS) IANA-  overvejelser . tools.ietf.org. Hentet 7. februar 2019. Arkiveret fra originalen 2. august 2020.
  4. P.V. Mockapetris. Domænenavne - koncepter og faciliteter  . tools.ietf.org. Hentet 7. februar 2019. Arkiveret fra originalen 23. juni 2018.
  5. P.V. Mockapetris. Domænenavne - implementering og specifikation  (engelsk) . tools.ietf.org. Hentet 7. februar 2019. Arkiveret fra originalen 3. april 2019.

Links

Artikler

RFC'er