domännamnssystem



Internet är en outtömlig källa till kunskap, även när det gäller domännamnssystem. Århundraden av mänsklig kunskap om domännamnssystem har lagts och läggs fortfarande på nätet, och det är just därför som det är så svårt att få tillgång till det, eftersom det finns platser där det kan vara svårt eller till och med omöjligt att navigera. Vårt förslag är att du inte ska skeppsbrutet i ett hav av uppgifter om domännamnssystem och att du snabbt och effektivt ska kunna nå alla visdomens hamnar.

Med detta mål i åtanke har vi gjort något som går utöver det uppenbara, nämligen att samla in den mest aktuella och bäst förklarade informationen om domännamnssystem. Vi har också ordnat den på ett sätt som gör den lätt att läsa, med en minimalistisk och trevlig design som garanterar den bästa användarupplevelsen och den kortaste laddningstiden. Vi gör det enkelt för dig så att allt du behöver oroa dig för är att lära dig allt om domännamnssystem! Så om du tycker att vi har uppnått vårt syfte och du redan vet vad du ville veta om domännamnssystem, vill vi gärna ha dig tillbaka i sapientiasv.com:s lugna hav när din hunger efter kunskap väcks på nytt.

Domain Name System (DNS)
Familj: Internetprotokollfamilj
Driftområde: Namnupplösning
Hamnar:

53 / UDP
53 / TCP
853 / TCP (endast med TLS, RFC 7858 )
853 / UDP (endast med DTLS , RFC 8094 )

DNS på TCP / IP-protokollstacken :
Ansökan DNS
transport UDP TCP
Internet IP ( IPv4 , IPv6 )
Nätverkstillgång Ethernet Token
buss
Token
ring
FDDI ...
Standarder: RFC 1034 (1987)

RFC 1035 (1987)

Den Domain Name System ( DNS ) är en av de viktigaste tjänsterna i många IP -baserade nät . Dess huvudsakliga uppgift är att svara på förfrågningar om namnupplösning .

DNS fungerar på samma sätt som katalogförfrågningar. Användaren känner till domänen (namnet på en dator på Internet som människor kan komma ihåg) - till exempel example.org. Det skickar detta som en begäran på Internet. Domänen konverteras sedan av DNS till tillhörande IP-adress ("anslutningsnummer" på Internet) - till exempel en IPv4- adress i formuläret 192.0.2.42eller en IPv6- adress som 2001:db8:85a3:8d3:1319:8a2e:370:7347- och leder därmed till rätt dator.

Översikt

DNS är en hierarkisk katalogtjänst som distribueras på tusentals servrar över hela världen som hanterar namnområdet på Internet. Detta namnområde är uppdelat i så kallade zoner , för vilka oberoende administratörer är ansvariga. För lokala krav - till exempel inom ett företagsnätverk - är det också möjligt att driva en DNS som är oberoende av Internet.

DNS används främst för att konvertera domännamn till IP-adresser ( framåtriktad uppslagning ). Detta kan jämföras med en telefonbok som tar upp namnen på deltagarna i deras telefonnummer. DNS erbjuder alltså en förenkling eftersom människor kan komma ihåg namn mycket bättre än siffror. Detta gör det lättare att komma ihåg ett domännamn som exempel.org än tillhörande IP-adress 192.0.32.10. Denna punkt blir ännu viktigare under introduktionen av IPv6 , för då tilldelas IPv4- och IPv6-adresser ett namn. Till exempel bryter namnet www.kame.net upp i IPv4-adressen 203.178.141.194och IPv6-adressen 2001:200:dff:fff1:216:3eff:feb1:44d7.

En annan fördel är att IP-adresser - till exempel från webbservrar - kan ändras med relativt liten risk. Eftersom Internetanvändare endast adresserar (oförändrat) DNS-namn är ändringar i den underordnade IP-nivån till stor del dolda för dem. Eftersom flera IP-adresser kan tilldelas ett namn kan även en enkel belastningsfördelning via DNS ( lastbalansering ) implementeras.

Med DNS är en omvänd upplösning av IP-adresser i namn ( omvänd uppslagning ) också möjlig. I analogi med telefonboken motsvarar detta en sökning efter namnet på en abonnent för ett känt telefonnummer, vilket är känt inom telekommunikationsindustrin som en invers sökning .

DNS designades av Paul Mockapetris 1983 och beskrivs i RFC 882 och RFC 883 (RFC = begäran om kommentarer ). Båda har nu ersatts av RFC 1034 och RFC 1035 och kompletterats med många andra standarder. Den ursprungliga uppgiften var att ersätta de lokala värdfilerna , som fram till dess var ansvariga för namnupplösning och som inte längre kunde klara det enormt ökande antalet nya poster. På grund av den beprövade höga tillförlitligheten och flexibiliteten integrerades ytterligare databaser gradvis i DNS och gjordes tillgängliga för Internetanvändare (se nedan: Förlängning av DNS ).

DNS kännetecknas av:

  • decentraliserad administration,
  • hierarkisk strukturering av namnområdet i trädform,
  • Namnens unikhet,
  • Expanderbarhet.

Komponenter

Domännamnsområde

Domännamnsområdet har en trädformad struktur. De blad och noder trädet kallas etiketter. Ett fullständigt domännamn för ett objekt består av sammankoppling av alla sökvägar.

Etiketter är teckensträngar som är minst en byte och högst 63 byte långa ( RFC 2181 , avsnitt 11. Namnsyntax). Enskilda etiketter är åtskilda från varandra med prickar. Ett domännamn slutar med en period (den sista perioden är vanligtvis utelämnad, men är rent formellt en del av ett fullständigt domännamn). Således är ett korrekt, komplett domännamn (även kallat fullt kvalificerat domännamn (FQDN) ) till exempel www.example.com. och kan vara maximalt 255 byte lång inklusive alla punkter.

Ett domännamn delegeras alltid och löses från höger till vänster, det vill säga ju längre till höger en etikett är, desto högre är den i trädet. Poängen till höger om ett domännamn skiljer etiketten för den första nivån i hierarkin från roten (engelska roten ). Denna första nivå kallas också toppdomänen (TLD). DNS-objekten för en domän (till exempel datornamnen) förvaras vanligtvis som en uppsättning resursposter i en zonfil som är tillgänglig på en eller flera auktoritativa namnservrar. Ju mer allmän term zonen används vanligen i stället för zonfilen .

