DNS

DNS ( engelsk  Domain Name System  "domännamnssystem") är ett datordistribuerat system för att få information om domäner . Används oftast för att hämta en IP-adress från ett värdnamn (dator eller enhet), få ​​information om e- postdirigering och/eller servervärdar för protokoll i en domän ( SRV-post ).

En distribuerad DNS-databas stöds av en hierarki av DNS-servrar som interagerar över ett specifikt protokoll .

Grunden för DNS är idén om en hierarkisk namnstruktur och zoner . Varje server som ansvarar för namnet kan överföra ansvaret för den ytterligare delen av domänen till en annan server (ur administrativ synvinkel - till en annan organisation eller person), vilket gör att du kan tilldela ansvaret för informationens relevans till servrarna hos olika organisationer (människor) endast ansvariga för "sitt" deldomännamn.

Från och med 2010 har DNS-systemet implementerat dataintegritetskontroller som kallas DNS Security Extensions ( DNSSEC ). Den överförda informationen är inte krypterad, men dess äkthet verifieras med kryptografiska metoder. Den implementerade DANE- standarden säkerställer överföring av tillförlitlig kryptografisk information ( certifikat ) med hjälp av DNS som används för att upprätta säkra och säkra förbindelser mellan transport- och applikationsskikten .

Viktiga egenskaper hos DNS

DNS har följande egenskaper:

• Fördelning av administration . Olika personer eller organisationer är ansvariga för olika delar av den hierarkiska strukturen.
• Distribution av informationslagring . Varje nätverksnod måste nödvändigtvis endast lagra de data som ingår i dess ansvarsområde och (eventuellt) adresser till rot-DNS-servrar .
• Informationscache . _ En nod kan lagra en viss mängd data utanför sitt ansvarsområde för att minska nätverksbelastningen.
• Hierarkisk struktur , där alla noder kombineras till ett träd , och varje nod kan antingen självständigt bestämma arbetet för nedströms noder, eller delegera (överföra) dem till andra noder.
• Reservation . Flera servrar är (vanligtvis) ansvariga för att lagra och underhålla sina noder (zoner), separerade både fysiskt och logiskt, vilket säkerställer datasäkerheten och fortsättningen av arbetet även om en av noderna misslyckas.

DNS är viktigt för driften av Internet , eftersom information om en värds IP-adress behövs för att ansluta till en värd, och det är lättare för människor att komma ihåg alfabetiska (vanligtvis meningsfulla) adresser än en sekvens av nummer. I vissa fall tillåter detta användning av virtuella servrar, såsom HTTP-servrar, som särskiljer dem med namnet på begäran. Inledningsvis gjordes konverteringen mellan domän och IP-adresser med hjälp av en speciell textfil värdar , som kompilerades centralt och skickades automatiskt till var och en av maskinerna i dess lokala nätverk. Med webbens tillväxt fanns det ett behov av en effektiv, automatiserad mekanism, som blev DNS.

DNS utvecklades av Paul Mokapetris 1983 ; den ursprungliga beskrivningen av arbetsmekanismerna finns i RFC 882 och RFC 883 . 1987 ändrade publiceringen av RFC 1034 och RFC 1035 DNS-specifikationen och utfasade RFC 882 , RFC 883 och RFC 973 .

Ytterligare funktioner

• stöd för dynamiska uppdateringar
• dataskydd ( DNSSEC ) och transaktioner ( TSIG )
• stöd för olika typer av information

Historik

Användningen av ett enklare och mer minnesvärt namn istället för en numerisk värdadress kommer från ARPANET -eran . Stanford Research Institute (nu SRI International ) upprätthöll en textfil HOSTS.TXT som mappade värdnamn till numeriska datoradresser på ARPANET . Underhållet av numeriska adresser, kallat en lista över tilldelade nummer, sköttes av Jon Postel vid University of Southern California's Information Science Institute (ISI), vars team arbetade nära NII [1] .

Adresser tilldelades manuellt. För att begära ett värdnamn och adress och lägga till en dator till huvudfilen, kontaktade användare SRI Network Information Center (NIC), som drivs av Elisabeth Feinler , per telefon under kontorstid.

