Domain Name System - Domain Name System

Den Domain Name System ( DNS ) er et hierarkisk og decentralt navngivning system til computere, tjenester eller andre ressourcer, der er tilsluttet internettet eller et privat netværk. Det forbinder forskellige oplysninger med domænenavne, der er tildelt hver af de deltagende enheder. Mest fremtrædende oversætter det lettere huskede domænenavne til de numeriske IP -adresser, der er nødvendige for at lokalisere og identificere computertjenester og -enheder med de underliggende netværksprotokoller . Ved at levere en verdensomspændende, distribueret katalogtjeneste har domænenavnesystemet været en væsentlig komponent i Internets funktionalitet siden 1985.

Domain Name System delegerer ansvaret for at tildele domænenavne og kortlægge disse navne til internetressourcer ved at udpege autoritative navneservere til hvert domæne. Netværksadministratorer kan delegere myndighed over underdomæner i deres tildelte navnerum til andre navneservere. Denne mekanisme leverer distribueret og fejltolerant service og er designet til at undgå en enkelt stor central database.

Domain Name System angiver også den tekniske funktionalitet for databasetjenesten , der er kernen. Den definerer DNS -protokollen, en detaljeret specifikation af datastrukturer og datakommunikationsudvekslinger, der bruges i DNS, som en del af Internet Protocol Suite .

Internettet opretholder to hovednavnerum , domænenavnshierarkiet og Internet Protocol (IP) adresserum . Domain Name System opretholder domænenavnshierarkiet og leverer oversættelsestjenester mellem det og adresserummene. Internets navneservere og en kommunikationsprotokol implementerer Domain Name System. En DNS -navneserver er en server, der gemmer DNS -registreringerne for et domæne; en DNS -navneserver reagerer med svar på forespørgsler mod sin database.

De mest almindelige typer registreringer, der er gemt i DNS -databasen, er til Start of Authority ( SOA ), IP -adresser ( A og AAAA ), SMTP -mailudvekslere (MX), navneservere (NS), pointer til reverse DNS -opslag (PTR), og domænenavnsaliaser (CNAME). Selvom det ikke er beregnet til at være en database til generelle formål, er DNS med tiden blevet udvidet til at gemme poster for andre typer data til enten automatiske opslag, f.eks. DNSSEC -poster eller til menneskelige forespørgsler, f.eks. RP -poster ( ansvarlig person ). Som en database til generelle formål er DNS også blevet brugt til at bekæmpe uopfordret e-mail (spam) ved at gemme en blackhole-liste (RBL) i realtid . DNS -databasen er traditionelt gemt i en struktureret tekstfil, zonefilen , men andre databasesystemer er almindelige.

Fungere