Namnserver

En namnserver är en server som erbjuder namnupplösning . Namnupplösning är den process som gör det möjligt att lösa namnen på datorer eller tjänster till en adress som kan behandlas av datorn (t.ex. www.wikipedia.org i 91.198.174.192 ).

De flesta namnservrar är en del av domänsystemet som också används på Internet .

Å ena sidan är namnservrar program som svarar på frågor om domännamnsutrymmet på grundval av en DNS- databas . I språkbruk kallas dock datorer där dessa program används också namnservrar. Man gör en åtskillnad mellan auktoritativa och icke-auktoritativa namnservrar.

En auktoritativ namnserver är ansvarig för en zon. Hans information om denna zon anses därför vara säker . För varje zon finns minst en auktoritativ server, den primära namnservern. Detta listas i SOA-resursposten för en zonfil . Av redundans och belastningsbalanseringsskäl är auktoritativa namnservrar nästan alltid som en server - Cluster realiseras, där zondata är identiska med en eller flera sekundära namnservrar. Synkroniseringen mellan primära och sekundära namnservrar sker via zonöverföring .

En icke-auktoritativ namnserver får sin information om en zon från andra namnservrar från andra eller tredje hand, så att säga. Hans information anses inte vara säker . Eftersom DNS-data normalt bara ändras mycket sällan sparar icke-auktoritativa namnservrar den information som en resolver begär i det lokala RAM-minnet så att den är tillgänglig snabbare när en ny begäran görs. Denna teknik kallas cachning . Var och en av dessa poster har sitt eget utgångsdatum ( TTL- tid att leva ), varefter posten raderas från cachen. TTL bestäms av en auktoritativ namnserver för denna post och bestäms utifrån sannolikheten för att posten ändras (DNS-data som ändras ofta får låg TTL). Under vissa omständigheter kan detta innebära att namnservern ger fel information under denna tid om data har ändrats under tiden.

Caching-endast namnservern är ett specialfall. I detta fall är namnservern inte ansvarig för någon zon och måste lösa alla inkommande förfrågningar via andra namnservrar (vidarebefordrare). Olika strategier finns tillgängliga för detta:

Samarbete mellan de enskilda namnservrarna

För att en icke-auktoritativ namnserver kan hitta information om andra delar av namnområdet använder den följande strategier:

Delegation
Delar av namnområdet för en domän läggs ofta ut på underdomäner med egna ansvariga namnservrar. En namnserver på en domän känner till namnservern som är ansvarig för dessa underdomäner från sin zonfil och delegerar förfrågningar om detta underordnade namnområde till en av dessa namnservrar.
Spedition
Om det begärda namnområdet ligger utanför din egen domän vidarebefordras begäran till en permanent konfigurerad namnserver.
Upplösning via rotnamnservern
Om ingen vidarebefordringsserver har konfigurerats eller om den inte svarar frågas rotnamnservrarna. För detta ändamål lagras namnen och IP-adresserna på rotservrarna i form av en statisk fil. Det finns 13 rotservrar (servrarna A till M). Rotservrarna svarar bara på iterativa frågor. Annars skulle du helt enkelt bli överbelastad med antalet förfrågningar.

Olika tänkta namnupplösningar från servrar, såsom NetWare Name Service eller Windows Internet Naming Service , är oftast begränsade till lokala nätverk och ersätts alltmer av Internetprotokollfamiljen .

Resolver

Resolvers är helt enkelt strukturerade programvarumoduler som installeras på en DNS-deltagares dator och kan hämta information från namnservrar. De bildar gränssnittet mellan applikationen och namnservern. Upplösaren accepterar begäran från en applikation, kompletterar den vid behov till en FQDN och överför den till en normalt permanent tilldelad namnserver. En resolver fungerar antingen rekursivt eller iterativt.

I rekursivt läge skickar resolvern en rekursiv begäran till namnservern som tilldelats den. Om han inte har önskad information i sin egen databas, kontaktar namnservern andra servrar - tills han får svar; antingen positiv eller negativ från en auktoritär server. Resolver som arbetar rekursivt lämnar arbetet för fullständig upplösning till namnservern.

I fallet med en iterativ fråga får resolver antingen önskad resurspost eller en hänvisning till andra namnservrar som den frågar nästa. Upplösaren fungerar från namnserver till namnserver tills den får ett bindande svar från en av dem.

Upplösaren överför svaret som erhållits på detta sätt till programmet som begärde informationen, till exempel till webbläsaren . Vanliga klienters lösare arbetar exklusivt rekursivt; de kallas sedan också stub resolvers. Namnservrar har vanligtvis sin egen resolver. Dessa fungerar vanligtvis iterativt .

Välkända program för att kontrollera namnupplösningen är nslookup , host och dig .

protokoll

DNS-förfrågningar skickas vanligtvis till namnservern via UDP- port 53. DNS-standarden kräver dock också att TCP stöds för frågor vars svar är för stora för UDP-överföringar. Om utökad DNS inte används (EDNS) är den maximalt tillåtna längden på DNS-UDP-paketet 512 byte . Alltför långa svar överförs därför trunkerade. Den begärande klienten informeras om detta genom att ställa in den avkortade flaggan. Han måste sedan avgöra om svaret är tillräckligt för honom eller inte. Vid behov upprepar den begäran via TCP-port 53.

Zonöverföringar utförs alltid via port 53 TCP. Men zonöverföringar utlöses vanligtvis via UDP.

DNS-databasens struktur

Domännamnssystemet kan ses som en distribuerad databas med en trädliknande struktur. Med internet-DNS lagras data på ett stort antal servrar utspridda runt om i världen, som är länkade till varandra via referenser - kallade delegationer i DNS-terminologi .