I början av 1980-talet hade underhållet av en enda centraliserad värdtabell blivit långsam och besvärlig, och det växande nätverket behövde ett automatiskt namnsystem för att hantera tekniska frågor och personalfrågor. Postel satte sig själv i uppgift att utarbeta en kompromiss mellan fem konkurrerande förslag för att lösa det problem som Paul Mokapetris ställde upp. Mokapetris skapade istället konceptet med ett hierarkiskt domännamnssystem.

IETF Working Group publicerade de ursprungliga specifikationerna i RFC 882 och RFC 883 i november 1983.

1984 skrev fyra UC Berkeley- studenter, Douglas Terry, Mark Painter, David Riggle och Songnian Zhou, den första versionen av BIND -namnservern (Berkeley Internet Name Daemon) . 1985 gjorde DEC:s Kevin Dunlap en rejäl översyn av DNS-implementeringen. Mike Karel, Phil Almquist och Paul Vixey har stöttat BIND sedan dess. I början av 1990-talet portades BIND till Windows NT -plattformen . Den är utbredd, särskilt på Unix-system, och är fortfarande den mest använda DNS-mjukvaran på Internet.

I november 1987 antogs DNS-specifikationerna - RFC 1034 och RFC 1035 . Sedan dess har hundratals RFC :er antagits för att modifiera och komplettera DNS.

Säkerhetsproblem

Inledningsvis var säkerhetsproblem inte stora överväganden i utvecklingen av DNS-programvara, eller någon programvara som skulle distribueras på det tidiga Internet, eftersom nätverket inte var öppet för allmänheten. Internets tillväxt i den kommersiella sektorn på 1990-talet förändrade dock kraven på säkerhetsåtgärder för att skydda dataintegritet och användarautentisering.

Flera sårbarheter har upptäckts och utnyttjats av angripare. Ett sådant problem är DNS-cacheförgiftning , där data sprids till caching-resolvers under sken av att vara en auktoritativ ursprungsserver, och därigenom förorenar datalagret med potentiellt falsk information och långa utgångsdatum (tid att leva). Därefter kan förfrågningar från legitima applikationer omdirigeras till nätverksvärdar som kontrolleras av angriparen.

DNS-svar har inte tidigare signerats kryptografiskt, vilket möjliggör en mängd olika attackalternativ. Moderna domännamnssäkerhetstillägg ( DNSSEC ) modifierar DNS för att lägga till stöd för kryptografiskt signerade svar. Andra tillägg, som TSIG, lägger till stöd för kryptografisk autentisering mellan betrodda kamrater och används ofta för att auktorisera zonöverföringar eller dynamiska uppdateringsoperationer.

Vissa domännamn kan användas för att uppnå spoofingseffekter. Till exempel är paypal.com och paypa1.com olika namn, men användare kanske inte kan särskilja dem i GUI beroende på användarens valda teckensnitt. I många typsnitt ser bokstaven l och siffran 1 väldigt lika eller till och med identiska ut. Detta problem är akut på system som stöder internationaliserade domännamn eftersom många av ISO 10646- teckenkoderna kan visas på typiska datorskärmar. Denna sårbarhet utnyttjas ibland vid nätfiske .

Tekniker som omvänd DNS med direkt postvalidering kan också användas för att validera DNS-resultat, men de är inte kryptografiskt giltiga; detta tar inte hänsyn till möjligheten att ersätta ruttinformation ( engelsk  BGP-kapning ).

Terminologi och funktionsprinciper

De viktigaste begreppen för DNS är:

• Domän ( engelsk  domän  "område") - en nod i namnträdet, tillsammans med alla noder som är underordnade den (om några), det vill säga en namngiven gren eller underträd i namnträdet. Strukturen för ett domännamn återspeglar ordningen på noderna i hierarkin; domännamnet läses från vänster till höger från juniordomäner till toppdomäner (i stigande ordningsföljd): överst finns rotdomänen (som har identifieraren "." (prick)), nedanför finns domänerna på första nivån ( domänzoner ), sedan - domänerna på andra nivån, den tredje etc. (till exempel för en adressru.wikipedia.org.är domänen på första nivånorg, den andra ärwikipedia, den tredje ärru). DNS låter dig inte ange punkten för rotdomänen.
• Underdomän ( engelska  underdomän ) - en underordnad domän (till exempelwikipedia.org - en underdomän till domänenorgochru.wikipedia.org - domänenwikipedia.org). Teoretiskt kan en sådan uppdelning vara upp till 127 nivåer djup, och varje etikett kan innehålla upp till 63 tecken, tills den totala längden, inklusive punkter, når 254 tecken. Men i praktiken använder domännamnsregistratorer strängare begränsningar. Om du till exempel har en vydomänmydomain.rukan du skapa olika vyunderdomäner för denmysite1.mydomain.ruosvmysite2.mydomain.ru.
• En resurspost  är en enhet för lagring och överföring av information i DNS. Varje resurspost har ett namn (det vill säga den är knuten till ett specifikt domännamn , en nod i namnträdet), en typ och ett datafält , vars format och innehåll beror på typen .
• En zon  är en del av ett domännamnsträd (inklusive resursposter ), värd som en enda enhet på någon domännamnsserver ( DNS-server , se nedan), och oftare - samtidigt på flera servrar (se nedan). Syftet med att isolera en del av trädet till en separat zon är att överföra ansvaret (se nedan) för motsvarande domän till en annan person eller organisation. Detta kallas delegering (se nedan). Som en sammanhängande del av trädet är zonen inuti också ett träd. Om vi ​​betraktar DNS-namnområdet som en struktur av zoner, och inte enskilda värdar/namn, får vi också ett träd; det är motiverat att tala om föräldra- och barnzoner, om äldre och underordnade. I praktiken består de flesta 0- och 1-nivåzoner ('.', ru, com, …) av en enda nod som underordnade zoner är direkt underordnade. I stora företagsdomäner (2:a eller fler nivåer) bildas ibland ytterligare underordnade nivåer utan att separera dem i underordnade zoner.
• Delegering  är operationen att överföra ansvaret för en del av domännamnsträdet till en annan person eller organisation. Delegering i DNS säkerställer distribuerad administration och lagring. Tekniskt sett uttrycks delegering i tilldelningen av denna del av trädet till en separat zon och placeringen av denna zon på en DNS-server (se nedan) som hanteras av denna person eller organisation. Samtidigt ingår " limning " resursposter (NS och A) som innehåller pekare till DNS-servrarna för den underordnade zonen i den överordnade zonen, och all annan information relaterad till den underordnade zonen är redan lagrad på DNS-servrarna i den underordnade zonen. barnzon.
• DNS-server  - specialiserad programvara för att betjäna DNS, såväl som den dator som denna programvara körs på. DNS-servern kan vara ansvarig för vissa zoner och/eller kan vidarebefordra förfrågningar till uppströmsservrar.
• DNS-klient  är ett specialiserat bibliotek (eller program) för att arbeta med DNS. I vissa fall fungerar DNS-servern som en DNS-klient.
• Authority ( eng.  auktoritativ ) - ett tecken på platsen för zonen på DNS-servern. DNS-serversvar kan vara av två typer: auktoritativa (när servern hävdar att den är ansvarig för själva zonen) och icke -auktoritativ ( eng.  Non-authoritative ), när servern bearbetar begäran och returnerar ett svar från andra servrar. I vissa fall, istället för att skicka begäran vidare, kan DNS-servern returnera ett värde som redan är känt för den (genom förfrågningar tidigare) (cacheläge).
• DNS-fråga ( eng.  DNS-fråga ) - en begäran från klienten (eller servern) till servern. En fråga kan vara rekursiv eller icke-rekursiv (se rekursion ).

DNS-systemet innehåller en hierarki av DNS-servrar , motsvarande en hierarki av zoner . Varje zon stöds av minst en auktoritativ DNS-server (från engelskan  auktoritativ  - auktoritativ), som innehåller information om domänen.

