Domenenavn system

Domain Name System ( akronym DNS , på italiensk system av domenenavn ), [1] innen informasjonsteknologi og telekommunikasjon , indikerer et system som brukes til å tildele navn til nettverksnoder (på engelsk: host ).

Den indikerer også protokollen som styrer funksjonen til tjenesten, programmene som implementerer den, serverne som disse behandles på, settet med disse serverne som samarbeider for å tilby den mest intelligente tjenesten.

Historie

DNS ble utviklet 23. juni 1983 av Paul Mockapetris , Jon Postel og Craig Partridge [2] [3] ; de originale spesifikasjonene er beskrevet i standarden RFC 882. I 1987 ble det publisert kommentarer til DNS RFC-standarden, med navnene RFC 1034 og RFC 1035 som gjorde de tidligere spesifikasjonene foreldet.

Beskrivelse

DNS-navn, eller "domenenavn" eller "mnemoniske adresser" [4] , er en av de mest synlige egenskapene til Internett . Konverteringen fra navn til IP-adresse kalles "DNS-oppløsning"; konverteringen fra IP-adresse til navn kalles "omvendt oppløsning". Disse navnene kan brukes ved hjelp av en oversettelse, vanligvis kalt "oppløsning", i stedet for de originale IP-adressene . Tjenesten implementeres gjennom en distribuert database , bestående av DNS - servere . DNS har en invertert trehierarkisk struktur og er delt inn i domener (com, org, it, etc.). Hvert domene eller node tilsvarer en navneserver , som holder en database med informasjonen til noen domener som den er ansvarlig for og henvender seg til påfølgende noder når den trenger å finne informasjon som tilhører andre domener.

Hvert domenenavn slutter med en "." (punkt). For eksempel slutter wikipedia.org -adressen med et punktum. Strengen etter den etterfølgende prikken kalles DNS-rotsonen . Serverne som er ansvarlige for rotdomenet er de såkalte rotnavneserverne . De eier listen over autoritative servere for alle anerkjente toppnivådomener (TLDer) og gir den som svar på hver forespørsel. Det er 13 rotnavneservere over hele verden, inkludert 10 i USA , to i Europa ( England og Sverige ) og en i Japan .

I praksis er DNS et universelt register som er en distribuert database , med en hierarkisk struktur, som lagrer mnemoniske domenenavn og deres tilknytning til deres spesifikke IP-adresser.

Årsaker og bruksområder

• Muligheten til å tilordne et tekstnavn som er enkelt å huske til en server (for eksempel et verdensomspennende nettsted ) forbedrer bruken av tjenesten betraktelig, ettersom mennesker finner det lettere å huske tekstnavn (mens verter og rutere er tilgjengelige ved hjelp av numeriske IP-adresser). Av denne grunn er DNS grunnleggende for den utbredte spredningen av internett selv blant ikke-tekniske brukere, og er en av dens mest synlige funksjoner.
• Det er mulig å tilordne flere navn til samme IP-adresse (eller omvendt) for å representere forskjellige tjenester eller funksjoner levert av samme vert (eller flere verter som tilbyr samme tjeneste). Denne "fleksibiliteten" er nyttig i mange tilfeller:
  • I tilfelle serveren som er vert for en tjeneste må byttes ut, eller IP-adressen må endres, endrer du ganske enkelt DNS -posten uten å måtte gripe inn på klientene .
  • Ved å bruke forskjellige navn for å referere til de forskjellige tjenestene som tilbys av samme vert (derfor registrert med samme IP-adresse), er det mulig å flytte en del av tjenestene til en annen vert (med en annen IP-adresse, allerede satt opp for å tilby de aktuelle tjenestene). Derfor, ved å endre navnepostene knyttet til tjenestene som skal flyttes på DNS- serveren og registrere den nye IP-en i stedet for den gamle, vil de nye forespørslene fra alle klientene automatisk bli flyttet til denne nye verten uten å avbryte tjenestene.
  • En veldig populær bruk av denne muligheten er såkalt virtuell hosting , basert på navn, en teknikk der en nettserver med et enkelt nettverksgrensesnitt og en enkelt IP-adresse kan være vert for flere nettsteder, ved å bruke den alfanumeriske adressen som overføres i HTTP - overskriften til identifisere nettstedet som forespørselen er gjort for.
  • Ved å matche et navn til flere IP-adresser, blir belastningen til klientene som ber om dette navnet spredt over de forskjellige serverne som er knyttet til de registrerte IP-ene, noe som resulterer i en økning i den totale tjenesteytelsen og feiltoleransen (men du må sørge for at de forskjellige servere er alltid justert, dvs. tilbyr nøyaktig den samme tjenesten til klienter ).
