DNS
Het domeinnaamsysteem, Engels: Domain Name System (of Server of Service), afgekort DNS, is een hiërarchisch en gedecentraliseerd naamgevingssysteem voor computers, services of andere bronnen die zijn verbonden met internet of een particulier netwerk. Het koppelt verschillende informatie aan domeinnamen die aan elk van de deelnemende entiteiten zijn toegewezen. Het meest in het oog springend vertaalt het gemakkelijker opgeslagen domeinnamen naar de numerieke IP-adressen die nodig zijn voor het lokaliseren en identificeren van computerservices en apparaten met de onderliggende netwerkprotocollen. Door een wereldwijde, gedistribueerde directoryservice aan te bieden, is het Domain Name System sinds 1985 een essentieel onderdeel van de functionaliteit van het internet.
Het Domain Name Service delegeert de verantwoordelijkheid voor het toewijzen van domeinnamen en het toewijzen van die namen aan internetbronnen door voor elk domein gezaghebbende naamservers aan te wijzen. Netwerkbeheerders kunnen bevoegdheden over subdomeinen van hun toegewezen naamruimte delegeren aan andere naamservers. Dit mechanisme biedt gedistribueerde en fouttolerante service en is ontworpen om één grote centrale database te vermijden.
Het Domain Name Server specificeert ook de technische functionaliteit van de databaseservice die de kern vormt. Het definieert het DNS-protocol, een gedetailleerde specificatie van de datastructuren en datacommunicatie-uitwisselingen die in de DNS worden gebruikt, als onderdeel van de Internet Protocol Suite.
Het internet heeft twee hoofdnaamruimten, de domeinnaamhiërarchie en de IP-adresruimten (Internet Protocol). Het Domain Name System onderhoudt de domeinnaamhiërarchie en biedt vertaaldiensten tussen deze en de adresruimten. Internet-naamservers en een communicatieprotocol implementeren het Domain Name System. Een DNS-naamserver is een server die de DNS-records voor een domein opslaat; een DNS-naamserver reageert met antwoorden op vragen over zijn database.
De meest voorkomende soorten records die zijn opgeslagen in de DNS-database zijn voor Start of Authority (SOA), IP-adressen (A en AAAA), SMTP-mailwisselaars (MX), naamservers (NS), pointers voor reverse DNS lookups (PTR), en domeinnaamaliassen (CNAME). Hoewel DNS niet bedoeld is als een database voor algemene doeleinden, is het in de loop van de tijd uitgebreid om records op te slaan voor andere soorten gegevens voor automatische zoekacties, zoals DNSSEC-records, of voor menselijke vragen zoals records van verantwoordelijke personen (RP). Als een algemene database is de DNS ook gebruikt bij het bestrijden van ongevraagde e-mail (spam) door een realtime blackhole-lijst (RBL) op te slaan. De DNS-database wordt traditioneel opgeslagen in een gestructureerd tekstbestand, het zonebestand, maar andere databasesystemen zijn gebruikelijk.
Functie
Een vaak gebruikte analogie om het Domain Name System uit te leggen, is dat het dient als het telefoonboek voor het internet door mensvriendelijke computerhostnamen te vertalen in IP-adressen. De domeinnaam www.example.com vertaalt zich bijvoorbeeld naar de adressen 93.184.216.34 (IPv4) en 2606: 2800: 220: 1: 248: 1893: 25c8: 1946 (IPv6). De DNS kan snel en transparant worden bijgewerkt, waardoor de locatie van een service op het netwerk kan veranderen zonder dat dit gevolgen heeft voor de eindgebruikers, die dezelfde hostnaam blijven gebruiken. Gebruikers profiteren hiervan wanneer ze zinvolle Uniform Resource Locators (URL’s) en e-mailadressen gebruiken zonder te hoeven weten hoe de computer de services daadwerkelijk lokaliseert.
Een belangrijke en alomtegenwoordige functie van DNS is de centrale rol in gedistribueerde internetdiensten zoals clouddiensten en netwerken voor inhoudslevering. Wanneer een gebruiker via een URL toegang krijgt tot een gedistribueerde internetservice, wordt de domeinnaam van de URL vertaald naar het IP-adres van een server die proximaal is van de gebruiker. De belangrijkste functionaliteit van DNS die hier wordt geëxploiteerd, is dat verschillende gebruikers tegelijkertijd verschillende vertalingen voor dezelfde domeinnaam kunnen ontvangen, een belangrijk verschilpunt met een traditionele telefoonboekweergave van de DNS. Dit proces waarbij DNS wordt gebruikt om proximale servers aan gebruikers toe te wijzen, is essentieel voor het leveren van snellere en betrouwbaardere reacties op internet en wordt veel gebruikt door de meeste grote internetdiensten.
De DNS weerspiegelt de structuur van administratieve verantwoordelijkheid op internet. Elk subdomein is een zone van administratieve autonomie die aan een manager is gedelegeerd. Voor zones die worden beheerd door een register, wordt administratieve informatie vaak aangevuld met de RDAP- en WHOIS-services van het register. Die gegevens kunnen worden gebruikt om inzicht te krijgen in en de verantwoordelijkheid voor een bepaalde host op internet te volgen.
Geschiedenis
Het gebruik van een eenvoudigere, meer gedenkwaardige naam in plaats van het numerieke adres van een host dateert uit het ARPANET-tijdperk. Het Stanford Research Institute (nu SRI International) hield een tekstbestand bij met de naam HOSTS.TXT dat hostnamen toewijst aan de numerieke adressen van computers op het ARPANET. Elizabeth Feinler heeft de eerste ARPANET-directory ontwikkeld en onderhouden. Het onderhoud van numerieke adressen, de Assigned Numbers List genoemd, werd uitgevoerd door Jon Postel van het Information Sciences Institute (ISI) van de University of Southern California, wiens team nauw samenwerkte met SRI.
Adressen zijn handmatig toegewezen. Computers, inclusief hun hostnamen en adressen, werden aan het hoofdbestand toegevoegd door tijdens kantooruren telefonisch contact op te nemen met het Network Information Center (NIC) van de SRI, aangestuurd door Elizabeth Feinler. Later zette Feinler een WHOIS-directory op een server in de netwerkkaart voor het ophalen van informatie over bronnen, contacten en entiteiten. Zij en haar team hebben het concept van domeinen ontwikkeld. Feinler stelde voor dat domeinen gebaseerd zouden moeten zijn op de locatie van het fysieke adres van de computer. Computers bij onderwijsinstellingen zouden bijvoorbeeld het domein edu hebben. Zij en haar team beheerden het Host Naming Registry van 1972 tot 1989.
Tegen het begin van de jaren tachtig was het onderhouden van één centrale hosttabel langzaam en log geworden en het opkomende netwerk vereiste een geautomatiseerd naamgevingssysteem om technische en personeelsproblemen aan te pakken. Postel gaf Paul Mockapetris de opdracht om een compromis te smeden tussen vijf concurrerende voorstellen voor oplossingen. Mockapetris creëerde in plaats daarvan het Domain Name System in 1983.
De Internet Engineering Task Force publiceerde de oorspronkelijke specificaties in RFC 882 en RFC 883 in november 1983.
In 1984 schreven vier UC Berkeley-studenten, Douglas Terry, Mark Painter, David Riggle en Songnian Zhou, de eerste Unix-naamserverimplementatie voor het Berkeley Internet Name Domain, ook wel BIND genoemd. In 1985 heeft Kevin Dunlap van DEC de DNS-implementatie aanzienlijk herzien. Mike Karels, Phil Almquist en Paul Vixie hebben sindsdien BIND gehandhaafd. Begin jaren negentig werd BIND geport naar het Windows NT-platform. Het werd op grote schaal verspreid, vooral op Unix-systemen, en is nog steeds de meest gebruikte DNS-software op internet.
In november 1987 vervangen RFC 1034 en RFC 1035 de DNS-specificaties van 1983. Verschillende aanvullende verzoeken om opmerkingen hebben uitbreidingen voorgesteld voor de belangrijkste DNS-protocollen.
Structuur
Domeinnaamruimte
De domeinnaamruimte bestaat uit een boomgegevensstructuur. Elk knooppunt of blad in de boom heeft een label en nul of meer bronrecords (RR), die informatie bevatten die is gekoppeld aan de domeinnaam. De domeinnaam zelf bestaat uit het label, aaneengeschakeld met de naam van het bovenliggende knooppunt aan de rechterkant, gescheiden door een punt.
De boom is onderverdeeld in zones beginnend bij de wortelzone. Een DNS-zone kan bestaan uit slechts één domein of kan bestaan uit veel domeinen en subdomeinen, afhankelijk van de administratieve keuzes van de zonemanager. DNS kan ook worden gepartitioneerd volgens klasse, waarbij de afzonderlijke klassen kunnen worden beschouwd als een array van parallelle naamruimtebomen.
De administratieve verantwoordelijkheid voor elke zone kan worden verdeeld door extra zones te creëren. Het gezag over de nieuwe zone zou worden gedelegeerd aan een aangewezen naamserver. De ouderzone is niet langer gezaghebbend voor de nieuwe zone.
Syntaxis van domeinnamen, internationalisering
De definitieve beschrijvingen van de regels voor het vormen van domeinnamen zijn te vinden in RFC 1035, RFC 1123, RFC 2181 en RFC 5892. Een domeinnaam bestaat uit een of meer delen, technisch genaamd labels, die conventioneel aaneengeschakeld zijn en worden gescheiden door punten, zoals als voorbeeld.be.
Het meest rechtse label geeft het topleveldomein weer; de domeinnaam www.voorbeeld.com behoort bijvoorbeeld tot het domein op het hoogste niveau.
De hiërarchie van domeinen loopt van rechts naar links; elk label aan de linkerkant specificeert een onderverdeling of subdomein van het domein aan de rechterkant. Het labelvoorbeeld specificeert bijvoorbeeld een subdomein van het be-domein en www is een subdomein van voorbeeld.be. Deze onderverdelingsboom kan tot 127 niveaus bevatten.
Een label mag nul tot 63 tekens bevatten. Het null-label, met lengte nul, is gereserveerd voor de rootzone. De volledige domeinnaam mag in de tekstuele weergave niet langer zijn dan 253 tekens. In de interne binaire representatie van de DNS vereist de maximale lengte 255 octetten opslag, omdat het ook de lengte van de naam opslaat.
Hoewel er geen technische beperking bestaat om enig teken te gebruiken in domeinnaamlabels die representatief zijn voor een octet, gebruiken hostnamen een voorkeursindeling en tekenset. De toegestane tekens in labels zijn een subset van de ASCII-tekenset, bestaande uit de tekens a tot en met z, A tot en met Z, cijfers 0 tot en met 9 en koppelteken. Deze regel staat bekend als de LDH-regel (letters, cijfers, koppelteken). Domeinnamen worden per geval onafhankelijk geïnterpreteerd. Labels mogen niet beginnen of eindigen met een koppelteken. Een aanvullende regel vereist dat domeinnamen op het hoogste niveau niet allemaal numeriek mogen zijn.
De beperkte set ASCII-tekens die in de DNS zijn toegestaan, verhinderde de weergave van namen en woorden van veel talen in hun eigen alfabetten of scripts. Om dit mogelijk te maken, keurde ICANN het Internationalizing Domain Names in Applications (IDNA) -systeem goed, waarmee gebruikerstoepassingen, zoals webbrowsers, Unicode-strings toewijzen aan de geldige DNS-tekenset met Punycode. In 2009 keurde ICANN de installatie goed van geïnternationaliseerde domeinnaam landcode top-level domeinen (ccTLD’s). Bovendien hebben veel registers van de bestaande top-level domeinnamen (TLD’s) het IDNA-systeem overgenomen, geleid door RFC 5890, RFC 5891, RFC 5892, RFC 5893.
Namemservers
Het Domain Name System wordt onderhouden door een gedistribueerd databasesysteem, dat het client-servermodel gebruikt. De knooppunten van deze database zijn de naamservers. Elk domein heeft ten minste één gezaghebbende DNS-server die informatie over dat domein en de naamservers van eventuele daaraan gerelateerde domeinen publiceert. De top van de hiërarchie wordt bediend door de root-naamservers, de servers die moeten worden bevraagd bij het opzoeken (oplossen) van een TLD.
Gezaghebbende naamserver (Engels: Authoritative name server)
Een gezaghebbende naamserver is een naamserver die alleen antwoorden geeft op DNS-query’s van gegevens die zijn geconfigureerd door een oorspronkelijke bron, bijvoorbeeld de domeinbeheerder of door dynamische DNS-methoden, in tegenstelling tot antwoorden die zijn verkregen via een query naar een andere naamserver die alleen een gegevenscache bijhoudt.
Een gezaghebbende naamserver kan een masterserver of een slaveserver zijn. Een masterserver is een server die de originele (master) kopieën van alle zonerecords opslaat. Een slaveserver gebruikt een speciaal automatisch updatemechanisme in het DNS-protocol in communicatie met zijn master om een identieke kopie van de masterrecords te behouden.
Aan elke DNS-zone moet een reeks gezaghebbende naamservers worden toegewezen. Deze set servers wordt opgeslagen in de bovenliggende domeinzone met naamserverrecords (NS).
Een gezaghebbende server geeft zijn status aan van het leveren van definitieve antwoorden, die als gezaghebbend worden beschouwd, door een protocolvlag in te stellen, de “gezaghebbende antwoord” (AA) -bit in zijn antwoorden. Deze vlag wordt meestal prominent weergegeven in de uitvoer van DNS-beheerquery-tools, zoals dig, om aan te geven dat de antwoordende naamserver een autoriteit is voor de betreffende domeinnaam.
Werking
Mechanisme voor adresresolutie
Domeinnaam-resolvers bepalen de domeinnaamservers die verantwoordelijk zijn voor de betreffende domeinnaam door een reeks vragen die beginnen met het meest rechtse (hoogste niveau) domeinlabel.
Een DNS-resolver die de iteratieve benadering van RFC 1034 implementeert; in dit geval raadpleegt de resolver drie nameservers om de volledig gekwalificeerde domeinnaam “www.dnsd.be” op te lossen.
Voor een goede werking van de domeinnaamresolver is een netwerkhost geconfigureerd met een initiële cache (hints) van de bekende adressen van de root-naamservers. De hints worden periodiek bijgewerkt door een beheerder door een dataset op te halen bij een betrouwbare bron.
Ervan uitgaande dat de resolver geen records in de cache heeft om het proces te versnellen, begint het oplossingsproces met een zoekopdracht naar een van de basisservers. Bij een normale werking antwoorden de basisservers niet rechtstreeks, maar reageren ze met een verwijzing naar meer gezaghebbende servers, bijv. Een vraag naar “www.voorbeeld.be” wordt verwezen naar de org-servers. De resolver vraagt nu de servers waarnaar wordt verwezen en herhaalt dit proces iteratief totdat het een gezaghebbend antwoord ontvangt. Het diagram illustreert dit proces voor de host die wordt genoemd met de volledig gekwalificeerde domeinnaam “www.dnsd.be”.
Dit mechanisme zou een grote verkeersdruk op de rootservers leggen, als elke resolutie op het internet vanaf de root vereist is. In de praktijk wordt caching gebruikt in DNS-servers om de root-servers te ontlasten, en als gevolg hiervan zijn root-naamservers eigenlijk slechts bij een relatief klein deel van alle verzoeken betrokken.
Recursieve en caching naamserver
In theorie zijn gezaghebbende naamservers voldoende voor de werking van internet. Aangezien echter alleen gezaghebbende naamservers actief zijn, moet elke DNS-query beginnen met recursieve query’s in de rootzone van het Domain Name System en zou elk gebruikerssysteem resolversoftware moeten implementeren die recursief kan werken.
Om de efficiëntie te verbeteren, het DNS-verkeer over het internet te verminderen en de prestaties in eindgebruikertoepassingen te verbeteren, ondersteunt het Domain Name System DNS-cacheservers die DNS-queryresultaten opslaan gedurende een bepaalde tijd bepaald in de configuratie (time-to-live) van het betreffende domeinnaamrecord. Dergelijke caching DNS-servers implementeren doorgaans ook het recursieve algoritme dat nodig is om een bepaalde naam op te lossen, te beginnen met de DNS-root tot en met de gezaghebbende nameservers van het opgevraagde domein. Met deze functie geïmplementeerd in de naamserver, worden gebruikerstoepassingen efficiënter in ontwerp en bediening.
De combinatie van DNS-caching en recursieve functies in een naamserver is niet verplicht; de functies kunnen onafhankelijk worden geïmplementeerd in servers voor speciale doeleinden.
Internetserviceproviders bieden doorgaans recursieve en caching naamservers voor hun klanten. Bovendien implementeren veel thuisnetwerkrouters DNS-caches en recursors om de efficiëntie in het lokale netwerk te verbeteren.
DNS-resolvers
De client-kant van de DNS wordt een DNS-resolver genoemd. Een resolver is verantwoordelijk voor het initiëren en sequentiëren van de vragen die uiteindelijk leiden tot een volledige resolutie (vertaling) van de gezochte bron, bijvoorbeeld vertaling van een domeinnaam naar een IP-adres. DNS-resolvers worden geclassificeerd door verschillende querymethoden, zoals recursief, niet-recursief en iteratief. Een resolutieproces kan een combinatie van deze methoden gebruiken.
In een niet-recursieve query vraagt een DNS-resolver naar een DNS-server die een record levert waarvoor de server gezaghebbend is, of het levert een gedeeltelijk resultaat op zonder andere servers te ondervragen. In het geval van een caching DNS-resolver, levert de niet-recursieve query van de lokale DNS-cache een resultaat op en vermindert het de belasting op upstream DNS-servers door DNS-bronrecords een tijdje in de cache te plaatsen na een eerste reactie van upstream DNS-servers.
In een recursieve query vraagt een DNS-resolver naar een enkele DNS-server, die op zijn beurt namens de aanvrager andere DNS-servers kan opvragen. Een eenvoudige stub-resolver die op een thuisrouter draait, doet bijvoorbeeld meestal een recursieve query naar de DNS-server die wordt uitgevoerd door de ISP van de gebruiker. Een recursieve query is een query waarvoor de DNS-server de query volledig beantwoordt door naar behoefte andere nameservers te raadplegen. Bij een normale bewerking verzendt een client een recursieve query naar een caching recursieve DNS-server, die vervolgens niet-recursieve query’s afgeeft om het antwoord te bepalen en een enkel antwoord terug te sturen naar de client. De resolver, of een andere DNS-server die recursief optreedt namens de resolver, onderhandelt over het gebruik van een recursieve service met bits in de queryheaders. DNS-servers zijn niet vereist om recursieve vragen te ondersteunen.
De iteratieve queryprocedure is een proces waarbij een DNS-resolver een keten van een of meer DNS-servers opvraagt. Elke server verwijst de client naar de volgende server in de keten, totdat de huidige server het verzoek volledig kan oplossen. Een mogelijke resolutie van www.example.com zou bijvoorbeeld een globale basisserver, dan een “be” -server en ten slotte een “voorbeeld.be” -server opvragen.
Circular dependencies and glue records
Naamservers in delegaties worden geïdentificeerd op naam en niet op IP-adres. Dit betekent dat een oplossende naamserver een ander DNS-verzoek moet indienen om het IP-adres te achterhalen van de server waarnaar het is verwezen. Als de naam in de delegatie een subdomein is van het domein waarvoor de delegatie wordt verstrekt, is er een circulaire afhankelijkheid.
In dit geval moet de naamserver die de delegatie verzorgt, ook een of meer IP-adressen verstrekken voor de gezaghebbende naamserver die in de delegatie wordt genoemd. Deze informatie wordt glue (lijm) genoemd. De delegerende naamserver levert deze glue in de vorm van records in het aanvullende gedeelte van het DNS-antwoord en levert de delegatie in het autoriteitsgedeelte van het antwoord. Een lijmrecord is een combinatie van de naamserver en het IP-adres.
Als de gezaghebbende naamserver voor voorbeeld.be bijvoorbeeld ns1.voorbeeld.be is, lost een computer die www.voorbeeld.be probeert op te lossen eerst ns1.voorbeeld.be op. Aangezien ns1 is opgenomen in voorbeeld.org, moet hiervoor eerst voorbeeld.org worden opgelost, wat een circulaire afhankelijkheid oplevert. Om de afhankelijkheid te verbreken, bevat de naamserver voor de domeinorganisatie op het hoogste niveau lijm samen met de delegatie voor bijvoorbeeld.org. De lijmrecords zijn adresrecords die IP-adressen bieden voor ns1.voorbeeld.be. De resolver gebruikt een of meer van deze IP-adressen om een van de gezaghebbende servers van het domein te bevragen, waardoor deze de DNS-query kan voltooien.
Record caching
Een standaardpraktijk bij het implementeren van naamomzetting in toepassingen is het verminderen van de belasting van de Domain Name System-servers door de resultaten lokaal of in tussenliggende resolver-hosts in de cache op te slaan. Resultaten verkregen uit een DNS-verzoek zijn altijd gekoppeld aan de tijd om te leven (TTL), een vervaltijd waarna de resultaten moeten worden weggegooid of vernieuwd. De TTL wordt ingesteld door de beheerder van de gezaghebbende DNS-server. De geldigheidsduur kan variëren van enkele seconden tot dagen of zelfs weken.
Als gevolg van deze gedistribueerde cachingarchitectuur worden wijzigingen in DNS-records niet onmiddellijk door het hele netwerk verspreid, maar moeten alle caches verlopen en na TTL worden vernieuwd. RFC 1912 bevat basisregels voor het bepalen van geschikte TTL-waarden.
Sommige resolvers kunnen TTL-waarden overschrijven, omdat het protocol caching tot achtenzestig jaar of helemaal geen caching ondersteunt. Negatieve caching, d.w.z. het cachen van het feit dat een record niet bestaat, wordt bepaald door naamservers die gezaghebbend zijn voor een zone die het Start of Authority (SOA) -record moet bevatten wanneer er geen gegevens van het gevraagde type bestaan. De waarde van het minimale veld van het SOA-record en de TTL van de SOA zelf wordt gebruikt om de TTL voor het negatieve antwoord vast te stellen.
Omgekeerd opzoeken (Reverse lookup)
Een reverse DNS lookup is een zoekopdracht van de DNS voor domeinnamen wanneer het IP-adres bekend is. Aan een IP-adres kunnen meerdere domeinnamen worden gekoppeld. De DNS slaat IP-adressen op in de vorm van domeinnamen als speciaal opgemaakte namen in pointer (PTR) -records binnen de infrastructuur top-level domein arpa. Voor IPv4 is het domein in-addr.arpa. Voor IPv6 is het domein voor reverse lookup ip6.arpa. Het IP-adres wordt weergegeven als een naam in octet-weergave in omgekeerde volgorde voor IPv4 en in omgekeerde volgorde in nibble-weergave voor IPv6.
Bij het uitvoeren van een reverse lookup, zet de DNS-client het adres om in deze formaten voordat hij de naam opvraagt voor een PTR-record volgens de delegatieketen zoals voor elke DNS-query. Ervan uitgaande dat het IPv4-adres 208.80.152.2 is toegewezen aan Wikimedia, wordt het weergegeven als een DNS-naam in omgekeerde volgorde: 2.152.80.208.in-addr.arpa. Wanneer de DNS-resolver een pointer (PTR) -verzoek ontvangt, begint het met het ondervragen van de root-servers, die verwijzen naar de servers van American Registry for Internet Numbers (ARIN) voor de zone 208.in-addr.arpa. De servers van ARIN delegeren 152.80.208.in-addr.arpa naar Wikimedia waarnaar de resolver nog een vraag stuurt voor 2.152.80.208.in-addr.arpa, wat resulteert in een gezaghebbende reactie.
Client opzoeken (Client lookup)
Gebruikers communiceren over het algemeen niet rechtstreeks met een DNS-resolver. In plaats daarvan vindt DNS-resolutie transparant plaats in toepassingen zoals webbrowsers, e-mailclients en andere internettoepassingen. Wanneer een toepassing een verzoek indient waarvoor een domeinnaam moet worden opgezocht, sturen dergelijke programma’s een verzoek tot oplossing naar de DNS-resolver in het lokale besturingssysteem, dat op zijn beurt de vereiste communicatie afhandelt.
De DNS-resolver heeft bijna altijd een cache (zie hierboven) met recente zoekopdrachten. Als de cache het antwoord op het verzoek kan geven, retourneert de resolver de waarde in de cache naar het programma dat het verzoek heeft gedaan. Als de cache het antwoord niet bevat, stuurt de resolver het verzoek naar een of meer aangewezen DNS-servers. In het geval van de meeste thuisgebruikers zal de internetprovider waarmee de machine verbinding maakt, gewoonlijk deze DNS-server leveren: een dergelijke gebruiker zal het adres van die server handmatig hebben geconfigureerd of DHCP hebben toegestaan het in te stellen; wanneer systeembeheerders echter systemen hebben geconfigureerd om hun eigen DNS-servers te gebruiken, wijzen hun DNS-resolvers naar afzonderlijk onderhouden naamservers van de organisatie. In ieder geval zal de aldus ondervraagde naamserver het hierboven beschreven proces volgen totdat het met succes een resultaat vindt of niet. Vervolgens stuurt het de resultaten terug naar de DNS-resolver; ervan uitgaande dat het een resultaat heeft gevonden, slaat de resolver het resultaat naar behoren op voor toekomstig gebruik en geeft het resultaat terug aan de software die het verzoek heeft geïnitieerd.
Gebroken resolvers
Sommige grote ISP’s hebben hun DNS-servers geconfigureerd om regels te overtreden, bijvoorbeeld door ongehoorzaam te zijn aan TTL’s of door aan te geven dat een domeinnaam niet bestaat, alleen omdat een van de naamservers niet reageert.
Sommige applicaties, zoals webbrowsers, hebben een interne DNS-cache om herhaalde zoekopdrachten via het netwerk te voorkomen. Deze praktijk kan extra problemen opleveren bij het debuggen van DNS-problemen omdat het de geschiedenis van dergelijke gegevens verdoezelt. Deze caches gebruiken doorgaans zeer korte cachetijden in de orde van één minuut.
Internet Explorer vormt een opmerkelijke uitzondering: versies tot IE 3.x cachen DNS-records standaard 24 uur lang. Internet Explorer 4.x en latere versies (tot IE 8) verlagen de standaard time-outwaarde tot een half uur, die kan worden gewijzigd door de standaardconfiguratie te wijzigen.
Wanneer Google Chrome problemen met de DNS-server detecteert, wordt er een specifiek foutbericht weergegeven.
Andere applicaties
Het Domain Name System bevat verschillende andere functies en kenmerken.
Hostnamen en IP-adressen hoeven niet overeen te komen in een één-op-één-relatie. Meerdere hostnamen kunnen overeenkomen met één IP-adres, wat handig is bij virtuele hosting, waarbij veel websites vanaf één host worden bediend. Als alternatief kan een enkele hostnaam worden omgezet in veel IP-adressen om fouttolerantie te vergemakkelijken en de verdeling van de belasting naar meerdere serverinstanties binnen een onderneming of het wereldwijde internet te vergemakkelijken.
DNS dient naast het vertalen van namen naar IP-adressen ook voor andere doeleinden. Zo gebruiken mail transfer agents DNS om de beste mailserver te vinden om e-mail af te leveren: Een MX-record biedt een mapping tussen een domein en een mail-wisselaar; dit kan een extra laag fouttolerantie en belastingverdeling opleveren.
De DNS wordt gebruikt voor efficiënte opslag en distributie van IP-adressen van op de zwarte lijst geplaatste e-mailhosts. Een veelgebruikte methode is om het IP-adres van de onderwerphost in het subdomein van een hogere domeinnaam te plaatsen en die naam om te zetten in een record dat een positieve of een negatieve indicatie aangeeft.
Bijvoorbeeld:
- Het adres 102.3.4.5 staat op de zwarte lijst. Het verwijst naar 5.4.3.102.blacklist.example, wat oplost tot 127.0.0.1.
- Het adres 102.3.4.6 staat niet op de zwarte lijst en verwijst naar 6.4.3.102.blacklist.example. Deze hostnaam is niet geconfigureerd of wordt omgezet in 127.0.0.2.
E-mailservers kunnen een blacklist.example opvragen om erachter te komen of een specifieke host die ermee verbonden is, in de blacklist staat. Veel van dergelijke zwarte lijsten, hetzij op abonnementsbasis, hetzij gratis, zijn beschikbaar voor gebruik door e-mailbeheerders en antispamsoftware.
Om veerkracht te bieden in het geval van een computer- of netwerkstoring, worden meestal meerdere DNS-servers geleverd voor dekking van elk domein. Op het hoogste niveau van wereldwijde DNS bestaan dertien groepen rootnameservers, met extra “kopieën” daarvan die wereldwijd worden verspreid via anycast-adressering.
Dynamic DNS (DDNS) werkt een DNS-server bij met een IP-adres van een client, bijvoorbeeld wanneer u tussen ISP’s of mobiele hotspots beweegt of wanneer het IP-adres administratief verandert.
DNS-berichtindeling (DNS message format)
Het DNS-protocol maakt gebruik van twee soorten DNS-berichten: zoekopdrachten en antwoorden; beide hebben hetzelfde formaat. Elk bericht bestaat uit een koptekst en vier secties: vraag, antwoord, autoriteit en een extra spatie. Een koptekstveld (flags) bepaalt de inhoud van deze vier secties.
De koptekstsectie bestaat uit de volgende velden: Identificatie, Flags, Aantal vragen, Aantal antwoorden, Aantal autoriteitsbronrecords (RR’s) en Aantal extra RR’s. Elk veld is 16 bits lang en verschijnt in de aangegeven volgorde. Het identificatieveld wordt gebruikt om reacties te matchen met vragen. Het vlagveld bestaat uit de volgende subvelden:
Veld | Omschrijving | Lengte (bits) |
---|---|---|
QR | Indicates if the message is a query (0) or a reply (1) | 1 |
OPCODE | The type can be QUERY (standard query, 0), IQUERY (inverse query, 1), or STATUS (server status request, 2) | 4 |
AA | Authoritative Answer, in a response, indicates if the DNS server is authoritative for the queried hostname | 1 |
TC | TrunCation, indicates that this message was truncated due to excessive length | 1 |
RD | Recursion Desired, indicates if the client means a recursive query | 1 |
RA | Recursion Available, in a response, indicates if the replying DNS server supports recursion | 1 |
Z | Zero, reserved for future use | 3 |
RCODE | Response code, can be NOERROR (0), FORMERR (1, Format error), SERVFAIL (2), NXDOMAIN (3, Nonexistent domain), etc. | 4 |
Na de flag eindigt de koptekst met vier 16-bits gehele getallen die het aantal records in elk van de volgende secties bevatten, in dezelfde volgorde.
Vraag sectie
De vraagsectie heeft een eenvoudiger indeling dan de bronrecordindeling die in de andere secties wordt gebruikt. Elk vraagrecord (er is er meestal maar één in de sectie) bevat de volgende velden:
Veld | Omschrijving | Lengte (octets) |
---|---|---|
NAME | Name of the requested resource | Variable |
TYPE | Type of RR (A, AAAA, MX, TXT, etc.) | 2 |
CLASS | Class code | 2 |
De domeinnaam is opgesplitst in afzonderlijke labels die zijn samengevoegd; elk label wordt voorafgegaan door de lengte van dat label.
Transport van DNS-protocol
DNS gebruikt voornamelijk het User Datagram Protocol (UDP) op poortnummer 53 om verzoeken te bedienen. DNS-query’s bestaan uit één UDP-verzoek van de client, gevolgd door één UDP-antwoord van de server. Als de lengte van het antwoord groter is dan 512 bytes en zowel de client als de server EDNS ondersteunen, worden grotere UDP-pakketten gebruikt. Anders wordt de query opnieuw verzonden via het Transmission Control Protocol (TCP). TCP wordt ook gebruikt voor taken zoals zoneoverdrachten. Sommige resolver-implementaties gebruiken TCP voor alle vragen.
Bronrecords
Het Domain Name System specificeert een database met informatie-elementen voor netwerkbronnen. De soorten informatie-elementen zijn gecategoriseerd en georganiseerd met een lijst van DNS-recordtypen, de bronrecords (RR’s). Elk record heeft een type (naam en nummer), een vervaltijd (tijd om te leven), een klasse en typespecifieke gegevens. Bronrecords van hetzelfde type worden beschreven als een bronrecordset (RRset), zonder speciale volgorde. DNS-resolvers retourneren de volledige set na een query, maar servers kunnen een round-robin-volgorde implementeren om load balancing te bereiken. Daarentegen werken de Domain Name System Security Extensions (DNSSEC) in canonieke volgorde aan de volledige set bronrecords.
Bij verzending via een internetprotocol-netwerk gebruiken alle records de algemene indeling die is gespecificeerd in RFC 1035:
Veld | Omschrijving | Lengte (octets) |
---|---|---|
NAME | Name of the node to which this record pertains | Variable |
TYPE | Type of RR in numeric form (e.g., 15 for MX RRs) | 2 |
CLASS | Class code | 2 |
TTL | Time To Live of Hop Limit: het aantal seconden dat de RR geldig blijft (het maximum is 231−1, dat is ongeveer 68 jaar)) | 4 |
RDLENGTH | Length of RDATA field (specified in octets) | 2 |
RDATA | Additional RR-specific data | Variable, as per RDLENGTH |
NAME is de volledig gekwalificeerde domeinnaam van het knooppunt in de boom. Op de kabel kan de naam worden ingekort met behulp van labelcompressie, waarbij uiteinden van eerder in het pakket genoemde domeinnamen het einde van de huidige domeinnaam kunnen vervangen. Een vrijstaande @ wordt gebruikt om de huidige oorsprong aan te geven.
TYPE is het recordtype. Het geeft het formaat van de gegevens aan en geeft een indicatie van het beoogde gebruik. Het A-record wordt bijvoorbeeld gebruikt om te vertalen van een domeinnaam naar een IPv4-adres, het NS-record geeft aan welke naamservers zoekopdrachten in een DNS-zone kunnen beantwoorden, en het MX-record specificeert de mailserver die wordt gebruikt voor het afhandelen van mail voor een gespecificeerd domein in een e-mailadres.
RDATA zijn gegevens van typespecifieke relevantie, zoals het IP-adres voor adresrecords of de prioriteit en hostnaam voor MX-records. Bekende recordtypen kunnen labelcompressie gebruiken in het RDATA-veld, maar “onbekende” recordtypen niet (RFC 3597).
De CLASS van een record is ingesteld op IN (voor internet) voor algemene DNS-records met internethostnamen, servers of IP-adressen. Daarnaast bestaan de klassen Chaos (CH) en Hesiod (HS). Elke klasse is een onafhankelijke naamruimte met mogelijk verschillende delegaties van DNS-zones.
Naast bronrecords die zijn gedefinieerd in een zonebestand, definieert het domeinnaamsysteem ook verschillende verzoektypen die alleen worden gebruikt in communicatie met andere DNS-knooppunten (op de kabel), zoals bij het uitvoeren van zoneoverdrachten (AXFR / IXFR) of voor EDNS (OPT).
DNS-records met jokertekens (Wildcard DNS)
Het domeinnaamsysteem ondersteunt wildcard DNS-records die namen specificeren die beginnen met het asterisk label, ‘*’, bijvoorbeeld * .example. DNS-records die behoren tot wildcard-domeinnamen specificeren regels voor het genereren van bronrecords binnen een enkele DNS-zone door hele labels te vervangen door overeenkomende componenten van de querynaam, inclusief gespecificeerde afstammelingen. In de volgende configuratie specificeert de DNS-zone x.example bijvoorbeeld dat alle subdomeinen, inclusief subdomeinen van subdomeinen, van x.example de mail exchange (MX) a.x.example gebruiken. Het A-record voor a.x.-voorbeeld is nodig om het IP-adres van de mailwisselaar op te geven. Aangezien dit het gevolg is van het uitsluiten van deze domeinnaam en zijn subdomeinen van de jokertekens, moet een extra MX-record voor het subdomein a.x. bijvoorbeeld, evenals een jokerteken MX-record voor al zijn subdomeinen, worden gedefinieerd in de DNS-zone.
x.example. MX 10 a.x.voorbeeld. *.x.voorbeeld. MX 10 a.x.voorbeeld. *.a.x.voorbeeld. MX 10 a.x.voorbeeld. a.x.voorbeeld. MX 10 a.x.voorbeeld. a.x.voorbeeld. AAAA 2001:db8::1
De rol van wildcardrecords werd verfijnd in RFC 4592, omdat de oorspronkelijke definitie in RFC 1034 onvolledig was en resulteerde in verkeerde interpretaties door implementeerders.
Protocol-extensies
Het oorspronkelijke DNS-protocol had beperkte bepalingen voor uitbreiding met nieuwe functies. In 1999 publiceerde Paul Vixie in RFC 2671 (vervangen door RFC 6891) een extensiemechanisme, genaamd Extensiemechanismen voor DNS (EDNS) dat optionele protocolelementen introduceerde zonder de overhead te verhogen wanneer niet in gebruik. Dit werd bereikt door het OPT pseudo-bronrecord dat alleen bestaat in draadtransmissies van het protocol, maar niet in zonebestanden. Er werden ook initiële uitbreidingen voorgesteld (EDNS0), zoals het vergroten van de DNS-berichtgrootte in UDP-datagrammen.
Dynamische zone-updates
Dynamische DNS-updates gebruiken de UPDATE DNS-opcode om bronrecords dynamisch toe te voegen aan of te verwijderen uit een zonedatabase die wordt onderhouden op een gezaghebbende DNS-server. De functie wordt beschreven in RFC 2136. Deze mogelijkheid is handig om netwerkclients in de DNS te registreren wanneer ze opstarten of anderszins beschikbaar worden op het netwerk. Aangezien aan een opstartclient elke keer vanaf een DHCP-server een ander IP-adres kan worden toegewezen, is het niet mogelijk om statische DNS-toewijzingen voor dergelijke clients op te geven.
Veiligheidsproblemen
Oorspronkelijk waren veiligheidsproblemen geen belangrijke ontwerpoverwegingen voor DNS-software of software voor implementatie op het vroege internet, aangezien het netwerk niet openstond voor deelname door het grote publiek. De uitbreiding van het internet naar de commerciële sector in de jaren negentig veranderde echter de vereisten voor beveiligingsmaatregelen om de gegevensintegriteit en gebruikersauthenticatie te beschermen.
Verschillende kwetsbaarheidsproblemen werden ontdekt en misbruikt door kwaadwillende gebruikers. Een van die problemen is DNS-cache-vergiftiging, waarbij gegevens worden gedistribueerd naar caching-resolvers onder het voorwendsel een gezaghebbende oorsprongsserver te zijn, waardoor de gegevensopslag wordt vervuild met mogelijk valse informatie en lange vervaltijden (time-to-live). Vervolgens kunnen legitieme aanvraagaanvragen worden doorgestuurd naar netwerkhosts die met kwaadaardige bedoelingen worden bediend.
DNS-antwoorden hebben traditioneel geen cryptografische handtekening, wat tot veel aanvalsmogelijkheden leidt; de Domain Name System Security Extensions (DNSSEC) wijzigen DNS om ondersteuning toe te voegen voor cryptografisch ondertekende antwoorden. DNSCurve is voorgesteld als alternatief voor DNSSEC. Andere extensies, zoals TSIG, voegen ondersteuning toe voor cryptografische authenticatie tussen vertrouwde peers en worden vaak gebruikt om zoneoverdracht of dynamische updatebewerkingen toe te staan.
Sommige domeinnamen kunnen worden gebruikt om spoofing-effecten te bereiken. Paypal.com en paypa1.com zijn bijvoorbeeld verschillende namen, maar gebruikers kunnen ze mogelijk niet onderscheiden in een grafische gebruikersinterface, afhankelijk van het door de gebruiker gekozen lettertype. In veel lettertypen lijken de letter l en het cijfer 1 erg op elkaar of zelfs identiek. Dit probleem is acuut bij systemen die geïnternationaliseerde domeinnamen ondersteunen, aangezien veel tekencodes in ISO 10646 identiek kunnen lijken op typische computerschermen. Dit beveiligingslek wordt af en toe misbruikt bij phishing.
Technieken zoals voorwaarts bevestigde reverse DNS kunnen ook worden gebruikt om DNS-resultaten te valideren.
DNS kan ook “lekken” uit anderszins beveiligde of privéverbindingen, als er geen aandacht wordt besteed aan hun configuratie, en soms wordt DNS gebruikt om firewalls te omzeilen door kwaadwillende personen, en om gegevens te exfiltreren, omdat het vaak als onschadelijk wordt beschouwd.
Problemen met privacy en tracking
Oorspronkelijk ontworpen als een openbare, hiërarchische, gedistribueerde en zwaar gecachte database, heeft het DNS-protocol geen vertrouwelijkheidscontroles. Gebruikersvragen en naamserverreacties worden onversleuteld verzonden, waardoor snuffelen van netwerkpakketten, DNS-kaping, DNS-cache-vergiftiging en man-in-the-middle-aanvallen mogelijk wordt. Deze tekortkoming wordt vaak gebruikt door cybercriminelen en netwerkexploitanten voor marketingdoeleinden, gebruikersauthenticatie op captive portals en censuur.
De privacy van gebruikers wordt verder blootgelegd door voorstellen die het niveau van client-IP verhogen in DNS-zoekopdrachten (RFC 7871) ten behoeve van Content Delivery Networks.
De belangrijkste benaderingen worden gebruikt om privacyproblemen met DNS tegen te gaan:
- VPN’s, die DNS-resolutie naar de VPN-operator verplaatsen en gebruikersverkeer voor lokale ISP verbergen,
- Tor <, dat de traditionele DNS-resolutie vervangt door anonieme .onion-domeinen, die zowel naamomzetting als gebruikersverkeer verbergt achter ui-routebeveiliging,
- Proxy’s en openbare DNS-servers, die de daadwerkelijke DNS-resolutie verplaatsen naar een externe provider, die gewoonlijk weinig of geen logboekregistratie en optionele extra functies belooft, zoals advertenties op DNS-niveau of blokkering van pornografie.
- Openbare DNS-servers kunnen worden opgevraagd met behulp van het traditionele DNS-protocol, in welk geval ze geen bescherming bieden tegen lokale bewaking, of DNS-over-HTTPS, DNS-over-TLS en DNSCrypt, die een dergelijke bescherming bieden
Oplossingen die DNS-inspectie door de lokale netwerkexploitant voorkomen, worden bekritiseerd vanwege het dwarsbomen van het netwerkbeveiligingsbeleid en de internetcensuur. Ze worden ook bekritiseerd vanuit het oogpunt van privacy, omdat ze de DNS-resolutie weggeven aan een klein aantal bedrijven die bekend staan om het genereren van inkomsten met gebruikersverkeer en voor het centraliseren van DNS-naamresolutie, die over het algemeen als schadelijk voor internet wordt beschouwd.
Domeinnaam registratie
Het recht om een domeinnaam te gebruiken wordt gedelegeerd door domeinnaamregistrators die zijn geaccrediteerd door de Internet Corporation for Assigned Names and Numbers (ICANN) of andere organisaties zoals OpenNIC, die belast zijn met het toezicht op de naam- en nummerstelsels van internet. Naast ICANN wordt elk topleveldomein (TLD) technisch onderhouden en onderhouden door een administratieve organisatie die een register beheert. Een register is verantwoordelijk voor het beheer van de database met namen binnen zijn gezaghebbende zone, hoewel de term het vaakst wordt gebruikt voor TLD’s. Een registrant is een persoon of organisatie die om domeinregistratie heeft gevraagd. Het register ontvangt registratie-informatie van elke domeinnaamregistrar, die is geautoriseerd (geaccrediteerd) om namen toe te wijzen in de overeenkomstige zone en de informatie publiceert met behulp van het WHOIS-protocol. Vanaf 2015 wordt overwogen om RDAP te gebruiken.
ICANN publiceert de volledige lijst van TLD’s, TLD-registers en domeinnaamregistreerders. Registrantinformatie die aan domeinnamen is gekoppeld, wordt bijgehouden in een online database die toegankelijk is via de WHOIS-service. Voor de meeste van de meer dan 290 topdomeinen met landcodes (ccTLD’s), houden de domeinregisters de WHOIS-gegevens (registrant, naamservers, vervaldatums, enz.) Bij. DENIC, Duitsland NIC, houdt bijvoorbeeld de DE-domeingegevens. Vanaf ongeveer 2001 hebben de meeste Generic top-level domain (gTLD) -registers deze zogenaamde dikke registerbenadering aangenomen, d.w.z. het bewaren van de WHOIS-gegevens in centrale registers in plaats van in registrar-databases.
Voor topleveldomeinen op COM en NET wordt een dun registratiemodel gebruikt. Het domeinregister (bijvoorbeeld GoDaddy, BigRock en PDR, VeriSign, enz., Enz.) Bevat basis WHOIS-gegevens (d.w.z. registrar- en naamservers, enz.). Organisaties of registranten die ORG gebruiken, staan daarentegen uitsluitend in het register van openbaar belang.
Sommige domeinnaamregisters, ook wel netwerkinformatiecentra (NIC) genoemd, fungeren naast toegang tot de WHOIS-datasets ook als registrars voor eindgebruikers. De topregistraties van domeinen, zoals voor de domeinen COM, NET en ORG, gebruiken een registry-registrar-model dat bestaat uit veel domeinnaamregistrars. Bij deze beheermethode beheert het register alleen de domeinnaamdatabase en de relatie met de registrars. De registranten (gebruikers van een domeinnaam) zijn klanten van de registrar, in sommige gevallen door extra onderaanneming van resellers.
RFC-documenten
Standaarden
Het Domain Name System wordt gedefinieerd door Request for Comments (RFC) -documenten die zijn gepubliceerd door de Internet Engineering Task Force (internetstandaarden). Hieronder volgt een lijst met RFC’s die het DNS-protocol definiëren.
- RFC 1034, Domain Names – Concepts and Facilities
- RFC 1035, Domain Names – Implementation and Specification
- RFC 1123, Requirements for Internet Hosts—Application and Support
- RFC 1995, Incremental Zone Transfer in DNS
- RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
- RFC 2136, Dynamic Updates in the domain name system (DNS UPDATE)
- RFC 2181, Clarifications to the DNS Specification
- RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)
- RFC 2672, Non-Terminal DNS Name Redirection
- RFC 2845, Secret Key Transaction Authentication for DNS (TSIG)
- RFC 3225, Indicating Resolver Support of DNSSEC
- RFC 3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements
- RFC 3596, DNS Extensions to Support IP Version 6
- RFC 3597, Handling of Unknown DNS Resource Record (RR) Types
- RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification
- RFC 4592, The Role of Wildcards in the Domain Name System
- RFC 4635, HMAC SHA TSIG Algorithm Identifiers
- RFC 5001, DNS Name Server Identifier (NSID) Option
- RFC 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors
- RFC 5452, Measures for Making DNS More Resilient against Forged Answers
- RFC 5890, Internationalized Domain Names for Applications (IDNA):Definitions and Document Framework
- RFC 5891, Internationalized Domain Names in Applications (IDNA): Protocol
- RFC 5892, The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
- RFC 5893, Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
- RFC 6891, Extension Mechanisms for DNS (EDNS0)
- RFC 7766, DNS Transport over TCP – Implementation Requirements
Proposed security standards
- RFC 4033, DNS Security Introduction and Requirements
- RFC 4034, Resource Records for the DNS Security Extensions
- RFC 4035, Protocol Modifications for the DNS Security Extensions
- RFC 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records
- RFC 4470, Minimally Covering NSEC Records and DNSSEC On-line Signing
- RFC 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
- RFC 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
- RFC 5910, Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
- RFC 5933, Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
- RFC 7830, The EDNS(0) Padding Option
- RFC 7858, Specification for DNS over Transport Layer Security (TLS)
- RFC 8310, Usage Profiles for DNS over TLS and DNS over DTLS
- RFC 8484, DNS Queries over HTTPS (DoH)
Experimental RFCs
- RFC 1183, New DNS RR Definitions
Best Current Practices
- RFC 2182, Selection and Operation of Secondary DNS Servers (BCP 16)
- RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)
- RFC 5625, DNS Proxy Implementation Guidelines (BCP 152)
- RFC 6895, Domain Name System (DNS) IANA Considerations (BCP 42)
- RFC 7720, DNS Root Name Service Protocol and Deployment Requirements (BCP 40)
Informational RFCs
These RFCs are advisory in nature, but may provide useful information despite defining neither a standard or BCP. (RFC 1796)
- RFC 1178, Choosing a Name for Your Computer (FYI 5)
- RFC 1591, Domain Name System Structure and Delegation
- RFC 1912, Common DNS Operational and Configuration Errors
- RFC 2100, The Naming of Hosts
- RFC 3696, Application Techniques for Checking and Transformation of Names
- RFC 4892, Requirements for a Mechanism Identifying a Name Server Instance
- RFC 5894, Internationalized Domain Names for Applications (IDNA):Background, Explanation, and Rationale
- RFC 5895, Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008
- RFC 7626, DNS Privacy Considerations
- RFC 7706, Decreasing Access Time to Root Servers by Running One on Loopback
Unknown
These RFCs have an official status of Unknown, but due to their age are not clearly labeled as such.
- RFC 920, Domain Requirements – Specified original top-level domains
- RFC 1032, Domain Administrators Guide
- RFC 1033, Domain Administrators Operations Guide
- RFC 1101, DNS Encodings of Network Names and Other Types