I varje inblandad namnserver finns en eller flera filer - de så kallade zonfilerna - som innehåller alla relevanta data. Dessa filer är listor över resursposter . Sju skivtyper är av stor betydelse:

  • Med SOA-resursposten kan parametrar för zonen , till exempel B. Giltighetstid eller serienummer.
  • Länkarna ( delegationerna ) mellan servrarna implementeras med NS Resource Record .
  • De faktiska uppgifterna definieras med följande posttyper:
    • En A-resurspost tilldelar ett namn en IPv4- adress.
    • En AAAA-resurspost tilldelar ett namn en IPv6- adress.
    • En CNAME-resurspost hänvisar från ett namn till ett annat namn.
    • En MX-resurspost tilldelar ett e-postserver ett namn . Det är speciellt eftersom det avser en speciell tjänst på Internet, nämligen e-postleverans med SMTP . Alla andra tjänster använder resurser för CNAME , A och AAAA för namnupplösning.
    • En PTR-resurspost tilldelar ett namn till en IP-adress ( omvänd uppslagning ) och används lika för IPv4 och IPv6, endast för IPv4 under domänen "IN-ADDR.ARPA." Och för IPv6 under "IP6.ARPA.".
    • En TXT-resurspost kan tilldela ett namn som kan definieras fritt. En möjlig användning här är att avvärja skräppost .

Med tiden definierades nya typer med vilka förlängningar av DNS realiserades. Denna process pågår fortfarande. En omfattande lista finns under Resource Record .

Exempel:

Följande NS-resurspost definieras i zonfilen för domänen "org.": Zonfilen för domänen "exempel.org." Finns på servern "ns0.example.org.". Poängen i slutet är viktig eftersom det gör det klart att inget släktnamn är avsett, så det finns inget att lägga till efter "org". "IN" betyder att posten har klassen "Internet" och numret framför det betyder Time To Live (TTL) på några sekunder, det står hur länge denna information kan lagras tillfälligt i en cache innan den ska begäras igen . Med dynamiska IP-adresser ligger detta nummer vanligtvis mellan 20 och 300 sekunder.

example   86400  IN  NS   ns0.example.org.

Följande CNAME-resurspost definieras i zonfilen för domänen "exempel.org.": Namnet "de.example.org." Avser namnet "rr.example.net.".

de          3600   IN  CNAME   rr.example.net.

Definiera följande resursposter i zonfilen för domänen "exempel.net": Namnet "rr.example.net." Avser namnet "rr.esams.example.net." Och detta tilldelas i sin tur IPv4 adress 203.0.113.232.

rr          600    IN  CNAME   rr.esams
rr.esams    3600   IN  A       203.0.113.232

I slutändan måste alla datorer som vill ansluta till de.example.org. 203.0.113.232Skicka IPv4-paket till IP-adressen .

Lösning av en DNS-begäran

Antag att en dator X vill upprätta en anslutning till de.wikipedia.org. (Dator Y ). För att göra detta behöver han sin IP-adress. Följande steg beskriver hur detta kan göras. Om datorn X är IPv6-kompatibel körs processen först för IPv6 (fråga från AAAA resurspost ) och omedelbart därefter för IPv4 (fråga från A resurspost ). En begäran om en IPv6-adress kan skickas till en IPv4 DNS-server med IPv4-överföring. Om i slutändan en IPv6- och en IPv4-adress bestäms för dator Y föredras vanligtvis kommunikation mellan X och Y via IPv6 enligt standardpolicytabellen i RFC 6724 , såvida inte i operativsystemet eller i de applikationer som används, t.ex. webbläsare har detta beteende ställts in annorlunda.

  1. Computer X söker i sin värdfil för att se om IP-adressen för de.wikipedia.org är lagrad där. Om detta inte är fallet frågar han DNS-servern. Detta anges antingen permanent eller tilldelades automatiskt via DHCP eller DHCPv6 och har formulärnamnservern 192.0.2.23 eller namnserver 2001: db8 :: 23: café: affe: 42 .
  2. Om DNS-servern på dator X har cachat en IP-adress för det begärda namnet svarar den med den och begäran upphör (se sista punkten). Annars frågar en av de 13 rotnamnsservrar för "de.wikipedia.org.".
  3. Rotsnamnsservern får reda på att upplösningen för detta namn fortsätter i zonen "org." Och skickar namnen och IP-adresserna till "org." Namnservrarna ( NS Resource Records och deras AAAA- eller A Resource Records ) till DNS server på datorn X .
  4. Nu ber DNS-servern på dator X en av namnservrarna om "org." Domäner för "de.wikipedia.org.".
  5. "Org." Namnservern skickar honom namnen på namnservrarna (och deras IP-adresser, förutsatt att de tillhör samma toppdomän) för zonen "wikipedia.org.".
  6. DNS-servern dator X frågar sedan en wikipedia.org. Name server som IP-adressen för namnet de.wikipedia.org..
  7. Den här adressen används för att svara till DNS-servern på dator X och ...
  8. ... skickar dem till dator X , som nu till exempel kan skicka sina HTTP- förfrågningar till IP-adressen "de.wikipedia.org.".

Exempel på upplösning av namn

I följande exempel med kommentarer bestäms IPv4-adressen för namnet "www.heise.de." Med hjälp av resolververktyget dig . " +trace" Betyder att de enskilda svaren på iterativa frågor till namnserverhierarkin ges, " +additional" säkerställer att det också visas att namnservrarna inte bara hanterar NS-resursposter för delegationer utan också deras IP-adresser i form av vissa Know om A- eller AAAA-resursposter och leverera dem med dem, " -t A" ber slutligen om A-resursposten , dvs IPv4-adressen. Det visar sig att fyra namnservrar måste ifrågasättas efter varandra för att komma fram till svaret:

$ dig +trace +additional -t A www.heise.de.
; <<>> DiG 9.5.1-P3 <<>> +trace +additional -t A www.heise.de.
;; global options:  printcmd
.                       6086    IN      NS      B.ROOT-SERVERS.NET.
.                       6086    IN      NS      D.ROOT-SERVERS.NET.
.                       6086    IN      NS      J.ROOT-SERVERS.NET.
.                       6086    IN      NS      G.ROOT-SERVERS.NET.
.                       6086    IN      NS      K.ROOT-SERVERS.NET.
.                       6086    IN      NS      C.ROOT-SERVERS.NET.
.                       6086    IN      NS      M.ROOT-SERVERS.NET.
.                       6086    IN      NS      I.ROOT-SERVERS.NET.
.                       6086    IN      NS      H.ROOT-SERVERS.NET.
.                       6086    IN      NS      E.ROOT-SERVERS.NET.
.                       6086    IN      NS      F.ROOT-SERVERS.NET.
.                       6086    IN      NS      A.ROOT-SERVERS.NET.
.                       6086    IN      NS      L.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.     6644    IN      A       128.8.10.90
J.ROOT-SERVERS.NET.     10421   IN      A       192.58.128.30
J.ROOT-SERVERS.NET.     1289    IN      AAAA    2001:503:c27::2:30
G.ROOT-SERVERS.NET.     10940   IN      A       192.112.36.4
K.ROOT-SERVERS.NET.     4208    IN      A       193.0.14.129
K.ROOT-SERVERS.NET.     7277    IN      AAAA    2001:7fd::1
C.ROOT-SERVERS.NET.     6126    IN      A       192.33.4.12
M.ROOT-SERVERS.NET.     3274    IN      A       202.12.27.33
M.ROOT-SERVERS.NET.     7183    IN      AAAA    2001:dc3::35
I.ROOT-SERVERS.NET.     9788    IN      A       192.36.148.17
H.ROOT-SERVERS.NET.     10421   IN      A       128.63.2.53
H.ROOT-SERVERS.NET.     13739   IN      AAAA    2001:500:1::803f:235
E.ROOT-SERVERS.NET.     11125   IN      A       192.203.230.10
F.ROOT-SERVERS.NET.     9973    IN      A       192.5.5.241
;; Received 500 bytes from 192.168.2.1#53(192.168.2.1) in 50 ms

192.168.2.1(se sista raden) är den registrerade namnservern på frågedatorn, som hänvisar till rotnamnservern , som alla kan frågas via IPv4, vissa också via IPv6. Rotsnamnservrarna hanterar rotzonen (zon som innehåller namnservrarna för .org, .de, .com och andra toppnivådomäner) för namnupplösning, representerad av en punkt. IP-adresserna till rotnamnservrarna ändras väldigt sällan och måste vara kända för alla namnservrar om de svarar på frågor som rör Internet. (Dessa IP-adresser kan till exempel tillhandahållas i en textfil som heter "Root Hints".)

de.                     172800  IN      NS      F.NIC.de.
de.                     172800  IN      NS      L.DE.NET.
de.                     172800  IN      NS      S.DE.NET.
de.                     172800  IN      NS      Z.NIC.de.
de.                     172800  IN      NS      A.NIC.de.
de.                     172800  IN      NS      C.DE.NET.
A.NIC.de.               172800  IN      A       194.0.0.53
C.DE.NET.               172800  IN      A       208.48.81.43
F.NIC.de.               172800  IN      A       81.91.164.5
F.NIC.de.               172800  IN      AAAA    2001:608:6:6::10
L.DE.NET.               172800  IN      A       89.213.253.189
S.DE.NET.               172800  IN      A       195.243.137.26
Z.NIC.de.               172800  IN      A       194.246.96.1
Z.NIC.de.               172800  IN      AAAA    2001:628:453:4905::53
;; Received 288 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET) in 58 ms

I.ROOT-SERVERS.NET. Valdes slumpmässigt från de 13 namngivna rotnamnservrarna för att fråga honom om www.heise.de.. Han svarade med sex namnservrar att välja mellan, som är ansvariga för zonen "de.". Även här är det möjligt att fråga med IPv6 med två servrar.

heise.de.               86400   IN      NS      ns.plusline.de.
heise.de.               86400   IN      NS      ns.heise.de.
heise.de.               86400   IN      NS      ns2.pop-hannover.net.
heise.de.               86400   IN      NS      ns.pop-hannover.de.
heise.de.               86400   IN      NS      ns.s.plusline.de.
ns.s.plusline.de.       86400   IN      A       212.19.40.14
ns.heise.de.            86400   IN      A       193.99.145.37
ns.plusline.de.         86400   IN      A       212.19.48.14
ns.pop-hannover.de.     86400   IN      A       193.98.1.200
;; Received 220 bytes from 81.91.164.5#53(F.NIC.de) in 52 ms

"F.NIC.de." valdes slumpmässigt ut från de sex namngivna servrarna för att ta reda på mer om "www.heise.de.". Han svarade på frågan med fem möjliga delegationer. Bland annat med en delegation till servern "ns.heise.de." Den här informationen skulle utan motsvarande A-resurspost , vid 193.99.145.37visning, inte hjälpa på samma server, eftersom namnet är i zonen "heise.de." Att den hanterar sig själv. Man talar i denna typ av information också lim poster (på engelska. Lim , lim). Om servern ns2.pop-hannover.net. Väljs för nästa steg måste dess IP-adress först bestämmas i en separat namnupplösning, eftersom den inte skickades hit.

www.heise.de.           86400   IN      A       193.99.144.85
heise.de.               86400   IN      NS      ns.pop-hannover.de.
heise.de.               86400   IN      NS      ns.plusline.de.
heise.de.               86400   IN      NS      ns2.pop-hannover.net.
heise.de.               86400   IN      NS      ns.s.plusline.de.
heise.de.               86400   IN      NS      ns.heise.de.
ns.heise.de.            86400   IN      A       193.99.145.37
ns.pop-hannover.de.     10800   IN      A       193.98.1.200
ns2.pop-hannover.net.   86400   IN      A       62.48.67.66
;; Received 220 bytes from 193.98.1.200#53(ns.pop-hannover.de) in 4457 ms

Från de fem namngivna servrarna, "ns.pop-hannover.de." Används slumpmässigt för att svara på frågan om "www.heise.de.". Svaret är 193.99.144.85. Detta innebär att begäran har nått sin destination. Återigen namnges samma namnservrar som ansvariga för heise.de., Utan att hänvisa till andra namnservrar.

Exempel på omvänd uppslagning