• Omvendt oppløsning er nyttig for å identifisere identiteten til en vert , eller for å lese resultatet av en traceroute .
• DNS brukes av en rekke teknologier på en måte som ikke er veldig synlig for brukerne, for å organisere informasjonen som er nødvendig for at tjenesten skal fungere.

Domenenavn

Et domenenavn består av en serie strenger atskilt med punktum, for eksempel it.wikipedia.org . og er organisert i nivåer. I motsetning til IP-adresser, hvor den viktigste delen av nummeret er det første sifferet som starter fra venstre, i et DNS-navn er den viktigste delen den første som starter fra høyre.

Den delen til høyre kalles Top Level Domain (eller TLD ), og det er hundrevis av dem som kan velges, for eksempel .orgeller .it.

Et andrenivådomene , i motsetning til toppnivådomenet som består av "faste" og begrensede ord, består av et ord valgt etter eget ønske. Dette ordet må i størst mulig grad knyttes til det som identifiserer oss og det vi ønsker å kommunisere. Det andre nivådomenet består derfor av to deler, for eksempel wikipedia.org, og så videre.

Domenet på tredje nivå er underordnet av domenet på andre nivå, faktisk, med wikipedia.org som eksempel, vil et domene på tredje nivå være: stuff.wikipedia.org. Hvert ytterligere element spesifiserer derfor en ytterligere underinndeling. Når et domene på andre nivå er registrert hos tilordneren, er tilordnet autorisert til å bruke domenenavnene knyttet til følgende nivåer, for eksempel some.other.stuff.wikipedia.org(domene på femte nivå) og så videre.

Bruke DNS-navn

Et domenenavn, for eksempel it.wikipedia.org , kan være en del av en URL , for eksempel http://it.wikipedia.org/wiki/Treno, eller en e -postadresse , for eksempel apache @ it .wikipedia . org . Det er også mulig å koble til et nettsted med telnet - protokollen eller bruke en FTP -tilkobling ved å bruke domenenavnet.

DNS Record

Posttyper

Ulike typer informasjon kan tilsvare et DNS-navn. Av denne grunn finnes det flere typer DNS-poster . Hver DNS - databaseoppføring [5] må ha en type. Hovedtypene er:

• Oppføring A - Indikerer samsvaret mellom et navn og én (eller flere) IPv4 -adresser .
• MX-post - ( Mail eXchange ) indikerer til hvilke servere e -post skal sendes for et bestemt domene.
• CNAME-poster - De brukes til å lage et alias, det vil si for å sikre at den samme verten er kjent med flere navn. En av bruksområdene for denne typen poster er å gi en vert som tilbyr flere tjenester et navn for hver tjeneste. På denne måten kan tjenestene flyttes til andre verter uten å måtte rekonfigurere klientene , men bare ved å endre DNS.
• PTR-post - DNS brukes også til å utføre omvendt oppløsning , dvs. å matche det tilsvarende domenenavnet til en IP-adresse. For dette bruker vi postene av typen "PTR" (og et spesielt område av navneområdet in-addr.arpa ).
• AAAA Record - Dette er som Record A , men fungerer med IPv6 og returnerer en IPv6 -adresse .
• SRV Records - Identifiser serveren for en bestemt tjeneste innenfor et domene. De kan betraktes som en generalisering av MX-poster.
• TXT-poster – Knytt vilkårlige tekstfelt til et domene. Disse feltene kan inneholde en informativ beskrivelse eller brukes til å lage tjenester.

Det finnes også typer "tjeneste"-poster som er nødvendige for at den distribuerte databasen skal fungere:

• NS Record - Brukes til å indikere hvilke DNS-servere som er autoritative for et bestemt domene, eller for å delegere deres administrasjon.
• SOA Record - ( Start of Authority ) brukes til å administrere DNS-soner.