Et ofte anvendt analogi til at forklare Domain Name System er, at det fungerer som telefonbog for internettet ved at oversætte menneske-venlig computer værtsnavne til IP-adresser. For eksempel oversættes domænenavnet www.example.com til adresserne 93.184.216.34 ( IPv4 ) og 2606: 2800: 220: 1: 248: 1893: 25c8: 1946 ( IPv6 ). DNS kan hurtigt og gennemsigtigt opdateres, så en services placering på netværket kan ændres uden at påvirke slutbrugerne, der fortsat bruger det samme værtsnavn. Brugere drager fordel af dette, når de bruger meningsfulde Uniform Resource Locators ( URL'er ) og e-mail-adresser uden at skulle vide, hvordan computeren rent faktisk lokaliserer tjenesterne.

En vigtig og allestedsnærværende funktion af DNS er dens centrale rolle i distribuerede internettjenester såsom cloud -tjenester og indholdsleveringsnetværk . Når en bruger får adgang til en distribueret internettjeneste ved hjælp af en URL, oversættes URL -domænenavnet til IP -adressen på en server, der er proximal til brugeren. Nøglefunktionen i den DNS, der udnyttes her, er, at forskellige brugere samtidigt kan modtage forskellige oversættelser for det samme domænenavn, et centralt punkt for afvigelse fra en traditionel telefonbogsvisning af DNS. Denne proces med brug af DNS til at tildele proximale servere til brugerne er nøglen til at levere hurtigere og mere pålidelige svar på Internettet og bruges i vid udstrækning af de fleste større internettjenester.

DNS afspejler strukturen af ​​det administrative ansvar på Internettet. Hvert underdomæne er en zone med administrativ autonomi delegeret til en leder. For zoner, der drives af et register , suppleres administrative oplysninger ofte med registerets RDAP- og WHOIS -tjenester. Disse data kan bruges til at få indsigt i og spore ansvaret for en given vært på Internettet.

Historie

Brug af et enklere og mere mindeværdigt navn i stedet for en værts numeriske adresse går tilbage til ARPANET -æraen. Stanford Research Institute (nu SRI International ) vedligeholdt en tekstfil ved navn HOSTS.TXT, der kortlagde værtsnavne til de numeriske adresser på computere på ARPANET. Elizabeth Feinler udviklede og vedligeholdt det første ARPANET -bibliotek . Vedligeholdelse af numeriske adresser, kaldet listen Assigned Numbers List, blev håndteret af Jon Postel ved University of Southern California 's Information Sciences Institute (ISI), hvis team arbejdede tæt sammen med SRI.

Adresser blev tildelt manuelt. Computere, herunder deres værtsnavne og adresser, blev føjet til den primære fil ved at kontakte SRI's Network Information Center (NIC), instrueret af Elizabeth Feinler, telefonisk i åbningstiden. Senere oprettede Feinler et WHOIS -bibliotek på en server i NIC til hentning af oplysninger om ressourcer, kontakter og enheder. Hun og hendes team udviklede begrebet domæner. Feinler foreslog, at domæner skulle være baseret på placeringen af ​​computerens fysiske adresse. Computere på uddannelsesinstitutioner ville f.eks. Have domænet edu . Hun og hendes team administrerede Host Naming Registry fra 1972 til 1989.

I begyndelsen af ​​1980'erne var vedligeholdelsen af ​​et enkelt, centraliseret værtsbord blevet langsomt og uhåndterligt, og det nye netværk krævede et automatisk navngivningssystem til at løse tekniske og personalemæssige problemer. Postel ledede opgaven med at indgå et kompromis mellem fem konkurrerende forslag til løsninger på Paul Mockapetris . Mockapetris oprettede i stedet domænenavnsystemet i 1983.

Den Internet Engineering Task Force offentliggjorde de oprindelige 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 Unix -navneserverimplementering for Berkeley Internet Name Domain, der almindeligvis kaldes BIND . I 1985 reviderede Kevin Dunlap fra DEC DNS -implementeringen væsentligt. Mike Karels , Phil Almquist og Paul Vixie har opretholdt BIND siden da. I begyndelsen af ​​1990'erne blev BIND portet til Windows NT -platformen.

I november 1987 erstattede RFC 1034 og RFC 1035 DNS -specifikationerne fra 1983. Flere yderligere anmodninger om kommentarer har foreslået udvidelser af de centrale DNS -protokoller.

Struktur

Domænenavn plads

Domænenavnsrummet består af en trædatastruktur . Hver node eller hvert blad i træet har en etiket og nul eller flere ressourceposter (RR), som indeholder oplysninger, der er knyttet til domænenavnet. Selve domænenavnet består af etiketten, sammenkædet med navnet på dets overordnede knude til højre, adskilt af en prik.

Træet inddeler sig i zoner, der begynder ved rodzonen . En DNS-zone kan kun bestå af ét domæne eller kan bestå af mange domæner og underdomæner, afhængigt af zoneadministratorens administrative valg. DNS kan også opdeles efter klasse, hvor de separate klasser kan opfattes som en række parallelle navnerumstræer.

Det hierarkiske domænenavnesystem til klasse -internet , organiseret i zoner, der hver serveres af en navneserver

Administrativt ansvar for enhver zone kan opdeles ved at oprette yderligere zoner. Myndighed over den nye zone siges at være delegeret til en udpeget navneserver. Forælderzonen ophører med at være autoritativ for den nye zone.

Domænenavnesyntaks, internationalisering

De endelige beskrivelser af reglerne for dannelse af domænenavne findes i RFC 1035, RFC 1123, RFC 2181 og RFC 5892. Et domænenavn består af en eller flere dele, teknisk kaldet etiketter , der konventionelt er sammenkædet og afgrænset af prikker, f.eks. som eksempel.com.

Mærket til højre overfører topdomænet ; f.eks. hører domænenavnet www.example.com til topdomænet com .

Hierarkiet af domæner falder fra højre til venstre; hver etiket til venstre angiver en underopdeling eller underdomæne for domænet til højre. For eksempel etiketten eksempel specificerer et underdomæne af com domæne, og www er et underdomæne af example.com. Dette underinddelingstræ kan have op til 127 niveauer.

En etiket kan indeholde nul til 63 tegn. Nulletiketten, med længde nul, er forbeholdt rodzonen. Det fulde domænenavn må ikke overstige længden på 253 tegn i dets tekstlige fremstilling. I den interne binære repræsentation af DNS kræver den maksimale længde 255 oktet lagring, da den også gemmer længden af ​​navnet.

Selvom der ikke findes nogen teknisk begrænsning for at forhindre domænenavnetiketter i at bruge et hvilket som helst tegn, der kan repræsenteres af en oktet, bruger værtsnavne et foretrukket format og et tegnsæt. De tegn, der er tilladt i etiketter, er en delmængde af ASCII -tegnsættet, der består af tegn a til z , A til Z , cifrene 0 til 9 og bindestreg. Denne regel er kendt som LDH -reglen (bogstaver, cifre, bindestreg). Domænenavne fortolkes på uafhængig måde. Etiketter må ikke starte eller slutte med en bindestreg. En ekstra regel kræver, at domænenavne på topniveau ikke skal være numeriske.

Det begrænsede sæt ASCII -tegn, der er tilladt i DNS, forhindrede gengivelse af navne og ord på mange sprog i deres native alfabeter eller scripts. For at gøre dette muligt godkendte ICANN systemet Internationalizing Domain Names in Applications (IDNA), hvorved brugerprogrammer, f.eks. Webbrowsere, tilknytter Unicode -strenge til det gyldige DNS -tegnsæt ved hjælp af Punycode . I 2009 godkendte ICANN installationen af ​​internationaliserede domænenavne landekode topdomæner ( ccTLD'er ) . Hertil kommer, at mange registre i de eksisterende top-level domænenavne ( TLD s har) vedtaget IDNA systemet, styret af RFC 5890, RFC 5891, RFC 5892, RFC 5893.

Navneservere

Domain Name System vedligeholdes af et distribueret databasesystem , der bruger klient -server -modellen . Noderne i denne database er navneservere . Hvert domæne har mindst én autoritær DNS -server, der udgiver oplysninger om det domæne og navneservere på alle domæner, der er underlagt det. Toppen af ​​hierarkiet betjenes af rodnavnserverne , serverne, der skal forespørge, når de leder ( løser ) et topdomæne.

Autoritativ navneserver

En autoritativ navneserver er en navneserver, der kun giver svar på DNS ​​-forespørgsler fra data, der er konfigureret af en original kilde, f.eks. Domæneadministratoren eller ved dynamiske DNS -metoder, i modsætning til svar, der er opnået via en forespørgsel til en anden navneserver der kun opretholder en cache med data.

En autoritativ navneserver kan enten være en primær server eller en sekundær server. Historisk set blev udtrykkene master/slave og primær/sekundær undertiden brugt om hverandre, men den nuværende praksis er at bruge sidstnævnte form. En primær server er en server, der gemmer de originale kopier af alle zoneposter. En sekundær server bruger en særlig automatisk opdateringsmekanisme i DNS -protokollen i kommunikation med dens primære for at opretholde en identisk kopi af de primære poster.

Hver DNS -zone skal tildeles et sæt autoritative navneservere. Dette sæt servere er gemt i den overordnede domænezone med navneserver (NS) -poster.

En autoritativ server angiver sin status for at levere endelige svar, der anses for autoritative , ved at indstille et protokolflag, kaldet " Autoritativt svar " ( AA ) -bitten i sine svar. Dette flag gengives normalt fremtrædende i output fra DNS -administrationsforespørgselsværktøjer, f.eks. Grave , for at angive, at den navneserver , der svarer, er en autoritet for det pågældende domænenavn.

Når en navneserver er udpeget som den autoritative server for et domænenavn, som den ikke har autoritative data for, præsenterer den en type fejl kaldet en "halt delegering" eller "halt svar".

Operation

Adresseløsningsmekanisme

Domænenavnsopløsere bestemmer domænenavnservere, der er ansvarlige for det pågældende domænenavn, ved hjælp af en række forespørgsler, der starter med domænetiketten til højre (øverste niveau).

En DNS -resolver, der implementerer den iterative tilgang, der er pålagt af RFC 1034; i dette tilfælde konsulterer resolveren tre navneservere for at løse det fuldt kvalificerede domænenavn "www.wikipedia.org".

For korrekt drift af dens domænenavnsopløser er en netværksvært konfigureret med en indledende cache ( tip ) af de kendte adresser til rodnavnserverne. Tipene opdateres periodisk af en administrator ved at hente et datasæt fra en pålidelig kilde.

Forudsat at resolveren ikke har cachelagrede poster til at fremskynde processen, starter opløsnings processen med en forespørgsel til en af ​​rodserverne. Ved typisk drift svarer rodserverne ikke direkte, men reagerer med en henvisning til mere autoritative servere, f.eks. Henvises en forespørgsel efter "www.wikipedia.org" til org -serverne. Opløseren spørger nu til de servere, der henvises til, og gentager denne proces iterativt, indtil den modtager et autoritativt svar. Diagrammet illustrerer denne proces for værten, der er navngivet med det fuldt kvalificerede domænenavn "www.wikipedia.org".

Denne mekanisme ville lægge en stor trafikbyrde på rodserverne, hvis hver opløsning på Internettet kræves fra roden. I praksis bruges caching i DNS-servere til at aflæse rodservere, og som et resultat er rodnavneservere faktisk kun involveret i en relativt lille brøkdel af alle anmodninger.

Rekursiv og caching navneserver

I teorien er autoritative navneservere tilstrækkelige til driften af ​​Internettet. Med kun autoritative navneservere i drift, skal hver DNS -forespørgsel imidlertid starte med rekursive forespørgsler i domænenavnesystemets rodzone, og hvert brugersystem skal implementere resolversoftware, der er i stand til rekursiv drift.

For at forbedre effektiviteten, reducere DNS-trafik på tværs af Internettet og øge ydeevnen i slutbrugerprogrammer understøtter Domain Name System DNS-cache-servere, der gemmer DNS-forespørgselsresultater i en periode bestemt i konfigurationen ( levetid ) for den pågældende domænenavnspost. Typisk implementerer sådanne caching -DNS -servere også den rekursive algoritme, der er nødvendig for at løse et givet navn, der starter med DNS -root til de autoritative navneservere i det forespurgte domæne. Med denne funktion implementeret i navneserveren opnår brugerapplikationer effektivitet i design og drift.

Kombinationen af ​​DNS -caching og rekursive funktioner i en navneserver er ikke obligatorisk; funktionerne kan implementeres uafhængigt i servere til særlige formål.

Internetudbydere leverer typisk rekursive og cachelagrede navneservere til deres kunder. Derudover implementerer mange hjemmenetværksroutere DNS -caches og recursors for at forbedre effektiviteten i det lokale netværk.

DNS -opløsere

Klientsiden af ​​DNS kaldes en DNS -resolver. En resolver er ansvarlig for at starte og sekvensere de forespørgsler, der i sidste ende fører til en fuld opløsning (oversættelse) af den søgte ressource, f.eks. Oversættelse af et domænenavn til en IP -adresse. DNS-resolvere er klassificeret efter en række forskellige forespørgselsmetoder, såsom rekursive , ikke-rekursive og iterative . En afviklingsproces kan bruge en kombination af disse metoder.

I en ikke-rekursiv forespørgsel forespørger en DNS-resolver en DNS-server, der leverer en post, som enten serveren er autoritativ til, eller den giver et delvist resultat uden at spørge andre servere. I tilfælde af en caching DNS-resolver leverer den ikke-rekursive forespørgsel i dens lokale DNS-cache et resultat og reducerer belastningen på opstrøms DNS-servere ved at cache DNS-ressourceoptegnelser i en periode efter et første svar fra opstrøms DNS-servere.

I en rekursiv forespørgsel forespørger en DNS -resolver en enkelt DNS -server, som igen kan forespørge andre DNS -servere på vegne af rekvirenten. For eksempel foretager en simpel stubopløsning, der kører på en hjemmrouter, typisk en rekursiv forespørgsel til DNS -serveren, der køres af brugerens internetudbyder . En rekursiv forespørgsel er en, for hvilken DNS -serveren besvarer forespørgslen fuldstændigt ved at forespørge andre navneservere efter behov. Ved typisk drift udsender en klient en rekursiv forespørgsel til en caching-rekursiv DNS-server, som efterfølgende udsender ikke-rekursive forespørgsler for at bestemme svaret og sende et enkelt svar tilbage til klienten. Resolveren eller en anden DNS -server, der handler rekursivt på vegne af resolveren, forhandler brug af rekursiv service ved hjælp af bits i forespørgselsoverskrifterne. DNS -servere er ikke påkrævet for at understøtte rekursive forespørgsler.

Den iterative forespørgselsprocedure er en proces, hvor en DNS -resolver forespørger en kæde med en eller flere DNS -servere. Hver server henviser klienten til den næste server i kæden, indtil den aktuelle server fuldt ud kan løse anmodningen. For eksempel ville en mulig opløsning af www.example.com forespørge på en global rodserver, derefter en "com" -server og endelig en "example.com" -server.

Cirkulære afhængigheder og limposter

Navneservere i delegationer identificeres ved navn i stedet for ved IP -adresse. Det betyder, at en resolverende navneserver skal udsende en anden DNS -anmodning for at finde ud af IP -adressen på den server, som den er blevet henvist til. Hvis det navn, der er givet i delegationen, er et underdomæne for det domæne, som delegationen leveres til, er der en cirkulær afhængighed .

I dette tilfælde skal navneserveren, der leverer delegationen, også angive en eller flere IP -adresser til den autoritative navneserver, der er nævnt i delegationen. Disse oplysninger kaldes lim . Den delegerende navneserver leverer denne lim i form af poster i den ekstra sektion af DNS -svaret og giver delegationen i autoritetsafsnittet i svaret. En limpost er en kombination af navneserveren og IP -adressen.

For eksempel, hvis den autoritative navneserver for eksempel.org er ns1.example.org, løser en computer, der forsøger at løse www.example.org, først ns1.example.org. Da ns1 er indeholdt i example.org, kræver dette først at løse example.org, som viser en cirkulær afhængighed. For at bryde afhængigheden indeholder navneserveren for topdomæneorganisationen lim sammen med delegationen for eksempel.org. Limposterne er adresseposter, der angiver IP -adresser til ns1.example.org. Opløseren bruger en eller flere af disse IP -adresser til at forespørge på en af ​​domænets autoritative servere, hvilket gør det muligt at fuldføre DNS -forespørgslen.

Optag cachelagring

En standard praksis ved implementering af navneopløsning i applikationer er at reducere belastningen på domænenavnsystemets servere ved at cache resultater lokalt eller i mellemliggende resolver -værter. Resultater opnået fra en DNS -anmodning er altid forbundet med levetid (TTL), en udløbstid, hvorefter resultaterne skal kasseres eller opdateres. TTL'en indstilles af administratoren af ​​den autoritative DNS -server. Gyldighedsperioden kan variere fra få sekunder til dage eller endda uger.

Som følge af denne distribuerede cachearkitektur spredes ændringer af DNS -poster ikke med det samme i hele netværket, men kræver, at alle caches udløber og opdateres efter TTL. RFC 1912 formidler grundlæggende regler for bestemmelse af passende TTL -værdier.

Nogle resolvere tilsidesætter muligvis TTL-værdier, da protokollen understøtter caching i op til otteogtres år eller slet ikke cacher. Negativ caching , dvs. cachelagring af det faktum, at der ikke findes en rekord, bestemmes af navneservere, der er autoritative for en zone, der skal indeholde Start of Authority (SOA) -registrering, når der ikke rapporteres, at der ikke findes data af den anmodede type. Værdien af minimumsfeltet i SOA -posten og TTL'en i selve SOA'en bruges til at etablere TTL for det negative svar.

Omvendt opslag

Et omvendt DNS -opslag er en forespørgsel efter DNS til domænenavne, når IP -adressen er kendt. Flere domænenavne kan være forbundet med en IP -adresse. DNS gemmer IP-adresser i form af domænenavne som specielt formaterede navne i markørposter (PTR) -poster inden for infrastrukturtopdomænet arpa . For IPv4 er domænet in-addr.arpa. For IPv6 er det reverse lookup -domæne ip6.arpa. IP-adressen repræsenteres som et navn i omvendt ordnet oktetrepræsentation for IPv4 og omvendt ordnet nibrepræsentation for IPv6.

Når der udføres et omvendt opslag, konverterer DNS -klienten adressen til disse formater, før der spørges om navnet på en PTR -post efter delegationskæden som for enhver DNS -forespørgsel. For eksempel, forudsat at IPv4-adressen 208.80.152.2 er tildelt Wikimedia, repræsenteres den som et DNS-navn i omvendt rækkefølge: 2.152.80.208.in-addr.arpa. Når DNS-resolveren får en pointer (PTR) -anmodning, begynder den med at forespørge rodservere, der peger på serverne i American Registry for Internet Numbers (ARIN) for zonen 208.in-addr.arpa. ARINs servere delegerer 152.80.208.in-addr.arpa til Wikimedia, hvortil resolveren sender en anden forespørgsel til 2.152.80.208.in-addr.arpa, hvilket resulterer i et autoritativt svar.

Kundesøgning

DNS -opløsningssekvens

Brugere kommunikerer generelt ikke direkte med en DNS -resolver. I stedet finder DNS-opløsning sted transparent i applikationer såsom webbrowsere , e-mail-klienter og andre internetapplikationer. Når en applikation fremsætter en anmodning, der kræver et domænenavnsøgning, sender sådanne programmer en anmodning om opløsning til DNS -resolveren i det lokale operativsystem, som igen håndterer den nødvendige kommunikation.

DNS -resolveren vil næsten altid have en cache (se ovenfor), der indeholder seneste opslag. Hvis cachen kan give svaret på anmodningen, returnerer resolver værdien i cachen til det program, der har fremsat anmodningen. Hvis cachen ikke indeholder svaret, sender resolver anmodningen til en eller flere udpegede DNS -servere. I tilfældet med de fleste hjemmebrugere vil internetudbyderen, som maskinen opretter forbindelse til, normalt levere denne DNS -server: en sådan bruger vil enten have konfigureret serverens adresse manuelt eller have tilladt DHCP at indstille den; hvor systemadministratorer imidlertid har konfigureret systemer til at bruge deres egne DNS -servere, peger deres DNS -resolvere på separat vedligeholdte navneservere i organisationen. Under alle omstændigheder vil den navneserver, der således forespørges, følge processen beskrevet ovenfor , indtil den enten med succes finder et resultat eller ikke. Det returnerer derefter sine resultater til DNS -resolver; forudsat at den har fundet et resultat, gemmer resolveren behørigt det resultat til fremtidig brug og afleverer resultatet tilbage til den software, der startede anmodningen.

Ødelagte resolvere

Nogle store internetudbydere har konfigureret deres DNS -servere til at overtræde regler, f.eks. Ved at være ulydige over TTL'er eller ved at angive, at et domænenavn ikke findes, bare fordi en af ​​dets navneservere ikke reagerer.

Nogle applikationer, f.eks. Webbrowsere, opretholder en intern DNS -cache for at undgå gentagne opslag via netværket. Denne praksis kan tilføre ekstra vanskeligheder ved fejlfinding af DNS -problemer, da det skjuler historikken for sådanne data. Disse cacher bruger typisk meget korte cachetider i størrelsesordenen et minut.

Internet Explorer repræsenterer en bemærkelsesværdig undtagelse: versioner op til IE 3.x cache DNS -poster i 24 timer som standard. Internet Explorer 4.x og nyere versioner (op til IE 8) reducerer standard timeout -værdien til en halv time, som kan ændres ved at ændre standardkonfigurationen.

Når Google Chrome registrerer problemer med DNS -serveren, viser den en bestemt fejlmeddelelse.

Andre applikationer

Domain Name System indeholder flere andre funktioner og funktioner.

Værtsnavne og IP-adresser er ikke påkrævet for at matche i et en-til-en-forhold. Flere værtsnavne kan svare til en enkelt IP -adresse, hvilket er nyttigt i virtuel hosting , hvor mange websteder serveres fra en enkelt vært. Alternativt kan et enkelt værtsnavn løse mange IP -adresser for at lette fejltolerance og belastningsfordeling til flere serverinstanser på tværs af en virksomhed eller det globale internet.

DNS tjener andre formål ud over at oversætte navne til IP -adresser. Eksempelvis mail transfer agenter bruger DNS til at finde den bedste mailserver til at levere e-mail : En MX-post giver en kortlægning mellem et domæne og en mail-veksler; dette kan give et yderligere lag af fejltolerance og belastningsfordeling.

DNS bruges til effektiv lagring og distribution af IP -adresser for sortlistede e -mail -værter. En almindelig metode er at placere emneværtens IP-adresse i underdomænet for et domænenavn på et højere niveau og at løse dette navn til en post, der angiver en positiv eller en negativ indikation.

For eksempel:

• Adressen 102.3.4.5 er sortlistet. Det peger på 5.4.3.102.blacklist.example, der løses til 127.0.0.1.
• Adressen 102.3.4.6 er ikke sortlistet og peger på 6.4.3.102. Sortlisteeksempel. Dette værtsnavn er enten ikke konfigureret eller løser til 127.0.0.2.

E-mailservere kan forespørge om sortlisteeksempel for at finde ud af, om en bestemt vært, der opretter forbindelse til dem, er på sortlisten. Mange af sådanne sortlister, enten abonnementsbaserede eller gratis, er tilgængelige til brug for e-mailadministratorer og anti-spam-software.

For at give modstandsdygtighed i tilfælde af computer- eller netværksfejl leveres der normalt flere DNS -servere til dækning af hvert domæne. På det øverste niveau af global DNS findes tretten grupper af rodnavneservere , med yderligere "kopier" af dem distribueret over hele verden via anycast -adressering.

Dynamisk DNS (DDNS) opdaterer en DNS-server med en klient-IP-adresse i farten, f.eks. Ved flytning mellem internetudbydere eller mobile hotspots , eller når IP-adressen ændres administrativt.

DNS -beskedformat

DNS -protokollen bruger to typer DNS -meddelelser, forespørgsler og svar; begge har samme format. Hver meddelelse består af en overskrift og fire sektioner: spørgsmål, svar, autoritet og et ekstra mellemrum. Et overskriftsfelt ( flag ) styrer indholdet af disse fire sektioner.

Overskriftssektionen består af følgende felter: Identifikation , Flag , Antal spørgsmål , Antal svar , Antal autoritetsressourcer (RR'er) og Antal yderligere RR'er . Hvert felt er 16 bit langt og vises i den angivne rækkefølge. Identifikationsfeltet bruges til at matche svar med forespørgsler. Flagfeltet består af underfelter som følger:

Efter flaget ender overskriften med fire 16-bit heltal, som indeholder antallet af poster i hver af de følgende sektioner i samme rækkefølge.

Spørgsmålssektion

Spørgsmålssektionen har et enklere format end det ressourceoptegnelsesformat, der bruges i de andre sektioner. Hver spørgsmålspost (der er normalt kun en i sektionen) indeholder følgende felter:

Domænenavnet er opdelt i diskrete etiketter, der er sammenkædede; hver etiket er præfikseret med længden af ​​denne etiket.

DNS -transportprotokoller

DNS-over-UDP/53 ("Do53")

Fra tidspunktet for dets oprindelse i 1983 og for ganske nylig har DNS primært besvaret forespørgsler på User Datagram Protocol (UDP) portnummer 53. Sådanne forespørgsler består af en klar tekstanmodning sendt i en enkelt UDP-pakke fra klienten, besvaret med et klartekstsvar sendt i en enkelt UDP-pakke fra serveren. Når svarets længde overstiger 512 bytes, og både klient og server understøtter udvidelsesmekanismer til DNS (EDNS), kan der bruges større UDP -pakker. Brug af DNS-over-UDP er begrænset af blandt andet dens mangel på transportlagskryptering, godkendelse, pålidelig levering og beskedlængde.

DNS-over-TCP/53 ("Do53/TCP")

I 1989 specificerede RFC 1123 valgfri Transmission Control Protocol (TCP) transport til DNS -forespørgsler, svar og især zoneoverførsler . Via fragmentering af lange svar tillader TCP længere svar, pålidelig levering og genbrug af langlivede forbindelser mellem klienter og servere.

DNSCrypt

Den DNSCrypt protokol, som blev udviklet i 2011 uden for rammerne IETF-standarder, indført DNS kryptering på den nedstrøms side af rekursive resolvers, hvor kunder krypterer forespørgslen nyttelast ved hjælp servermiljø- offentlige nøgler, der offentliggøres i DNS (snarere end at forlade sig på tredje- partcertifikatmyndigheder), og som igen kan være beskyttet af DNSSEC -signaturer. DNSCrypt bruger enten TCP- eller UDP -port 443, den samme port som HTTPS -krypteret webtrafik. Dette introducerede ikke kun privatliv vedrørende forespørgselens indhold, men også et betydeligt mål for firewall-traversal kapacitet. I 2019 blev DNSCrypt yderligere udvidet til at understøtte en "anonymiseret" tilstand, der ligner den foreslåede "Oblivious DNS", hvor en indgangsknude modtager en forespørgsel, der er blevet krypteret med den offentlige nøgle til en anden server, og videresender den til den server, der fungerer som en udgangsknude, der udfører den rekursive opløsning. Fortrolighed for bruger-/forespørgselspar oprettes, da indgangsknudepunktet ikke kender forespørgselens indhold, mens udgangsknudepunkterne ikke kender klientens identitet. DNSCrypt blev første gang implementeret i produktion af OpenDNS i december 2011.

DNS-over-TLS ("DoT")

En IETF -standard for krypteret DNS opstod i 2016 ved hjælp af standard Transport Layer Security (TLS) til at beskytte hele forbindelsen frem for kun DNS -nyttelasten. DoT -servere lytter på TCP -port 853. RFC7858 angiver, at opportunistisk kryptering og godkendt kryptering muligvis understøttes, men hverken server- eller klientgodkendelse blev obligatorisk.

DNS-over-HTTPS ("DoH")

En konkurrerende standard for DNS -forespørgselstransport blev introduceret i 2018, tunneling af DNS -forespørgselsdata over HTTPS (som igen transporterer HTTP over TLS). DoH blev fremmet som et mere webvenligt alternativ til DNS, da det ligesom DNSCrypt kører på TCP-port 443 og dermed ligner webtrafik, selvom de let kan differentieres i praksis. DoH er blevet kritiseret meget for at reducere brugeranonymitet i forhold til DoT.

DNS-over-TOR

Ligesom andre internetprotokoller køres DNS muligvis over VPN'er og tunneler . En anvendelse, der er blevet almindelig nok siden 2019 til at berettige sit eget ofte anvendte akronym, er DNS-over- Tor . Fortroligheden af ​​fortrolige DNS ved Oblivious DNS kan opnås ved brug af det allerede eksisterende Tor-netværk for ind- og udgangsknudepunkter, parret med transportlagskrypteringen fra TLS.

Glemsk DNS-over-HTTPS ("ODoH")

I 2021 blev en "uvidende" implementering af DoH foreslået og er blevet implementeret i kladdeform, der kombinerer indgang/udgangsadskillelse med HTTPS-tunneling og TLS-transportlags kryptering i en enkelt defineret protokol.

Ressourceoptegnelser

Domain Name System angiver en database med informationselementer til netværksressourcer. Typerne af informationselementer er kategoriseret og organiseret med en liste over DNS -posttyper , ressourceposter (RR'er). Hver post har en type (navn og nummer), en udløbstid ( tid til at leve ), en klasse og typespecifikke data. Ressourceposter af samme type beskrives som et ressourcepostsæt (RRset), der ikke har nogen særlig bestilling. DNS-resolvere returnerer hele sættet ved forespørgsel, men servere kan implementere round-robin-bestilling for at opnå belastningsbalancering . I modsætning hertil fungerer Domain Name System Security Extensions (DNSSEC) på det komplette sæt ressourcepost i kanonisk rækkefølge.

Når de sendes via et internetprotokolnetværk , bruger alle poster det fælles format, der er angivet i RFC 1035:

NAME er det fuldt kvalificerede domænenavn for noden i træet. På ledningen kan navnet forkortes ved hjælp af etiketkomprimering, hvor ender på domænenavne, der er nævnt tidligere i pakken, kan erstattes med slutningen af ​​det aktuelle domænenavn.

TYPE er posttypen. Det angiver dataets format, og det giver et fingerpeg om deres påtænkte anvendelse. For eksempel bruges A -posten til at oversætte fra et domænenavn til en IPv4 -adresse , NS -posten viser, hvilke navneservere der kan besvare opslag i en DNS -zone , og MX -posten angiver den mailserver, der bruges til at håndtere mail for et domæne, der er angivet i en e-mail-adresse.

RDATA er data af typespecifik relevans, f.eks. IP-adressen til adresseposter eller prioriteten og værtsnavnet for MX-poster. Kendte posttyper kan bruge etiketkomprimering i RDATA -feltet, men "ukendte" posttyper må ikke (RFC 3597).

Den KLASSE af en rekord er sat til IN (til internettet ) til fælles DNS-poster, der involverer Internet værtsnavne, servere eller IP-adresser. Derudover findes klasserne Chaos (CH) og Hesiod (HS). Hver klasse er et uafhængigt navnerum med potentielt forskellige delegationer af DNS -zoner.

Ud over ressourceposter, der er defineret i en zonefil , definerer domænenavnesystemet også flere anmodningstyper, der kun bruges i kommunikation med andre DNS -noder ( på ledningen ), f.eks. Ved udførelse af zoneoverførsler (AXFR/IXFR) eller til EDNS (OPT).

Wildcard DNS -registreringer

Domænenavnesystemet understøtter jokertegn -DNS -poster, der angiver navne, der starter med stjerneetiketten ' *', f.eks. *.Eksempel. DNS -poster, der tilhører wildcard -domænenavne, angiver regler for generering af ressourceposter inden for en enkelt DNS -zone ved at erstatte hele etiketter med matchende komponenter i forespørgselsnavnet, herunder eventuelle angivne efterkommere. For eksempel i følgende konfiguration, DNS zone x.example specificerer, at alle subdomæner, herunder subdomæner af underdomæner af x.example brug mail varmeveksler (MX) axexample . A -posten til akseprøve er nødvendig for at angive mailvekslerens IP -adresse. Da dette har resulteret i at ekskludere dette domænenavn og dets underdomæner fra jokertegnene , skal der også defineres en ekstra MX -post for underdomænet axeksempel samt en jokertegn MX -post for alle dens underdomæner i DNS -zonen.

x.example.       MX   10 a.x.example.
*.x.example.     MX   10 a.x.example.
*.a.x.example.   MX   10 a.x.example.
a.x.example.     MX   10 a.x.example.
a.x.example.     AAAA 2001:db8::1

Jokertegneposters rolle blev forfinet i RFC  4592 , fordi den oprindelige definition i RFC  1034 var ufuldstændig og resulterede i fejlfortolkninger af implementatorer.

Protokoludvidelser

Den originale DNS -protokol havde begrænsede bestemmelser om udvidelse med nye funktioner. I 1999 offentliggjorde Paul Vixie i RFC 2671 (erstattet af RFC 6891) en udvidelsesmekanisme, kaldet Extension Mechanisms for DNS (EDNS), der indførte valgfri protokolelementer uden at øge overhead, når den ikke var i brug. Dette blev opnået gennem OPT-pseudoressourcerekorden, der kun findes i trådtransmissioner af protokollen, men ikke i nogen zonefiler. Indledende udvidelser blev også foreslået (EDNS0), såsom forøgelse af DNS -beskedstørrelsen i UDP -datagrammer.

Dynamiske zoneopdateringer

Dynamiske DNS -opdateringer bruger UPDATE DNS -opkoden til at tilføje eller fjerne ressourceoptegnelser dynamisk fra en zonedatabase, der vedligeholdes på en autoritativ DNS -server. Funktionen er beskrevet i RFC 2136. Denne facilitet er nyttig til at registrere netværksklienter i DNS, når de starter eller på anden måde bliver tilgængelige på netværket. Da en opstartsklient kan blive tildelt en anden IP -adresse hver gang fra en DHCP -server, er det ikke muligt at levere statiske DNS -tildelinger til sådanne klienter.

Sikkerhedsspørgsmål

Oprindeligt var sikkerhedsproblemer ikke store designovervejelser for DNS -software eller software til implementering på det tidlige internet, da netværket ikke var åbent for deltagelse af den brede offentlighed. Udvidelsen af ​​Internettet til den kommercielle sektor i 1990'erne ændrede imidlertid kravene til sikkerhedsforanstaltninger for at beskytte dataintegritet og brugergodkendelse .

Flere problemer med sårbarhed blev opdaget og udnyttet af ondsindede brugere. Et sådant problem er DNS-cache-forgiftning , hvor data distribueres til caching-opløsere under påvisning af at være en autoritativ oprindelsesserver og derved forurener datalageret med potentielt falske oplysninger og lange udløbstider (time-to-live). Efterfølgende kan legitime applikationsanmodninger omdirigeres til netværksværter, der drives med ondsindet hensigt.

DNS -svar har traditionelt ikke en kryptografisk signatur , hvilket fører til mange angrebsmuligheder; de Domain Name System Security Extensions (DNSSEC) ændre DNS for at tilføje understøttelse af kryptografisk underskrevne svar. DNSCurve er blevet foreslået som et alternativ til DNSSEC. Andre udvidelser, f.eks. TSIG , tilføjer understøttelse af kryptografisk godkendelse mellem pålidelige jævnaldrende og bruges ofte til at godkende zoneoverførsel eller dynamiske opdateringsoperationer.

Nogle domænenavne kan bruges til at opnå forfalskningseffekter. For eksempel er paypal.com og paypa1.com forskellige navne, men alligevel kan brugerne muligvis ikke skelne dem i en grafisk brugergrænseflade afhængigt af brugerens valgte skrifttype . I mange skrifttyper ligner bogstavet l og tallet 1 meget ens eller endda identiske. Dette problem er akut i systemer, der understøtter internationaliserede domænenavne , da mange tegnkoder i ISO 10646 kan forekomme identiske på typiske computerskærme. Denne sårbarhed udnyttes lejlighedsvis i phishing .

Teknikker såsom fremadbekræftet reverse DNS kan også bruges til at hjælpe med at validere DNS-resultater.

DNS kan også "lække" fra ellers sikre eller private forbindelser, hvis der ikke lægges vægt på deres konfiguration, og til tider er DNS blevet brugt til at omgå firewalls af ondsindede personer og eksfiltrere data, da det ofte ses som uskadeligt.

Beskyttelse af personlige oplysninger og sporing

Oprindeligt designet som en offentlig, hierarkisk, distribueret og stærkt cachelagret database, har DNS -protokollen ingen fortrolighedskontrol. Brugerforespørgsler og navneserverresponser sendes ukrypteret, hvilket muliggør sniffning af netværkspakker , DNS-kapring , DNS-cache-forgiftning og man-in-the-middle-angreb . Denne mangel bruges sædvanligvis af cyberkriminelle og netværksoperatører til marketingformål, brugergodkendelse på fange portaler og censur .

Brugernes privatliv afsløres yderligere af forslag om at øge niveauet for klientens IP -oplysninger i DNS -forespørgsler (RFC 7871) til fordel for indholdsleveringsnetværk .

De vigtigste tilgange, der bruges til at imødegå problemer med privatlivets fred med DNS:

• VPN'er , der flytter DNS -opløsning til VPN -operatøren og skjuler brugertrafik for lokal internetudbyder,
• Tor , som erstatter traditionel DNS-opløsning med anonyme .onion- domæner, der skjuler både navneopløsning og brugertrafik bag løgeroutering modovervågning ,
• Proxyer og offentlige DNS-servere, der flytter den faktiske DNS-opløsning til en tredjepartsudbyder, der normalt lover lidt eller ingen anmodningslogning og valgfrie tilføjede funktioner, såsom reklame på DNS-niveau eller blokering af pornografi.
  • Offentlige DNS-servere kan forespørges ved hjælp af traditionel DNS-protokol, i hvilket tilfælde de ikke giver nogen beskyttelse mod lokal overvågning eller DNS-over-HTTPS , DNS-over-TLS og DNSCrypt , som giver en sådan beskyttelse

Løsninger, der forhindrer DNS -inspektion fra den lokale netværksoperatør, kritiseres for at modarbejde virksomhedernes netværkssikkerhedspolitikker og internetcensur. De kritiseres også ud fra et privatlivssynspunkt, idet de giver DNS -opløsningen fra hænderne på et lille antal virksomheder, der er kendt for at tjene penge på brugertrafik og for at centralisere DNS -navneopløsning, som generelt opfattes som skadeligt for Internettet.

Google er den dominerende udbyder af platformen i Android, browseren i Chrome og DNS -resolver i 8.8.8.8 -tjenesten. Ville dette scenario være et tilfælde af, at en enkelt virksomhedsenhed var i en position med overordnet kontrol over hele navnerummet på Internettet? Netflix stillede allerede en app, der brugte sin egen DNS -opløsningsmekanisme uafhængig af den platform, som appen kørte på. Hvad hvis Facebook -appen inkluderede DoH? Hvad hvis Apples iOS brugte en DoH-opløsningsmekanisme til at omgå lokal DNS-opløsning og styre alle DNS-forespørgsler fra Apples platforme til et sæt af Apple-betjente navneopløsere?

-  DNS Privacy og IETF

Registrering af domænenavn

Retten til at bruge et domænenavn delegeres af domænenavnsregistratorer, der er akkrediteret af Internet Corporation for Assigned Names and Numbers (ICANN) eller andre organisationer som OpenNIC , der har til opgave at føre tilsyn med Internets navne- og nummersystemer . Ud over ICANN vedligeholdes og serviceres hvert topdomæne (TLD) teknisk af en administrativ organisation, der driver et register. Et register er ansvarligt for drift af databasen med navne inden for sin autoritative zone, selvom udtrykket oftest bruges til topdomæner. En registrant er en person eller organisation, der bad om domæneregistrering. Den sekretariat modtager registreringsoplysninger fra hver domænenavn registrator , som er godkendt (akkrediteret) for at tildele navne i den tilsvarende zone og offentliggør oplysninger ved hjælp af WHOIS -protokollen. Fra 2015 overvejes brugen af RDAP .

ICANN offentliggør den komplette liste over TLD'er, TLD -registre og domænenavnsregistratorer. Registrantoplysninger forbundet med domænenavne opbevares i en online database, der er tilgængelig med WHOIS -tjenesten. For de fleste af de mere end 290 landekode- topdomæner (ccTLD'er) opretholder domæneregistrene oplysninger om WHOIS (registrant, navneservere, udløbsdatoer osv.). F.eks. Opbevarer DENIC , Tyskland NIC, DE -domænedataene. Fra omkring 2001 har de fleste generiske top-level domæne (gTLD) registre vedtaget denne såkaldte tykke registreringsmetode, det vil sige at beholde WHOIS-data i centrale registre i stedet for registratordatabaser.

For topdomæner på COM og NET bruges en tynd registreringsmodel. Domæneregisteret (f.eks. GoDaddy , BigRock og PDR , VeriSign osv. Osv.) Indeholder grundlæggende WHOIS -data (dvs. registrator- og navneservere osv.). Organisationer eller registranter, der anvender ORG på den anden side, er udelukkende på det offentlige interesseregister .

Nogle domænenavnsregistre, ofte kaldet netværksinformationscentre (NIC), fungerer også som registrarer for slutbrugere ud over at give adgang til WHOIS-datasæt. Topdomæneregistrene, f.eks. For domænerne COM, NET og ORG, bruger en model for registreringsregistratorer, der består af mange domænenavnsregistratorer. I denne forvaltningsmetode administrerer registreringsdatabasen kun domænenavnsdatabasen og forholdet til registratorerne. De registranter (brugere af et domænenavn) er kunder hos registratoren, i nogle tilfælde gennem yderligere udlicitering af forhandlere.

RFC -dokumenter

Standarder

Domain Name System er defineret af Request for Comments (RFC) dokumenter udgivet af Internet Engineering Task Force ( internetstandarder ). Følgende er en liste over RFC'er, der definerer DNS -protokollen.

• RFC  1034 , domænenavne - begreber og faciliteter
• RFC  1035 , domænenavne - implementering og specifikation
• RFC  1123 , Krav til internetværter - applikation og support
• RFC  1995 , trinvis zoneoverførsel i DNS
• RFC  1996 , en mekanisme til hurtig meddelelse om zoneændringer (DNS NOTIFY)
• RFC  2136 , dynamiske opdateringer i domænenavnesystemet (DNS UPDATE)
• RFC  2181 , præciseringer til DNS -specifikationen
• RFC  2308 , negativ caching af DNS -forespørgsler (DNS NCACHE)
• RFC  2672 , Non-Terminal DNS Name Redirection
• RFC  2845 , Secret Key Transaction Authentication for DNS (TSIG)
• RFC  3225 , Angiver Resolver Support af DNSSEC
• RFC  3226 , DNSSEC og IPv6 A6 -opmærksom på krav til server/resolver -meddelelsesstørrelse
• RFC  3596 , DNS -udvidelser til understøttelse af IP -version 6
• RFC  3597 , Håndtering af ukendte DNS -ressourceregistreringstyper (RR)
• RFC  4343 , Domain Name System (DNS) Case Insensitivity Clarification
• RFC  4592 , Wildcards rolle i domænenavnsystemet
• RFC  4635 , HMAC SHA TSIG Algoritme Identifiers
• RFC  5001 , DNS Name Server Identifier (NSID) Option
• RFC  5011 , Automated Updates of DNS Security (DNSSEC) Trust Anchors
• RFC  5452 , foranstaltninger til at gøre DNS mere modstandsdygtig over for forfalskede svar
• RFC  5890 , Internationaliserede domænenavne til applikationer (IDNA): Definitioner og dokumentrammer
• RFC  5891 , Internationaliserede domænenavne i applikationer (IDNA): Protokol
• RFC  5892 , Unicode -kodepunkter og internationaliserede domænenavne til applikationer (IDNA)
• RFC  5893 , højre-til-venstre-scripts til internationaliserede domænenavne til applikationer (IDNA)
• RFC  6891 , udvidelsesmekanismer til DNS (EDNS0)
• RFC  7766 , DNS Transport over TCP - Implementeringskrav

Foreslåede sikkerhedsstandarder

• RFC  4033 , Introduktion og krav til DNS -sikkerhed
• RFC  4034 , ressourceoptegnelser til DNS -sikkerhedsudvidelserne
• RFC  4035 , protokolændringer til DNS -sikkerhedsudvidelserne
• RFC  4509 , brug af SHA-256 i DNSSEC Delegation Signer (DS) Resource Records
• RFC  4470 , minimalt dækkende NSEC-registreringer og DNSSEC onlinesignering
• RFC  5155 , DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
• RFC  5702 , brug af SHA-2-algoritmer med RSA i DNSKEY og RRSIG Resource Records til DNSSEC
• RFC  5910 , Domain Name System (DNS) Security Extensions Mapping for Extensible Provisioning Protocol (EPP)
• RFC  5933 , brug af GOST -signaturalgoritmer i DNSKEY og RRSIG -ressourceoptegnelser til DNSSEC
• RFC  7830 , EDNS (0) polstring
• RFC  7858 , specifikation for DNS over Transport Layer Security (TLS)
• RFC  8310 , brugsprofiler til DNS over TLS og DNS over DTLS
• RFC  8484 , DNS -forespørgsler over HTTPS (DoH)

Eksperimentelle RFC'er

• RFC  1183 , nye DNS RR -definitioner

Bedste nuværende praksis

• RFC  2182 , valg og drift af sekundære DNS -servere (BCP 16)
• RFC  2317 , klasseløs IN-ADDR.ARPA-delegation (BCP 20)
• RFC  5625 , retningslinjer for implementering af DNS -proxy (BCP 152)
• RFC  6895 , Domain Name System (DNS) IANA -overvejelser (BCP 42)
• RFC  7720 , DNS Root Name Service Protocol og implementeringskrav (BCP 40)

Informations -RFC'er

Disse RFC'er er vejledende, men kan give nyttige oplysninger på trods af, at de hverken definerer en standard eller BCP. (RFC 1796)

• RFC  1178 , valg af navn til din computer (FYI 5)
• RFC  1591 , domænenavnssystemstruktur og delegering
• RFC  1912 , Almindelige DNS -drifts- og konfigurationsfejl
• RFC  2100 , Navngivning af værter
• RFC  3696 , applikationsteknikker til kontrol og omdannelse af navne
• RFC  3833 . Trusselanalyse af domænenavnsystemet (DNS)
• RFC  4892 , Krav til en mekanisme, der identificerer en navneserverforekomst
• RFC  5894 , internationaliserede domænenavne til applikationer (IDNA): Baggrund, forklaring og begrundelse
• RFC  5895 , Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008
• RFC  7626 , DNS Privacy Overvejelser
• RFC  7706 , formindsket adgangstid til rodservere ved at køre en på Loopback
• RFC  8499 , DNS -terminologi

Ukendt

Disse RFC'er har en officiel status som Ukendt , men er på grund af deres alder ikke tydeligt mærket som sådanne.

• RFC  920 , domænekrav -Specificerede originale topdomæner
• RFC  1032 , Domain Administrators Guide
• RFC  1033 , Domain Administrators Operations Guide
• RFC  1101 , DNS -kodninger af netværksnavne og andre typer

Se også

Referencer

Kilder

• Evans, Claire L. (2018). Broad Band: The Untold Story of the Women Who Made the Internet . New York: Portfolio/Penguin. ISBN 9780735211759.

eksterne links

• Vixie, Paul (2007-04-01). "DNS -kompleksitet" . ACM -kø . Arkiveret fra originalen 2007-06-10.
• Zytrax.com , Open Source Guide - DNS for raketforskere .
• Internet Governance og domænenavnsystemet: Spørgsmål til Congress Congressional Research Service
• Ball, James (28. februar 2014). "Mød de syv mennesker, der har nøglerne til verdensomspændende internetsikkerhed" . Værgen . Guardian News & Media Limited . Hentet 28. februar 2014 .