För den omvända sökningen , dvs att hitta ett namn för en IP-adress, omvandlas IP-adressen först formellt till ett namn, för vilket DNS efterfrågas för en PTR-resurspost . Eftersom hierarkin för IP-adresser är mer specifik från vänster till höger (se undernät ), men för DNS från höger till vänster, är det första steget att omvända ordningen på siffrorna och IPv4-adressen 193.99.144.85blir t.ex. Till exempel genereras namnet " 85.144.99.193.in-addr.arpa." och 2a02:2e0:3fe:100::6namnet " 6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.e.f.3.0.0.e.2.0.2.0.a.2.ip6.arpa." från IPv6-adressen . (Det här namnet är långt eftersom de implicita nollorna nu måste nämnas igen uttryckligen.)

Den PTR resurspost för den konverterade IPv4-adress kan bestämmas på samma sätt som i föregående exempel:

$ dig +trace +additional -t PTR 85.144.99.193.in-addr.arpa.
; <<>> DiG 9.5.1-P3 <<>> +trace +additional -t ptr 85.144.99.193.in-addr.arpa.
;; global options:  printcmd
.                       2643    IN      NS      M.ROOT-SERVERS.NET.
.                       2643    IN      NS      A.ROOT-SERVERS.NET.
.                       2643    IN      NS      B.ROOT-SERVERS.NET.
.                       2643    IN      NS      C.ROOT-SERVERS.NET.
.                       2643    IN      NS      D.ROOT-SERVERS.NET.
.                       2643    IN      NS      E.ROOT-SERVERS.NET.
.                       2643    IN      NS      F.ROOT-SERVERS.NET.
.                       2643    IN      NS      G.ROOT-SERVERS.NET.
.                       2643    IN      NS      H.ROOT-SERVERS.NET.
.                       2643    IN      NS      I.ROOT-SERVERS.NET.
.                       2643    IN      NS      J.ROOT-SERVERS.NET.
.                       2643    IN      NS      K.ROOT-SERVERS.NET.
.                       2643    IN      NS      L.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.     10978   IN      A       198.41.0.4
A.ROOT-SERVERS.NET.     2470    IN      AAAA    2001:503:ba3e::2:30
C.ROOT-SERVERS.NET.     387     IN      A       192.33.4.12
D.ROOT-SERVERS.NET.     2747    IN      A       128.8.10.90
E.ROOT-SERVERS.NET.     7183    IN      A       192.203.230.10
F.ROOT-SERVERS.NET.     14225   IN      AAAA    2001:500:2f::f
H.ROOT-SERVERS.NET.     7950    IN      A       128.63.2.53
H.ROOT-SERVERS.NET.     13245   IN      AAAA    2001:500:1::803f:235
I.ROOT-SERVERS.NET.     6172    IN      A       192.36.148.17
J.ROOT-SERVERS.NET.     7168    IN      A       192.58.128.30
J.ROOT-SERVERS.NET.     13860   IN      AAAA    2001:503:c27::2:30
K.ROOT-SERVERS.NET.     3541    IN      A       193.0.14.129
K.ROOT-SERVERS.NET.     9369    IN      AAAA    2001:7fd::1
L.ROOT-SERVERS.NET.     3523    IN      A       199.7.83.42
;; Received 512 bytes from 192.168.2.1#53(192.168.2.1) in 50 ms
193.in-addr.arpa.       86400   IN      NS      ns3.nic.fr.
193.in-addr.arpa.       86400   IN      NS      sec1.apnic.net.
193.in-addr.arpa.       86400   IN      NS      sec3.apnic.net.
193.in-addr.arpa.       86400   IN      NS      sunic.sunet.se.
193.in-addr.arpa.       86400   IN      NS      ns-pri.ripe.net.
193.in-addr.arpa.       86400   IN      NS      sns-pb.isc.org.
193.in-addr.arpa.       86400   IN      NS      tinnie.arin.net.
;; Received 239 bytes from 199.7.83.42#53(L.ROOT-SERVERS.NET) in 170 ms
99.193.in-addr.arpa.    172800  IN      NS      auth50.ns.de.uu.net.
99.193.in-addr.arpa.    172800  IN      NS      ns.ripe.net.
99.193.in-addr.arpa.    172800  IN      NS      auth00.ns.de.uu.net.
;; Received 120 bytes from 202.12.28.140#53(sec3.apnic.net) in 339 ms
144.99.193.in-addr.arpa. 86400  IN      NS      ns.heise.de.
144.99.193.in-addr.arpa. 86400  IN      NS      ns.s.plusline.de.
144.99.193.in-addr.arpa. 86400  IN      NS      ns.plusline.de.
;; Received 114 bytes from 194.128.171.99#53(auth50.ns.de.uu.net) in 2456 ms
85.144.99.193.in-addr.arpa. 86400 IN    PTR     www.heise.de.
144.99.193.in-addr.arpa. 86400  IN      NS      ns.heise.de.
144.99.193.in-addr.arpa. 86400  IN      NS      ns.s.plusline.de.
144.99.193.in-addr.arpa. 86400  IN      NS      ns.plusline.de.
ns.heise.de.            86400   IN      A       193.99.145.37
;; Received 148 bytes from 193.99.145.37#53(ns.heise.de) in 4482 ms

Så svaret är "www.heise.de.". Det är emellertid inte nödvändigt att ett namn tilldelas varje IP-adress, och heller inte framåt- och bakåtupplösningarna måste motsvara varandra. Upplösningen börjar igen med hänvisningen till rotnamnservern och delegationerna uppenbarligen äger rum vid gränserna mellan siffrorna markerade med punkter. Du kan dock också se i exemplet att det inte finns något behov av att delegera i ett namn vid varje punkt.

Tillägg

Eftersom DNS har visat sig vara pålitligt och flexibelt har flera viktiga förbättringar införts genom åren. Det finns inget slut i sikte på denna trend.

Dynamisk DNS

I klassisk DNS är det tidskrävande att tilldela ett namn till en ny IP-adress. Den associerade zonfilen måste ändras (vanligtvis manuellt) och namnservern laddas om. Tidsfördröjningar på upp till flera dagar är vanliga. Med dynamisk DNS kan ändringar göras genom att skicka en uppdateringsförfrågan med kort tidsfördröjning.

Dynamisk DNS är en säkerhetsrisk eftersom vem som helst kan radera eller ändra DNS-poster utan särskilda försiktighetsåtgärder. Dynamisk DNS är nästan absolut nödvändig i samband med DHCP , eftersom nya IP-adresser ofta tilldelas en användare. DHCP-servern skickar ett motsvarande meddelande till namnservern varje gång adressen ändras.