Namnet och IP-adressen är inte identiska  - en IP-adress kan ha många namn, vilket gör att du kan stödja många webbplatser på en dator (detta kallas virtuell värd ). Det omvända är också sant - många IP-adresser kan mappas till samma namn: detta låter dig skapa lastbalansering .

För att öka stabiliteten i systemet används många servrar som innehåller identisk information, och protokollet har medel för att upprätthålla synkroniseringen av information som finns på olika servrar. Det finns 13 rotservrar , deras adresser ändras praktiskt taget inte. [2]

DNS-protokollet använder TCP - eller UDP - port 53 för att svara på frågor. Traditionellt skickas förfrågningar och svar som ett enda UDP-datagram . TCP används när svarsdatastorleken överstiger 512 byte och för AXFR- förfrågningar.

Rekursion

Termen rekursion i DNS hänvisar till DNS-serverns beteendealgoritm : "utför på uppdrag av klienten en fullständig sökning efter nödvändig information i hela DNS-systemet, om nödvändigt, med hänvisning till andra DNS-servrar" .

En DNS-fråga kan vara rekursiv  - kräver en fullständig sökning - och icke-rekursiv (eller iterativ ) - kräver inte en fullständig sökning.

På liknande sätt kan en DNS-server vara rekursiv (kan utföra fullständiga uppslagningar) och icke-rekursiv (kan inte utföra fullständiga uppslagningar). Viss DNS-serverprogramvara, såsom BIND , kan konfigureras för att fråga vissa klienter rekursivt och frågar andra icke- rekursivt .

När man svarar på en icke-rekursiv fråga, samt oförmåga eller förbud att utföra rekursiva frågor, returnerar DNS-servern antingen data om zonen som den är ansvarig för , eller returnerar ett fel. Inställningarna för en icke-rekursiv server, när svaret returnerar adresserna till servrar som har mer information om den begärda zonen än den svarande servern (oftast adresserna till rotservrarna), är felaktiga, och en sådan server kan vara används för att organisera DoS-attacker .

I fallet med en rekursiv fråga , frågar DNS-servern servrarna (i fallande ordning efter zonnivån i namnet) tills den hittar ett svar eller finner att domänen inte existerar (i praktiken startar sökningen från närmaste DNS servrar till den önskade, om information om dem är tillgänglig cachad och uppdaterad, kanske servern inte frågar andra DNS-servrar).

Betrakta exemplet på driften av hela systemet.

Anta att vi skrev in adressen i webbläsarenru.wikipedia.org . Webbläsaren letar efter en matchning mellan denna adress och IP-adressen i hosts-filen . Om filen inte innehåller en matchning frågar webbläsaren DNS-servern: "Vad är IP-adressen till ru.wikipedia.org"? DNS-servern kanske inte bara vet något om det begärda namnet, utan även om hela domänen wikipedia.org. I det här fallet kontaktar servern  rotservern - till exempel 198.41.0.4. Den här servern säger - "Jag har ingen information om den här adressen, men jag vet att 204.74.112.1 är ansvarig för zonen org." Sedan skickar DNS-servern sin begäran till 204.74.112.1, men den svarar "Jag har ingen information om den här servern, men jag vet att 207.142.131.234 är ansvarig för zonen wikipedia.org." Slutligen skickas samma begäran till den tredje DNS-servern och får ett svar - en IP-adress, som överförs till klienten - webbläsaren.

I det här fallet, när du löser ett namn, det vill säga när du söker efter en IP med namn:

• webbläsaren skickade en rekursiv begäran till den DNS-server som den känner till - som svar på denna typ av begäran måste servern returnera ett "färdigt resultat", det vill säga en IP-adress, eller ett tomt svar och en NXDOMAIN-felkod;
• DNS-servern som tog emot begäran från webbläsaren skickade icke-rekursiva förfrågningar i sekvens, till vilka den fick svar från andra DNS-servrar, tills den fick ett svar från servern som ansvarar för den begärda zonen;
• de andra nämnda DNS-servrarna behandlade förfrågningar icke-rekursivt (och skulle troligen inte ha behandlat förfrågningar rekursivt, även om ett sådant krav fanns i begäran).