I DNS kan legges inn andre typer poster, noen folkloriske, for eksempel "LOC", brukes (lite) for å rapportere de geografiske koordinatene til et nettsted, andre legger til sikkerhetsfunksjoner for å unngå tukling. For referanser til alle disse postene, se DNS Record Types .

Flere poster

Poster av forskjellige typer, eller flere poster av samme type , kan knyttes til samme domenenavn samtidig. Dette gjøres vanligvis for å spre belastningen på en opptatt server over flere datamaskiner som tilbyr samme tjeneste.

Tid til å leve

Oppføringene knyttet til et domenenavn kan endres over tid, slik at det for eksempel kan tildeles en ny IP-adresse til en server , slik at den fortsetter å svare på navnet som allerede er kjent for brukerne.

Hver DNS-post har en tilknyttet parameter kalt time to live eller TTL (time to live), som indikerer hvor lenge denne posten kan lagres i et DNS- buffersystem før den anses som utløpt. Når en server svarer på en forespørsel med en post hentet fra hurtigbufferen , tildeler den postens gjenværende tid til å leve til svaret . Så hvis posten opprinnelig har en 12 timers TTL, og en server svarer på en forespørsel med data den fikk for to timer siden, vil den legge inn en 10 timers TTL i svaret.

Realisering

DNS implementerer et hierarkisk navneområde for å tillate at deler av et navneområde, kjent som "soner", kan delegeres fra én navneserver til en annen navneserver lenger ned i hierarkiet.

Domenenavn er underlagt visse begrensninger: for eksempel kan hver del av navnet (dvs. den som er begrenset av punktum i navnet) ikke overstige 63 tegn og det totale navnet kan ikke overstige 255 tegn.

Domenenavn er også begrenset til et undersett av ASCII- tegn ; dette hindrer deg i å skrive navn og ord med tegn som ikke alle har på tastaturet. For å overvinne denne begrensningen er IDNA- systemet basert på Punycode -modellen , oppdager Unicode -strenger i et gyldig DNS-tegnsett, ble godkjent av ICANN og adoptert av noen registre .

Soner, delegasjoner og kopier

En DNS "sone" er en del av navneområdet, bestående av et domene og dets underdomener som ikke selv er delegert, som er under samme administrative administrasjon og derfor administreres av en eller flere servere.

Forvaltningen av en sone "delegeres" av den øvre sonen gjennom NS type poster. For eksempel, i .org -sonen vil det være en delegering for wikipedia.org -sonen til DNS- serverne som administrerer den. Av redundansårsaker blir hver sone "replikert" på flere servere , og følgelig består delegasjonen av flere NS- poster , som indikerer at hver av de angitte serverne inneholder informasjonen for den sonen (dvs. den er "autoritativ" for sonen) . Innenfor en sone kan soner på lavere nivå delegeres, for eksempel i wikipedia.org kan det være delegasjoner for devel.wikipedia.org eller for accounting.admin.wikipedia.org .

Hvert domene har derfor en autoritativ DNS-server. [6]

De forskjellige serverne som er delegert for en sone bør inneholde samme informasjon, slik at en av dem kan svare på en forespørsel om en post i sonen.

Replikeringsskjemaet har vanligvis en hovedserver (primær), som er den som informasjonen oppdateres på, og en eller flere slaveservere (sekundær) som kopierer informasjon fra masteren ved behov. For å holde styr på de forskjellige "versjonene" av en sone som kan være i omløp, og spesielt for å la en sekundær bestemme om sonen skal overføres fra primærsonen, har hver sone et serienummer, som må økes hver gang endres er laget på primæren. For å få serienummeret til en sone som er tilstede på en server , utføres en SOA-typespørring. Sekundæren sammenligner serienummeret med den primære, og hvis den til primæren er høyere, overfører den sonen.

Operasjonen med å kopiere alle postene til en sone fra masteren til en slave kalles soneoverføring , og kan være fullstendig (alt innholdet i sonen kopieres) eller inkrementell (bare postene som er modifisert i forhold til versjonen som allerede er til stede er kopiert).

Noen DNS-implementeringer lar deg endre soner fra en hvilken som helst autoritativ server, og sprer endringene til andre servere .

Roten ( roten ) til DNS-navntreet er sonen. (periode), som administreres av et sett med servere kalt rotservere .

Iterasjon og rekursjon