internationalisering

Tidigare var etiketterna begränsade till alfanumeriska tecken och '-' karaktären. '_' Är också möjligt för underdomäner, men inte i enlighet med standarden. Denna begränsade uppsättning tecken beror främst på att DNS (som Internet ursprungligen) utvecklades i USA . Som ett resultat var tecken som vanligen används i många länder (i den tysktalande världen, till exempel umlauterna ä, ö och ü samt ß) eller tecken från helt olika skrivsystem (t.ex. kinesiska) ursprungligen inte möjliga i domännamn .

En under tiden etablerad metod för att öka teckenuppsättningen är internationaliseringen av domännamn (IDNA) som introducerades 2003 i RFC 3490 och uppdaterades 2010 med RFC 5890 . För att hålla det nya systemet kompatibelt med det tidigare kodas de utökade teckenuppsättningarna med de tecken som tidigare var tillåtna. De utökade teckenuppsättningarna normaliseras först för att mappa stora bokstäver till bland annat små bokstäver och mappas sedan till en ASCII-kompatibel sträng med Punycode . IDNA kräver en anpassning av nätverksapplikationerna ( t.ex. webbläsare ), men namnserverinfrastrukturen (server, resolver) behöver inte ändras. Sedan mars 2004 kan tyska, Liechtenstein, österrikiska och schweiziska domäner (.de, .li, .at och .ch) med paraplyer registreras och användas i tysktalande länder. Internationaliserade domännamn kan också användas för andra toppdomäner , särskilt i Asien.

Utökad DNS

År 1999 beskrev Paul Vixie några mindre, nedåtkompatibla tillägg till Domain Name System i RFC 2671 , som kallas för utökad DNS- version 0. Genom att använda en pseudo-post som ett header-tillägg kan den begärande parten ställa in ytterligare alternativ. I synnerhet kan den förmedla att den kan ta emot UDP-svar som är större än 512 byte. DNSSEC- kapabla servrar och resolvers måste kunna EDNS.

Hantering av telefonnummer

ENUM ( RFC 2916 ) representerar en ytterligare aktuell förlängning av DNS: Denna applikation möjliggör adressering av internettjänster via telefonnummer, dvs "uppringning" av enheter som är tillgängliga via Internet med det numreringsschema som är känt från telefonnätet. Från det breda utbudet av möjliga användningsområden är det särskilt lämpligt för Voice over IP- tjänster.

RFID-stöd

Med RFID kan ID: n lagras på speciella RFID-etiketter - så kallade elektroniska produktkoder eller EPC: er - läsas utan kontakt. DNS kan användas för att bestämma servern för ett ID som innehåller data om det associerade objektet. Den Object Naming Service ONS omvandlar EPC i ett DNS-namn och ber om en eller flera Naming Authority pekare NAPTR via standard DNS.

Spamskydd

För att filtrera skräppost , kontrollerar många e- postservrar rutinmässigt DNS-posten för den sändande e-postservern med omvänd DNS- sökning. Detta får inte bara lösa rätt framåt och peka på IP-adressen till det sändande systemet ( framåt bekräftad omvänd DNS ), utan måste också motsvara HELO-värdnamnet för det sändande systemet som anges i SMTP-protokollet.

Ett försök görs för att förhindra att förfalskade avsändare skickas av tredje part med hjälp av Sender Policy Framework . För varje e-postdomän används en speciell SPF-resurspost för att uttryckligen lista de servrar och IP-nätverk som e-postmeddelanden för denna domän kan förväntas från. Men SPF har utsatts för många tekniska svårigheter, såsom omdirigeringar.

Anti-spam-mekanismen DomainKeys (DKIM) använder också poster i DNS, eftersom sändande postservrar publicerar sin offentliga nyckel i DNS TXT-poster, som kan användas för att verifiera signaturen för deras utgående e-post.

diverse

Förutom IP-adresserna kan DNS-namn också tilldelas ISDN- nummer, X.25- adresser, ATM- adresser, allmänna nycklar , textrader etc. I praktiken är dock sådana tillämpningar undantaget.

DNS i det lokala nätverket

DNS är inte begränsat till Internet. Det är lätt möjligt och kompatibelt med definitionen att ställa in separata zoner i namnservern för upplösning av lokala namn och att ange motsvarande adresser där. Engångsinstallationen är också värdefull för relativt små nätverk, eftersom alla adresser i nätverket sedan kan hanteras centralt.

I större företag eller organisationer påträffas ofta ett blandat system bestående av lokal DNS och internet (split DNS). De interna användarna får åtkomst till lokal DNS och de externa användarna har tillgång till Internet. I praktiken kan detta leda till mycket komplicerade konstellationer.

DNS-servern BIND kan också fungera med DHCP och därmed möjliggöra namnupplösning för varje klient i nätverket.

Det finns en annan namnupplösningstjänst under Windows - WINS , som ger en liknande funktion men använder ett annat protokoll.

DNS-servernätverk

Det är möjligt att ansluta flera DNS-servrar. De servrar som utsetts som master är ansvariga för en eller flera domäner. Slavarna uppdaterar själva data efter en förändring, mastern distribuerar inte dessa data automatiskt. Uppgifterna samlas in via en zonöverföring .

Till exempel kan ett företag med flera platser driva en master för sin interna DNS på ett ställe, som levererar servrarna på filialkontoren. Med BIND görs zonöverföringen via TCP (som standardport 53) och det rekommenderas att du behöver autentisering. Slavarna uppdaterar sig om serienumret för en zonfil ändras eller om de får ett motsvarande meddelande från mastern. Släppet för överföringsporten bör länkas till masterns IP-adress via en brandvägg. Med andra programvarupaket kan data synkroniseras på andra sätt, till exempel genom LDAP-replikering, rsync eller andra mekanismer.

säkerhet

DNS är en central komponent i en nätverksansluten IT-infrastruktur. En störning kan leda till betydande kostnader och korruption av DNS-data kan vara utgångspunkten för attacker.

Former av attack