Det är ibland möjligt för den begärda servern att skicka en rekursiv fråga till en "uppströms" DNS-server och vänta på ett klart svar.

Med rekursiv frågebehandling går alla svar via DNS-servern, och den får möjlighet att cache dem. En upprepad begäran om samma namn går vanligtvis inte utöver serverns cache , det finns inga anrop till andra servrar alls. Den tillåtna cachetiden för svar kommer med svaren ( TTL -fältet i resursposten ).

Rekursiva förfrågningar kräver mer resurser från servern (och skapar mer trafik), så de accepteras vanligtvis från noder "kända" för serverägaren (till exempel tillhandahåller leverantören möjligheten att göra rekursiva förfrågningar endast till sina klienter, i ett företag nätverk, accepteras rekursiva förfrågningar endast från det lokala segmentet). Icke-rekursiva förfrågningar tas vanligtvis emot från alla värdar i nätverket (och endast frågor om den zon som hostas av värden ges ett meningsfullt svar, DNS-frågor för andra zoner returnerar vanligtvis adresser till andra servrar).

Omvänd DNS-fråga

DNS används främst för att lösa symboliska namn till IP-adresser, men det kan också utföra den omvända processen. För detta används befintliga DNS-verktyg. Faktum är att olika data kan jämföras med en DNS-post, inklusive ett symboliskt namn. Det finns en speciell domän in-addr.arpavars poster används för att konvertera IP-adresser till symboliska namn. Till exempel, för att få ett DNS-namn för en adress 11.22.33.44, kan du fråga DNS-servern efter en post 44.33.22.11.in-addr.arpaoch den kommer att returnera motsvarande symboliska namn. Den omvända ordningen för att skriva delar av IP-adressen beror på att i IP-adresser ligger de höga bitarna i början, och i symboliska DNS-namn är de höga bitarna (som ligger närmare roten) i slutet.

DNS-poster

DNS-poster , eller resursposter ( engelsk  resource records , RR ), är enheter för lagring och överföring av information i DNS. Varje resurspost består av följande fält [3] :

• namn (NAME) - domännamnet till vilket denna resurspost är länkad eller "ägd",
• resursposttyp (TYPE) - definierar formatet och syftet med denna resurspost,
• klass (KLASS) för resursposten; teoretiskt tror man att DNS inte bara kan användas med TCP / IP , utan också med andra typer av nätverk, koden i klassfältet bestämmer typen av nätverk [3] ,
• TTL (Time To Live) - den tillåtna tiden för att lagra denna resurspost i cachen på en oansvarig DNS-server ,
• datafältslängd (RDLEN),
• datafält (RDATA), vars format och innehåll beror på posttypen .

De viktigaste typerna av DNS-poster är:

• En A ( adresspost ) eller adresspost associerar ett värdnamn med en IPv4-adress. Om du till exempel frågar efter en A-post för ett namn referrals.icann.orgreturneras dess IPv4-adress - 192.0.34.164.
• En AAAA ( IPv6-adresspost ) associerar ett värdnamn med en IPv6- adress . Om du till exempel frågar efter en AAAA-post för ett namn K.ROOT-SERVERS.NETreturneras dess IPv6- adress - 2001:7fd::1.
• En CNAME-post ( kanonisk namnpost ) eller en kanonisk namnpost (alias) används för att omdirigera till ett annat namn.
• MX-posten ( postutbyte ) eller postutbytare anger postutbytesservern (arna) för den givna domänen.
• NS-posten ( namnserver ) pekar på DNS-servern för den givna domänen.
• En PTR-post ( pekare [4] [5] ) är en omvänd DNS- eller pekarpost som associerar en värds IP-adress med dess kanoniska namn. En domänfråga för en värds IP-adress i omvänd form kommer att returnera namnet ( FQDN ) på den värden (se Omvänd DNS-fråga ). Till exempel (i skrivande stund), för en IP-adress kommer en PTR-postfråga att returnera sitt kanoniska namn . För att minska mängden oönskad e-post (skräppost) kan många e-postmottagande servrar söka efter en PTR-post för värden som den skickas från. I det här fallet måste PTR-posten för IP-adressen matcha namnet på den sändande e-postservern som den verkar vara under SMTP- sessionen.in-addr.arpa192.0.34.164164.34.0.192.in-addr.arpareferrals.icann.org
• SOA - posten ( Start of Authority ) eller den initiala posten för zonen anger på vilken server referensinformationen om denna domän är lagrad, innehåller kontaktinformation för den person som är ansvarig för denna zon, tidpunkter (tidsparametrar) för cachning av zoninformation och interaktion mellan DNS-servrar.
• SRV-record ( serverval ) specificerar servrar för tjänster som används i synnerhet för Jabber och Active Directory .