Generelt, for å få oppløsningen til et navn er det nødvendig å starte fra roten, spørre en av rotserverne i toppnivådomenet, skaffe serveren som administrerer det, spørre det i andrenivådomenet, til du når den autoritative serveren for ønsket navn. Denne teknikken kalles "iterasjon".

Recursion delegerer i stedet de forskjellige spørringene til serverne selv: en forespørsel sendes til rotserveren , som selv videresender den til TLD- serveren , som videresender den til den autoritative serveren og så videre til ønsket server er nådd. DNS-svaret fortsetter i revers til det når klienten som sendte forespørselen.

Buffer

Noen servere egner seg til å utføre rekursive spørringer på vegne av enkelte klienter . Når de får svar, cacher de all informasjonen de har lært til den utløper. Noen implementeringer av DNS-tjenesten tillater opprettelse av såkalte caching only -servere , dvs. uten egen database , men nyttig for å omdirigere oppløsningsspørringer til en autoritativ server . Denne funksjonen er spesielt nyttig når oppløsningen må gjøres gjennom langsomme koblinger (med hastigheter under 500 kbps) eller brannmurer .

Serverfunksjoner _

En DNS-server kan konfigureres til å utføre en eller flere av følgende funksjoner:

• autoritativ server for en eller flere soner, det vil si serveren som dataene til en sone er konfigurert på, og som er delegert til å administrere den gjennom NS-poster som er satt inn i den øvre sonen. Det er vanligvis flere autoritative servere for en sone. Mange implementeringer lar deg endre sonedata bare på én server :
  • primær - autoritativ server der sonedata endres
  • sekundær - autoritativ server som kopierer sonedata fra en primær
• rekursiv server - serveren som er konfigurert til en klientpopulasjon , som tar seg av å løse spørringene den mottar ved å spørre de originale serverne, og holde en hurtigbuffer over mottatte svar
  • query forwarder - en server som er konfigurert til en populasjon av klienter , som løser spørsmålene deres ikke direkte, men ved å spørre en rekursiv server , og ofte holde en hurtigbuffer over mottatte svar

Opprinnelsen til data

Dataene i en sone kan konfigureres av en eller flere operatører, eller kan mates av automatiske mekanismer:

• i enklere implementeringer lagres sonedata i en eller flere filer på primærserveren
• mer raffinerte implementeringer lagrer dataene i en database . I noen tilfeller er dette ikke bare tilgjengelig for tjenesteoperatører, men også direkte for kunder (dette er tilfellet med kommersielle DNS-tjenester)

Dynamisk DNS

Begrepet dynamisk DNS , eller DDNS , indikerer et sett med teknologier som tillater at adressene til datamaskiner som får en ikke-forhåndsdefinert adresse, automatisk legges inn i en DNS-sone, vanligvis gjennom DHCP- eller PPP -protokollen . For dette formålet er "OPPDATERING" DNS -spørringer definert .

I et lokalt nettverk kan denne funksjonaliteten brukes direkte av klienter , finnes i Windows Active Directory-tjenester , eller den kan konfigureres ved hjelp av BIND og Internet Systems Consortium (ISC) DHCP-server .

DDNS brukes også av kommersielle tjenester for å tillate oppringte brukere (modem, ADSL ) å registrere et navn som tilsvarer adressen som er tildelt dem fra tid til annen av leverandøren deres . På denne måten er en vert med en dynamisk IP-adresse alltid tilgjengelig. Det finnes DDNS - klienter både i form av applikasjoner og innenfor rutere beregnet på hjemmemarkedet.

Bruk

For å bruke tjenesten må én eller flere henvisnings-DNS-servere konfigureres på hver klient . Disse er designet for å utføre rekursive spørringer og utføre hurtigbufringstjenester .

Når et system trenger å kommunisere med et annet system, ber det den henvisende DNS-serveren om å utføre prosessen som kalles "oppløsning" av navnet til en IP-adresse. Serveren søker i databasen sin for å få IP-adressen som tilsvarer det søkte systemet.

Hvis den forespurte serveren har den forespurte informasjonen, avsluttes søkeprosessen med å sende IP-adressen til rekvirenten. Hvis søket mislykkes, sender serveren en "rekursiv" forespørsel. [7] [8]

Implementering

DNS- protokollen implementeres av ulike programvarer . Her er noen av de mest populære:

• BIND (Berkeley Internet Name Domain), navnet på den vanligste DNS - demonen som brukes på Unix -systemer .
• DJBDNS (Dan J Bernsteins DNS-implementering)
• Ubundet , en modulært utformet DNS-server med spesielt hensyn til DNSSEC .
• MaraDNS
• NSD ( Name Server Daemon )
• PowerDNS
• DDNS ( Dynamic Domain Name System ) DNS-tjenesten som ligger til grunn for Microsoft-katalogtjenester inkludert i serverversjoner fra Windows 2000 og utover .

DNS bruker UDP -transportprotokollen og port 53 for å betjene forespørsler om oppløsning fra verter.

DNS-servere utfører soneoverføringer ved hjelp av TCP - transportprotokollen og port 53. Denne porten brukes også når en spørring har svært lang respons.

Klientsiden av DNS - tjenesten implementeres normalt gjennom systembiblioteker, som ofte integrerer den med andre løsningstjenester, slik som WINS , NIS , eller ved å konsultere lokale filer, slik at en bruker kan bruke et symbolsk navn i en applikasjon og få dets oppløsning til en IP-adresse uten å bekymre deg for hvilket verktøy som ble brukt for å få oppløsningen.

DNS-system på Internett

Ethvert IP -nettverk kan bruke DNS til å implementere sitt eget private navnesystem. Imidlertid er begrepet "domenenavn" mer vanlig brukt når det refererer til det offentlige DNS-systemet på Internett. Dette er basert på 13 universelle rotservere , hvis IP-adresser distribueres uavhengig av DNS via en fil som kalles rothintet (bokstavelig talt: ledetråder til roten). Fra disse rotserverne blir DNS deretter delegert til andre DNS- servere som tar seg av navnene innenfor bestemte deler av DNS-navneområdet.

Ti av de tretten rotserverne er, i det minste nominelt, lokalisert i USA . Men siden tilgang til mange av dem oppnås gjennom anycast- adressering , som gjør at flere datamaskiner kan tildeles samme IP-adresse for å gi enhetlig tjeneste over store geografiske områder, er de fleste servere faktisk plassert utenfor USA.

Eieren av et domenenavn kan bli funnet i en database kalt Whois : for mange toppnivådomener administreres en grunnleggende Whois av IANA , med detaljerte Whois vedlikeholdt av registraren som kontrollerer det domenet. For de mer enn 240 nasjonale domenene administrerer registreringsmyndigheten Whois utelukkende for kompetansedomenet.

Et nettsted eller nettapplikasjon kan hostes hos en leverandør ( vertsleverandør ) eller til og med lagres på eierens eller lederens hovedkvarter, mens det relaterte domenet kan ha blitt kjøpt fra en annen leverandør, vanligvis kjent som en registrar (som derfor eier en DNS-infrastruktur) . Registraren tillater, gjennom administrasjonspanelet, å konfigurere den primære IP-en som domenenavnet er knyttet til, samt å opprette underdomener.

Retningslinjer

Tildeling av soner på første nivå

Den nåværende måten å sjekke DNS-systemet byr ofte på noen kritiske problemer. Noen rotservere tilhører private selskaper (f.eks . Verisign ), selv om de fleste er kontrollert av universiteter eller andre enheter (f.eks . NASA ) [9] . Det er ikke mulig å legge til andre rotservere , eller i det minste ikke fysisk: på grunn av et kompatibilitetsproblem med UDP -protokollen skal bare 13 rotserversoner være synlige , men hver sone kan ha flere servere [ 10] .

Feil bruk

I 2009 la Paul Vixie, president for Internet Systems Consortium , på nettstedet til Association for Computing Machinery en artikkel om praksis som stammer fra feiltolkninger av DNS-konseptet eller bevisst bryter det. [11]

Responsmanipulering

Når en klient videresender en DNS - spørring til en rekursiv server , forventer den å få det "riktige" svaret, som er verdien av den forespurte DNS-posten eller en feilmelding hvis det forespurte navnet ikke eksisterer. Denne meldingen er kjent som "NXDOMAIN" eller også som "RCODE = 3".

Noen rekursive serveradministratorer manipulerer imidlertid svarene som gis til kundene deres, enten selektivt eliminerer noen eller ved å returnere en annen IP-adresse enn den riktige.

Denne teknikken kan brukes til flere formål:

• beskyttelse mot misbruk: DNS-serveren kan filtrere forespørsler knyttet til nettsteder som er farlige for brukere, for eksempel på grunn av distribusjon av skadelig programvare , eller fordi de brukes til phishing- operasjoner ;
• sensur: Forespørsler knyttet til nettsteder som skal gjøres utilgjengelige ved politisk beslutning (fra nettverkssjefen eller en offentlig myndighet) filtreres. Hvis besøket eller forsøket på besøk på "forbudte" nettsteder er kvalifisert som en indikasjon på kriminalitet , kan omdirigering av trafikk til en annen server enn den som er forespurt av brukeren tillate innsamling av klientens IP-adresser , eller til og med i noen tilfeller legitimasjonstyveri;
• man-in-the-middle : spørringer er modifisert for å omdirigere hele eller deler av trafikken til en server som fungerer som en transparent proxy , som avskjærer brukertrafikk. Dette tillater overvåking av brukertrafikk, og derfor, muligens, også tyveri av sensitiv informasjon og/eller legitimasjon;
• omdirigering av feil: spørringer etter ikke-eksisterende navn besvares med IP-adressen til en server , som vanligvis er vert for en søkemotor og forsøker å hjelpe brukere med å finne nettstedet de leter etter. [11]

Disse teknikkene kan også tas i bruk av nettverksadministratorer, ved å omdirigere DNS- spørringer rettet utover på deres servere ved å bruke destinasjons-NAT ( Nettverksadresseoversettelse )-mekanismer.

DNS-en ble ikke utformet for disse bruksområdene, derfor kan sikkerhetsimplikasjonene til brukere være negative, ettersom den personlige informasjonen som deles mellom en bruker og nettstedet de besøker, også utveksles med tredjepartssider, ikke autorisert. [11]

Merknader

1. ^ ( EN ) domenenavnsystem - Oversettelse på italiensk - TechDico , på www.TechDico . Hentet 19. juli 2019 .
2. ^ Hvorfor fungerer nettet fortsatt i julen? Paul Mockapetris | Internet Hall of Fame , på www.internethalloffame.org . Hentet 13. juli 2022 .
3. ^ Paul Mockapetris | Internet Hall of Fame , på internethalloffame.org . Hentet 13. juli 2022 .
4. ^ Mnemonisk adresse (for eksempel www.wikipedia.org) fordi det er lett å huske på mens IP-adresser er mye mer kompliserte å huske.
5. ^ John O., Hosting - Hva det er, betydning, definisjon og anmeldelser. , på Infowebhosting . Hentet 27. oktober 2017 .
6. ^ DNS (Domain Name System): hvordan det fungerer - FortyZone , på fortyzone.it . Hentet 8. september 2015 (arkivert fra originalen 5. november 2015) .
7. ^ Her er hvordan du bruker 1.1.1.1, DNS som respekterer personvernet , i LaStampa.it . Hentet 6. april 2018 (Arkiveret fra originalen 6. april 2018) .
8. ^ Ny DNS 1.1.1.1, rask og sikker: her er de første testene (og hvordan du bruker det) , i maskinvareoppgradering . Hentet 6. april 2018 .
9. ^ Offisiell rotserverside - http://www.root-servers.org/
10. ^ Det er ikke 13 rotservere
11. ^ a b c Paul Vixie, hva DNS ikke er. DNS er mange ting for mange mennesker - kanskje for mange ting for for mange mennesker , på dl.acm.org , november 2009.
    Artikkelen er også tilgjengelig på ACMs nettsted.

Relaterte elementer

• 1.1.1.1
• Omvendt DNS-oppløsning
• DNS-post
• Dynamisk DNS
• Googles offentlige DNS
• DNSSEC
• JEG KAN
• OpenNIC
• Nslookup
• Cybersquatting
• Internasjonalisert domenenavn

Andre prosjekter

• Wikiversity inneholder ressurser på domenenavnsystemet
• Wikimedia Commons inneholder bilder eller andre filer på domenenavnsystemet

Eksterne lenker

Juridiske profiler

• Domenenavn: regulatoriske profiler , CyberLaws.it

ICANN

• ( NO ) ICANN-nettsted

RFC