Huvudsyftet med DNS-attacker är att manipulera DNS-deltagare för att rikta dem till falska webbplatser för att därefter få lösenord, PIN-koder, kreditkortsnummer etc. I sällsynta fall görs försök att helt stänga av Internet-DNS med hjälp av denial-of-service- attacker och därmed förlama Internet. DNS kan också användas för att intensifiera riktade attacker mot individer eller företag.

DDoS-attack på namnservrar

I en distribuerad denial of service- attack överbelastas namnservrar av en hög dataström med DNS-frågor, så att legitima frågor inte längre kan besvaras. Det finns för närvarande inget försvar mot DDoS-attacker på namnservrar. Som en förebyggande åtgärd kan ett försök endast göras att dimensionera namnservrarna i enlighet med detta eller att installera ett distribuerat nätverk med så många servrar som möjligt. För att generera ett stort antal DNS-frågor används botnät i sådana attacker .

En DDoS-attack kan oavsiktligt påverka en DNS-server och få den att misslyckas om domännamnet för attackmålet löses upprepade gånger utan att cachas. Effekten på DNS-servrar förhindras om DDoS-skadlig programvara använder DNS-cachning .

DNS-förstärkningsattack

Den DNS förstärknings attack är en denial-of-service attack där själva målet är inte DNS-servern i sig, men en tredje part. Det faktum att en DNS-server ibland skickar tillbaka mycket långa svar på korta frågor utnyttjas. En falsk avsändaradress skickar dessa till offrets IP-adress. En angripare kan använda detta för att avsevärt öka dataströmmen som kommer från honom och därmed störa internetanslutningen för sitt mål.

DNS-förfalskning

Med DNS-förfalskning får en begärande klient en felaktig IP-adress som svar för att leda den till en falsk eller falsk webbplats (t.ex. i syfte att internetcensur eller nätfiske ).

Cacheförgiftning

Med cacheförgiftning skickas en begärande klient manipulerad data utöver rätt svar, som den senare överför till sin cache och senare används, eventuellt okontrollerad.

Öppna DNS-servern

Den som driver en auktoritativ DNS-server för sina egna domäner måste naturligtvis vara öppen för förfrågningar från vilken IP-adress som helst. För att hindra Internetanvändare från att använda denna server som en allmän namnserver (t.ex. för attacker på rotservrar) tillåter BIND att svaren begränsas till sina egna domäner. Till exempel orsakar alternativet allow-recursion {127.0.0.1; 172.16.1.4;};rekursiva frågor, dvs. H. Frågor till andra domäner, exklusivt för den lokala värden (localhost) samt 172.16.1.4 besvaras. Alla andra IP-adresser får bara svar på frågor om sina egna domäner.

En öppen DNS-server kan också vara en fälla om den returnerar falska IP-adresser, se Pharming .

Förbättringar av säkerheten

Mer än tio år efter den ursprungliga specifikationen lades säkerhetsfunktioner till DNS. Följande procedurer är tillgängliga:

TSIG

TSIG (Transaction Signatures) är ett enkelt förfarande baserat på symmetriska nycklar med vilka datatrafiken mellan DNS-servrar och uppdateringar från klienter kan säkerställas.

DNSSEC

Med DNSSEC (DNS Security) används ett asymmetriskt kryptosystem . Förutom server-server-kommunikation kan klient-server-kommunikation också säkerställas. Detta ska göra det svårt att manipulera svaren.

DNS över TLS (DoT)

Med DNS över TLS , DDoS-attacker ska manipulation av svar och spionera på den skickade informationen förhindras. För detta ändamål skyddas DNS-frågorna med hjälp av Transport Layer Security (TLS).

DNS över HTTPS (DoH)

DNS över HTTPS ändrar i grund och botten DNS-systemet. Förfrågningar görs här på applikationsnivå. Applikationer som webbläsaren begär DNS-servern direkt istället för att vidarebefordra begäran till operativsystemet. Som ett resultat ser DNS-förfrågningar ut som normal internettrafik och kan därför inte avlyssnas eller blockeras på ett riktat sätt.

Cloudflare och Google erbjuder offentliga DoH-webbservrar. Mozilla Firefox har stöttat DoH som en experimentell funktion sedan version 60. I samarbete med Cloudflare tillhandahåller Mozilla en DoH-server som måste uppfylla strikta sekretesskrav.

DNS över QUIC (DoQ)

DNS över QUIC syftar till att kombinera fördelarna med DoT och DoH. DoQ bör erbjuda god integritet och säkerhet, ha låg latens och vara blockerbar. Det finns bara en DoQ-server som drivs av Internet Engineering Task Force , exakta specifikationer finns ännu inte.

Domänregistrering

För att göra DNS-namn kända på Internet måste ägaren registrera domänen som innehåller detta namn. Registreringen säkerställer att vissa formella regler följs och att domännamn är unika över hela världen. Domänregistreringar utförs av organisationer (register, t.ex. Verisign eller Afilias) som har godkänts av IANA eller ICANN . Registreringar (med några få undantag) är avgiftsbelagda. DENIC ansvarar för domäner under .de . I de allra flesta fall kan domäner bara registreras hos registren via mellanhänder, så kallade registratorer som Godaddy eller 1 & 1 Internet SE, som har ingått motsvarande kontrakt med registren.

Bonjour eller Zeroconf

När man utvecklade macOS gjorde Apple flera tillägg till DNS, vilket skulle möjliggöra en omfattande självkonfiguration av tjänster i LAN. Å ena sidan introducerades Multicast DNS ("mDNS"), som möjliggör namnupplösning i ett LAN utan en dedikerad namnserver. Dessutom infördes DNS-SD (för "DNS Service Discovery"), vilket möjliggör sökning ("surfning") för nättjänster i DNS eller mDNS. Hittills mDNS och DNS-SD är inte officiella RFC i den IETF , men ändå redan finns i olika (även gratis) implementationer. Tillsammans med ett antal andra tekniker kombinerar Apple DNS-SD och mDNS under namnet " Zeroconf ", som en del av OS X också som "Rendezvous" eller " Bonjour ". De flesta Linux-distributioner stöder denna tillägg t.ex. B. med avahi- implementeringen av Zeroconf.

Censur och alternativ DNS