Reserverade domännamn

RFC 2606 ( Reserved Top Level DNS Names) definierar domännamn som ska användas som exempel (till exempel i dokumentation) och även för teständamål. Denna grupp omfattar förutom example.com, example.orgochexample.net , även test, invalidetc.

Internationaliserade domännamn

Ett domännamn kan bara bestå av en begränsad uppsättning ASCII -tecken, vilket gör att domänadressen kan skrivas in oavsett användarens språk. ICANN har godkänt ett Punycode - baserat IDNA- system som konverterar vilken Unicode -sträng som helst till en giltig DNS-teckenuppsättning.

DNS-programvara

Namnservrar:

• BIND (Berkeley Internet Name Domain) [1]
• djbdns ( Daniel J. Bernsteins DNS) [2]
• dnsmasq [3]
• MaraDNS [4]
• NSD (Name Server Daemon) [5]
• PowerDNS [6]
• OpenDNS [7]
• Microsoft DNS Server (i serverversioner av Windows NT -operativsystem )
• MyDNS [8]

Se även

• EDNS  är den nya DNS-protokollstandarden
• Alternativa DNS-rotservrar
• ÖppnaDNS
• Google Public DNS
• Yandex.DNS
• Cybersquatting
• Typsquatting
• Dynamisk DNS
• Round robin DNS  - lastbalansering mellan identiska servrar.
• JAG KAN
• DNSSEC
• DNS-klient
• DNS-server
• Nslookup
• DNS-zonöverföring

Anteckningar

1. ↑ IEEE Annals [3B2-9] man2011030074.3d 11:54. . - 29/7/011. — Sida 74 sid.
2. ↑ Den aktuella versionen av rotzonen finns alltid på: ftp://ftp.internic.net/domain/named.root
3. ↑ 1 2 Domain Name System (DNS) IANA-  överväganden . tools.ietf.org. Hämtad 7 februari 2019. Arkiverad från originalet 2 augusti 2020.
4. ↑ P.V. Mockapetris. Domännamn - koncept och faciliteter  . tools.ietf.org. Hämtad 7 februari 2019. Arkiverad från originalet 23 juni 2018.
5. ↑ P.V. Mockapetris. Domännamn - implementering och specifikation  (engelska) . tools.ietf.org. Hämtad 7 februari 2019. Arkiverad från originalet 3 april 2019.

Länkar

• DNS-  resurskatalog
• DNS & BIND-resurser Arkiverade 2 september 2006 på Wayback Machine 
• CircleID DNS  Society
• DNS Security Enhancement (DNSSEC  )
• IETF Working Committee on Extended DNS Specification (DNSEXT  )
• Root DNS Servers  webbplats
• Visa DNS-poster för en domän
• DNS Web Tools-katalog på dmoz.org Arkiverad 13 november 2018 på Wayback Machine 

Artiklar

• Översikt över system och typer av DNS-attacker

RFC:er

• RFC 1034  - Domännamn - Koncept och faciliteter
• RFC 1035  - Domännamn - Implementering och specifikation
• RFC 1912  - Vanliga DNS-drifts- och konfigurationsfel
• RFC 1591  - Domännamnssystemstruktur och delegering
• RFC 1713  - Verktyg för DNS-felsökning
• RFC 2606  - Reserverade DNS-namn på toppnivå