• ( EN ) RFC 882 , Domenenavn - Konsepter og fasiliteter (gjort foreldet av RFC 1034 )
• ( EN ) RFC 883 , Domenenavn - Implementering og spesifikasjon (gjort foreldet av RFC 1035 )
• ( EN ) RFC 920 , Domenekrav - Spesifiserte originale toppdomener
• ( EN ) RFC 1032 , Veiledning for domeneadministratorer
• ( EN ) RFC 1033 , Driftsveiledning for domeneadministratorer
• ( EN ) RFC 1034 , Domenenavn - Konsepter og fasiliteter
• ( EN ) RFC 1035 , Domenenavn - Implementering og spesifikasjon
• ( EN ) RFC 1101 , DNS - koding av nettverksnavn og andre typer
• ( EN ) RFC 1123 , Krav til internettverter — applikasjon og støtte
• ( NO ) RFC 1178 , Velge et navn for datamaskinen din (FYI 5)
• ( EN ) RFC 1183 , Nye DNS RR-definisjoner
• ( EN ) RFC 1591 , struktur og delegering av domenenavne (informasjon)
• ( EN ) RFC 1912 , Vanlige DNS-drifts- og konfigurasjonsfeil
• ( EN ) RFC 1995 , Inkrementell soneoverføring i DNS
• ( EN ) RFC 1996 , A Mechanism for prompt notification of sone change (DNS NOTIFY)
• ( EN ) RFC 2100 , Navngivningen av verter (informasjon)
• ( EN ) RFC 2136 , Dynamiske oppdateringer i domenenavnsystemet (DNS-OPPDATERING)
• ( EN ) RFC 2181 , Forklaringer til DNS-spesifikasjonen
• ( EN ) RFC 2182 , Valg og drift av sekundære DNS-servere
• ( EN ) RFC 2308 , negativ bufring av DNS-søk (DNS NCACHE)
• ( EN ) RFC 2317 , Klasseløs IN-ADDR.ARPA-delegering (BCP 20)
• ( EN ) RFC 2671 , utvidelsesmekanismer for DNS (EDNS0)
• ( EN ) RFC 2672 , omdirigering av ikke-terminal DNS-navn
• ( EN ) RFC 2845 , hemmelig nøkkeltransaksjonsautentisering for DNS (TSIG)
• ( EN ) RFC 3225 , Indikerende resolverstøtte for DNSSEC
• ( EN ) Krav til størrelseskrav for RFC 3226 , DNSSEC og IPv6 A6 A6 server / løser meldingsstørrelse
• ( EN ) RFC 3597 , Håndtering av ukjente DNS-ressursposttyper (RR)
• ( EN ) RFC 3696 , Applikasjonsteknikker for kontroll og transformasjon av navn (informativt)
• ( EN ) RFC 4033 , DNS-sikkerhetsintroduksjon og -krav
• ( EN ) RFC 4034 , Ressursposter for DNS-sikkerhetsutvidelsene
• ( EN ) RFC 4035 , Protokollendringer for DNS-sikkerhetsutvidelsene
• ( EN ) RFC 4343 , Domain Name System (DNS) Ufølsomhetsavklaring
• ( EN ) RFC 4470 , som minimalt dekker NSEC Records og DNSSEC on-line signering
• ( EN ) RFC 4509 , Bruk av SHA-256 i DNSSEC Delegation Signer (DS) Resource Records
• ( EN ) RFC 4592 , Jokertegnens rolle i domenenavnsystemet
• ( EN ) RFC 4635 , HMAC SHA TSIG Algoritmeidentifikatorer
• ( EN ) RFC 4892 , Krav til en mekanisme som identifiserer en navneserverforekomst (informativt)
• ( EN ) RFC 5001 , DNS-navneserveridentifikator (NSID) Alternativ
• ( EN ) RFC 5011 , Automatiserte oppdateringer av DNS Security (DNSSEC) Trust Anchors
• ( EN ) RFC 5155 , DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
• ( EN ) RFC 5395 , Domain Name System (DNS) IANA-hensyn (BCP 42)
• ( EN ) RFC 5452 , tiltak for å gjøre DNS mer motstandsdyktig mot forfalskede svar
• ( EN ) RFC 5625 , retningslinjer for implementering av DNS proxy (BCP 152)
• ( EN ) RFC 5702 , Bruk av SHA-2 algoritmer med RSA i DNSKEY og RRSIG Resource Records for DNSSEC