Sedan debatterna om blockering av internetinnehåll i Tyskland och censur på Internet i allmänhet har det funnits ett antal alternativa DNS-leverantörer som säger att de inte censurerar domäner. Exempel är projekt från organisationer som Digitalcourage , Freifunk Munich eller Digital Society . Alternativa DNS-servrar tillhandahålls också av privatpersoner. Chaos Computer Clubs alternativa DNS-server har kritiserats för sin bristande säkerhet.

Namecoin

Namecoin är den första gaffeln i Bitcoin från 2011 och används som en kryptovaluta och som en nyckelvärdesbutik för domännamn och identiteter. Som ett alternativt distribuerat domännamnssystem (DNS) utanför ICANN- namnområdet registreras transaktioner för registrering, uppdatering och överföring av domäner i blockchain . En webbläsarplugg eller en lokal Namecoin DNS-server krävs för att lösa .bit-adresserna. Precis som Bitcoin är Namecoin ett decentraliserat peer-to-peer- system som inte är föremål för censur. Programvaran är öppen källkod och värd på GitHub .

Enligt en Trend Micro-rapport har .bit-domäner också använts alltmer av cyberbrottslingar sedan 2013 . Främst av denna anledning stoppade OpenNIC- projektet sin DNS-upplösning av .bit-domäner sommaren 2019.

Namnserverprogramvara

Val av välkänd programvara för namnupplösning.

  • BIND (Berkeley Internet Name Domain) är den mest använda programvaran för namnserver och är referensimplementeringen av de flesta RFC: er för DNS. Den första versionen av BIND var den första allmänt tillgängliga implementeringen av namnservern.
  • CoreDNS är en DNS-server skriven i Go av Cloud Native Computing Foundation .
  • djbdns har författaren Daniel J. Bernstein annonserat en bonus för att hitta säkerhetsproblem. Bernstein utvecklar inte längre Djbdns eftersom han ser det som färdigt.
  • Dnsmasq är en namnserver och DHCP-server med begränsad funktionalitet. Namnen från det lokala nätverket löses enligt / etc / hosts. Dnsmasq har inte en fullständig resolver: okända namnförfrågningar vidarebefordras och cachas.
  • Knot DNS är en auktoritativ namnserver utvecklad av CZ.NIC , operatören av .cz .
  • Microsoft Windows DNS är en av få kommersiella namnserverimplementeringar som en del av Microsoft Windows Server-serien . Namnservern stöder dynamiska uppdateringar, zonöverföringar och aviseringar. Zondata kan sparas och replikeras i de aktuella versionerna i Active Directory eller i zonfiler.
  • Namnserver Daemon är en auktoritativ namnserver som har utvecklats för användning som en toppdomän och rotnamnsserver . NSD kompilerar statiskt svar för att optimera serverprestanda. Innehåll i dynamisk zon eller round robin stöds inte.
  • PowerDNS är en namnserver som kan läsa zoner från SQL- databaser, LDAP- kataloger och andra backends. PowerDNS började som en kommersiell implementering och har licensierats under GPL sedan 2002 .
  • Obundet är en DNS-resolver som stöder DNSSEC-validering och cachning. Obundet kan integreras i applikationer som ett programbibliotek.

webb-länkar

Individuella bevis

  1. RFC 7766 - DNS-transport över TCP - Krav på implementering. Internet Engineering Task Force (IETF), s. 3 (Status: mars 2010) Detta dokument uppdaterar därför kärnans DNS-protokollspecifikationer så att stöd för TCP hädanefter är en KRÄVD del av en fullständig DNS-protokollimplementering. [...] Det bör noteras att misslyckande med att stödja TCP (eller blockering av DNS över TCP vid nätverkslagret) sannolikt kommer att resultera i upplösningsfel och / eller tidsgränser på applikationsnivå.
  2. RFC 6724 - Standardadressval för Internetprotokoll version 6 (IPv6). Network Working Group of the IETF, s. 7 (september 2012) En annan effekt av standardtabellen är att föredra kommunikation med IPv6-adresser framför kommunikation med IPv4-adresser, om matchande källadresser är tillgängliga.
  3. a b c Carsten Strotmann, Jürgen Schmidt: DNS med integritet och säkerhet innan genombrottet. Hämtad 25 juli 2018 .
  4. Patrick McManus: Förbättrad DNS-integritet i Firefox. Hämtad 26 juli 2018 .
  5. DoQ bör inte vara manipulerbart, bör erbjuda samma integritet som DoT, låg latens som okrypterad DNS över UDP och bör inte vara blockerbar som DoH. Hämtad 28 januari 2021 .
  6. draft-ietf-dprive-dnsoquic-01 - Specifikation av DNS över dedikerade QUIC-anslutningar. Hämtad 28 januari 2021 .
  7. DNS-över-HTTPS och DNS-över-TLS-stöd , på ffmuc.net
  8. a b Betrodda DNS-servrar. Hämtad 19 februari 2021 .
  9. Krypterade DNS-upplösare. Åtkomst 3 maj 2021 .
  10. Kevin Helms: Hur man skaffar och använder .Bit-sekretessdomäner. I: Bitcoin News. 7 mars 2017, nås 19 mars 2020 .
  11. Namecoin. Hämtad 6 mars 2020 (engelska, projektwebbplats).
  12. .bit - Nästa generation av Bulletproof Hosting. I: abuse.ch. 25 september 2017, nås 19 mars 2020 .
  13. Catalin Cimpanu: OpenNIC tappar stöd för .bit-domännamn efter ojämn missbruk av skadlig kod. I: ZDNet. 17 juli 2019, nås 19 mars 2020 .

Opiniones de nuestros usuarios

Kenneth Ivarsson

Trevlig artikel från domännamnssystem.

Bodil Johansson

Det var ett tag sedan jag såg en artikel om _variabel skriven på ett så didaktiskt sätt. Jag gillar det.

Klara Wahlström

Det är en bra artikel om domännamnssystem. Den ger nödvändig information, utan överdrifter.

Lars Strömberg

Äntligen! Nuförtiden verkar det som att om de inte skriver artiklar med tiotusen ord så är de inte nöjda. Mina herrar innehållsskribenter, detta JA är en bra artikel om domännamnssystem.

Thomas Söderström

Bra inlägg om domännamnssystem.