domenenavn system
Funksjon | Oversettelse domenenavn i IP-adresse |
---|---|
Forkortelse | DNS |
Havn | 53 |
RFC |
1983 : RFC 882 - RFC 883 1987 : RFC 1034 - RFC 1035 1994 : RFC 1591 2011 : RFC 6195 2013 : RFC 6895 2018 : RFC 8375 - RFC 8467 - RFC 8483 - RFC 8484 2019 : RFC 8499 |
Den Domain Name System , vanligvis forkortet DNS , som kan oversettes som "Domain Name System", er distribuert datatjeneste som brukes til å oversette domenenavn på Internett til IP-adresser eller andre poster . Ved å tilby en distribuert navneløsningstjeneste fra Internett, rundt 1985, har DNS vært en viktig komponent i utviklingen av nettverket.
På forespørsel fra US Defense Advanced Research Projects Agency ( DARPA ) designet Jon Postel og Paul Mockapetris Domain Name System i 1983 og skrev den første implementeringen.
Utstyr ( verter ) koblet til et IP-nettverk, for eksempel Internett , har en IP-adresse som identifiserer dem på nettverket. Disse adressene er numeriske for å forenkle behandlingen av dem. I IPv4 er de representert som “- - -. - - -. - - -. - - - ”, der hver“ gruppe ”på tre bindestreker kan erstattes av et tall mellom 0 og 255 (i desimalrepresentasjon ). I IPv6 er adressene representert i formen "....: ....: ....: ....: ....: ....: ....: ...." , Hvor hver “gruppe” på fire punkter kan erstattes med en heksadesimal verdi fra 0000 til FFFF.
For å gjøre det lettere å få tilgang til verter i et IP-nettverk, har det blitt innført en mekanisme for å knytte et navn til en IP-adresse. Dette navnet, som er lettere å huske, kalles et " domenenavn ". Å løse et domenenavn innebærer å finne IP-adressen som er tilknyttet det.
I tillegg til IP-adresser, kan tilleggsinformasjon knyttes til domenenavn som poster i sammenheng med antispam ( SPF ), RRSIG for DNS-informasjonssikkerhet ( DNSSEC ) eller NAPTR for tilknytning av numre. Telefon til e-postadresser ( ENUM ).
Før DNS måtte løse et Internett-navn gjøres gjennom en tekstfil kalt HOSTS.TXT ( RFC 608) vedlikeholdt av NIC fra Stanford Research Institute (SRI) og kopiert til hver datamaskin på nettverksfiloverføringen. I 1982 viste dette sentraliserte systemet sine grenser, og flere erstatningsforslag dukket opp, inkludert det distribuerte systemet Grapevine fra Xerox og IEN 116. Det første ( Grapevine ) ble ansett for komplisert mens det andre (IEN 116) var utilstrekkelig. Til slutt vil teamet ledet av Elizabeth Feinler ved NIC definere Domain Name System for å håndtere veksten på Internett ved å delegere administrasjonen av domenenavn til distribuerte navneservere. Paul Mockapetris publiserte designet av systemet i RFC 882 og RFC 883 i 1983. Tilsvarende standard ble publisert i RFC 1034 og RFC 1035 i 1987. I 1987 inneholdt HOSTS.TXT-filen 5500 oppføringer, mens 20 000 verter ble definert i DNS .
Domenenavnsystemet består av et hierarki, hvis topp kalles roten . Vi representerer sistnevnte med et poeng. I et domene kan ett eller flere underdomener opprettes, samt en delegasjon for dem, det vil si en indikasjon på at informasjonen knyttet til dette underdomenet er registrert på en annen server. Disse underdomenene kan i sin tur delegere underdomener til andre servere.
Ikke alle underdomener er nødvendigvis delegert. Delegasjoner oppretter soner , det vil si sett med domener og deres ikke-delegerte underdomener som er konfigurert på en bestemt server. Soner forveksles ofte med domener.
Områdene som ligger rett under roten kalles toppnivådomene (TLD: Top Level Domain). Domenenavn som ikke tilsvarer en landsutvidelse kalles generiske domener (gTLDs), for eksempel .org eller .com. Hvis de tilsvarer landskoder (fr, be, ch…), er de nasjonale toppdomener , også kalt ccTLD fra engelsk landskode TLD .
Et domenenavn er representert ved å indikere suksessive domener atskilt med en prikk, de høyere domenenavnene er til høyre. For eksempel domeneorganisasjonen. er en toppdomene, underdomenet til roten. Wikipedia.org- domenet . er et underdomene til .org . Denne delegasjonen oppnås ved å spesifisere listen over DNS-servere som er tilknyttet underdomenet i toppdomenet.
Domenenavnene løses derfor ved å bla gjennom hierarkiet fra toppen og følge de påfølgende delegasjonene, det vil si ved å bla gjennom domenenavnet fra høyre til venstre.
For at det skal fungere normalt, må et domenenavn ha blitt delegert riktig på toppnivådomenet.
Verter har begrenset kunnskap om domenenavnsystemet. Når de må løse et navn, henvender de seg til en eller flere såkalte rekursive navneservere , det vil si at de vil bla gjennom DNS-hierarkiet og videresende forespørselen til en eller flere andre navneservere for å gi svar. IP-adressene til disse rekursive serverne blir ofte hentet via DHCP eller hardkonfigurert på vertsmaskinen. Den Internett-leverandører gjøre tilgjengelig for sine kunder disse rekursive servere. Det er også offentlige rekursive servere som Cloudflare , Yandex.DNS , Google Public DNS eller OpenNIC .
Når en rekursiv DNS-server trenger å finne IP-adressen til fr.wikipedia.org , begynner en iterativ prosess å slå opp DNS-hierarkiet. Denne serveren ber DNS-serverne kalt root- servere hvilke servere som kan svare på den for org- sonen . Blant disse vil serveren velge en for å vite hvilke servere som kan svare på den for wikipedia.org- sonen . Det er en av disse som vil kunne gi ham IP-adressen til fr.wikipedia.org . Hvis en server ikke reagerer, vil en annen server på listen bli konsultert.
For å optimalisere etterfølgende spørsmål fungerer rekursive DNS-servere også som en DNS-cache : de holder svaret på en navneløsning i minnet ( cache ) slik at denne prosessen ikke blir utført senere. Denne informasjonen oppbevares i en periode kalt Time to live og tilknyttet hvert domenenavn.
Et domenenavn kan bruke flere DNS-servere. Vanligvis bruker domenenavn minst to: et primært og et sekundært. Det kan være flere sekundære servere.
Alle primære og sekundære servere er autoritative for et domene, det vil si at svaret ikke ringer til en annen server eller cache. Rekursive servere gir svar som ikke nødvendigvis er oppdatert på grunn av hurtigbufferen. Dette blir referert til som et ikke-autoritativt svar .
Denne arkitekturen garanterer internettnettverket en viss kontinuitet i navneløsning. Når en DNS-server går ned, kompromitteres ikke riktig oppløsning av navn så lenge sekundære servere er tilgjengelige.
For å finne domenenavnet som er knyttet til en IP-adresse, brukes et lignende prinsipp. I et domenenavn er den mest generelle delen til høyre: org i fr.wikipedia.org, oppløsningsmekanismen skanner derfor domenenavnet fra høyre til venstre. I en V4 IP-adresse er det motsatt: 213 er den mest generelle delen av 213.228.0.42. For å opprettholde sammenhengende logikk, snur vi rekkefølgen på de fire vilkårene i adressen og sammenkobler den til pseudodomenet in-addr.arpa . Så for eksempel for å finne domenenavnet til IP-adressen 91.198.174.2, løser vi 2.174.198.91.in-addr.arpa.
Den omvendte uttalelsen er viktig på offentlige IP-adresser på internett, siden fraværet av en omvendt oppløsning betraktes som en operasjonsfeil ( RFC 1912) som kan føre til nektelse av tilgang til en tjeneste. For eksempel er det sannsynlig at en e-postserver som presenterer seg selv som sending med en IP-adresse uten omvendt oppløsning (PTR), vil bli avvist av den eksterne verten, overføringen av e-posten (meldingen om avslag av typen: IP-oppslag mislyktes. ).
I tillegg er denne omvendte oppløsningen viktig i sammenheng med å utføre nettverksdiagnostikk, fordi det er dette som gjør det mulig å gjøre resultatene av traceroute- kommandoen menneskelig utnyttbare. Navnene på omvendte vertsnavn er ofte sammensetninger av lokaliseringsunderdomener (by, region, land) og eksplisitte domener som indikerer at Internett-tilgangsleverandøren er krysset, for eksempel francetelecom.net (- - - -ctct202.Toulouse .francetelecom.net) og opentransit .net (- - - -.Aubervilliers.opentransit.net) for France Telecom , eller proxad.net (- - - -.intf.routers.proxad.net) gratis .
En IP-adresse kan tilknyttes forskjellige domenenavn ved å registrere flere PTR-oppføringer i .arpa- underdomenet dedikert til den adressen (in-addr.arpa. For IPv4 og ip6.arpa. For IPv6 ). Bruken av flere PTR-poster for samme IP-adresse er muligens til stede i sammenheng med den virtuelle verten av flere nettdomener bak den samme IP-adressen, men anbefales ikke siden antallet PTR-felt som skal returneres kan føre til at svaret overskrider størrelsen på UDP- responspakker og forårsake bruk av TCP (dyrere i ressurser) for å sende svaret til DNS-spørringen.
CIDR invers oppløsningDelegasjonene av omvendte soner er på en bytegrense, som fungerer når adresseblokker er klassisk fordelt, men forårsaker problemer når tildelte blokker er av hvilken som helst størrelse.
For eksempel, hvis to klienter A og B hver har blokker 192.168.0.0/25 og 192.168.0.128/25, er det ikke mulig å delegere 0.168.192.in-addr.arpa. til den første slik at den kan definere PTR-ene som tilsvarer vertene, fordi dette ville forhindre den andre i å gjøre det samme.
De RFC 2317 definerer en fremgangsmåte for å håndtere dette problemet, er det å gjøre bruk av mellomliggende områder og CNAME.
$ORIGIN 0.168.192.in-addr.arpa. 0/25 NS ns.clientA.fr. 128/25 NS ns.clientB.fr. 0 CNAME 0.0/25.0.168.192.in-addr.arpa. 1 CNAME 1.0/25.0.168.192.in-addr.arpa. ... 127 CNAME 127.0/25.0.168.192.in-addr.arpa. 128 CNAME 128.128/25.0.168.192.in-addr.arpa. ... 255 CNAME 255.128/25.0.168.192.in-addr.arpa.Klient A definerer sone 0 / 25.0.168.192.in-addr.arpa. :
$ORIGIN 0/25.0.168.192.in-addr.arpa. 1 PTR hote1.clientA.fr. ... 127 PTR hote127.clientA.fr.Klient B gjør det samme for 128 / 25.0.168.192.in-addr.arpa. og adresserer 128 til 255.
Å reversere 192.168.0.1 vil resultere i følgende spørsmål:
1.0.168.192.in-addr.arpa. CNAME 1.0/25.0.168.192.in-addr.arpa. 1.0/25.0.168.192.in-addr.arpa. PTR hote1.clientA.fr.Dette sikrer driften av omvendt oppløsning, med et ekstra nivå av indireksjon.
Rotserverne administreres av tolv forskjellige organisasjoner: to er europeiske, en japansk og de andre ni er amerikanske. Syv av disse serverne distribueres faktisk over hele verden ved hjelp av anycast- teknikken, og ni har en IPv6- adresse . Takket være anycast tilbyr mer enn 200 servere i 50 land over hele verden denne tjenesten. Det er 13 navnemyndigheter kalt fra a til m.root-servers.net. Serveren k mottar for eksempel størrelsesorden 70.000 til 100.000 forespørsler per sekund iapril 2019.
DNS gir ikke en mekanisme for å oppdage listen over rotservere , så hver server må kjenne denne listen ved oppstart takket være en eksplisitt koding. Denne listen oppdateres deretter ved å konsultere en av de angitte serverne. Denne listen oppdateres sjelden, slik at eldre servere fortsetter å fungere.
Begrepet Fullt kvalifisert domenenavn (FQDN), eller fullt kvalifisert domenenavn et domenenavn skrevet i absolutte termer, inkludert alle områder til toppnivådomene (TLD), er punktumert med punktum, for eksempel fr.wikipedia.org
Standarden foreskriver at et element i et domenenavn (kalt label ) ikke kan overstige 63 tegn, og et FQDN ikke kan overstige 253 tegn.
I sin opprinnelige definisjon består domenenavn av tegn fra A til Å (uten bokstav: store bokstaver er ikke differensiert), tall og bindestrek.
De RFC 3490 definerer et format kalt Punycode som tillater koding av en større tegnsett.
Når en tjeneste genererer betydelig trafikk, kan den påkalle Round-Robin DNS- teknikken (i fransk turnett-DNS), en av lastbalanseringsteknikkene som består i å knytte flere IP-adresser til en FQDN . De forskjellige versjonene av Wikipedia, for eksempel fr.wikipedia.org , er knyttet til flere IP-adresser: 207.142.131.235, 207.142.131.236, 207.142.131.245, 207.142.131.246, 207.142.131.247 og 207.142.131.248. Rekkefølgen som adressene returneres i, endres fra en forespørsel til en annen. En sirkulær rotasjon mellom disse forskjellige adressene gjør det således mulig å fordele belastningen som genereres av denne betydelige trafikken mellom de forskjellige maskinene som har disse IP-adressene. Denne distribusjonen må imidlertid kvalifiseres fordi den bare finner sted når vertsnavnet er løst og deretter blir liggende i hurtigbufferen på de forskjellige resolverne (DNS-klienten).
Type ressurspost (RR for Resource Record) er kodet på 16 bits, IANA fører registeret over tildelte koder. De viktigste definerte postene er:
NS-posten oppretter en delegasjon fra et underdomener til en liste over servere.
I org- sonen oppretter følgende NS-poster Wikipedia- underdomenet og delegerer det til de angitte serverne.
Rekkefølgen til serverne er vilkårlig. Alle serverne som er oppført, må være autoritative for domenet.
wikipedia NS ns1.wikimedia.org. wikipedia NS ns2.wikimedia.org. wikipedia NS ns0.wikimedia.org.I motsetning til en A- eller AAAA-oppføring, indikerer en PTR-oppføring hvilket vertsnavn en IPv4- eller IPv6- adresse tilsvarer . Hvis spesifisert, må den inneholde omvendt registrering av en DNS A- eller AAAA-oppføring.
For eksempel (for en IPv4- adresse ) er denne PTR-posten:
232.174.198.91.in-addr.arpa. IN PTR text.esams.wikimedia.org.tilsvarer denne oppføringen A:
text.esams.wikimedia.org. IN A 91.198.174.232I tilfelle en IPv6- adresse lagres PTR-typeoppføringer i ip6.arpa-sonen. (anheng fra in-addr.arpa-sonen til IPv4- adresser ).
Regelen for å finne oppføringen som tilsvarer en IPv6- adresse er lik den for IPv4- adresser (reversering av adresse og søk i et dedikert underdomener i arpa-sonen.), Men er forskjellig i antall biter. Av adressen som ble brukt til å skrive navnet av domenet hvor man skal lete etter PTR-feltet: hvor for IPv4 adressesplitting gjøres av byte, for IPv6 er det en splitting av nibble som brukes.
For eksempel på IPv6-adressen:
2001:610:240:22:::c100:68bsamsvarer med domenenavnet:
b.8.6.0.0.0.1.c.0.0.0.0.0.0.0.0.2.2.0.0.0.4.2.0.0.1.6.0.1.0.0.2.ip6.arpa. PTR www.ipv6.ripe.net.En DNS MX-oppføring indikerer SMTP- serverne som skal kontaktes for å sende en e-post til en bruker i et gitt domene. For eksempel :
wikimedia.org. IN MX 10 mchenry.wikimedia.org. wikimedia.org. IN MX 50 lists.wikimedia.org.Vi ser at e-post sendt til en @ wikimedia.org-adresse blir sendt til mchenry.wikimedia.org-serveren. eller lists.wikimedia.org. Tallet foran serveren representerer prioriteten. Serveren med lavest numeriske prioritet brukes først. Så her er det mchenry.wikimedia.org. som skal brukes først, med verdien 10.
De angitte serverne må ha blitt konfigurert til å godta videresending av e-post for det angitte domenenavnet. En vanlig feil er å spesifisere servere som sekundære servere, noe som fører til at e-post blir avvist når primærserveren ikke kan nås. Det er ikke viktig å ha sekundære servere, senderserverne holder meldingene i en bestemt tid (vanligvis flere dager) til den primære serveren igjen er tilgjengelig.
MX-oppføringer generaliseres av SRV-oppføringer som gjør at det samme kan gjøres, men for alle tjenester, ikke bare SMTP (e-post). Fordelen med SRV-oppføringer fremfor MX-oppføringer er også at de gjør det mulig å velge en vilkårlig port for hver tjeneste, samt mer effektiv lastbalansering . Ulempen er at det fortsatt er få klientprogrammer som håndterer SRV-oppføringer. Siden 2009, med økningen i bruken av SIP over VoIP- tjenester , blir SRV-poster imidlertid vanligere i DNS-soner.
CNAME-posten brukes til å opprette et alias .
For eksempel :
fr.wikipedia.org. IN CNAME text.wikimedia.org. text.wikimedia.org. IN CNAME text.esams.wikimedia.org. text.esams.wikimedia.org. IN A 91.198.174.232Dette ekskluderer annen registrering ( RFC 1034 avsnitt 3.6.2, RFC 1912 avsnitt 2.4), dvs. at du ikke kan ha både CNAME og A-post for samme domenenavn.
Dette er for eksempel forbudt:
fr.wikipedia.org. IN CNAME text.wikimedia.org. fr.wikipedia.org. IN A 91.198.174.232Videre av ytelsesgrunner og for å unngå uendelige løkker av typen
fr.wikipedia.org. IN CNAME text.wikimedia.org. text.wikipedia.org. IN CNAME fr.wikimedia.org.spesifikasjonene ( RFC 1034 avsnitt 3.6.2, RFC 1912 avsnitt 2.4) anbefaler å ikke peke et CNAME til et annet CNAME eller til et DNAME (alias for et navn og alle dets undernavn).
Dermed vil det første eksemplet fortrinnsvis bli lagret som følger:
fr.wikipedia.org. IN CNAME text.esams.wikimedia.org. text.wikimedia.org. IN CNAME text.esams.wikimedia.org. text.esams.wikimedia.org. IN A 91.198.174.232For tiden ikke mye brukt (de brukes hovedsakelig av ENUM ), de beskriver en omskriving av en nøkkel (et domenenavn) i URI . I ENUM kan for eksempel NAPTR-poster brukes til å finne e-postadressen til en person, med kunnskap om telefonnummeret (som fungerer som en nøkkel til ENUM).
Parametrene er i orden:
NAPTR-posten er definert av RFC 3403.
Denne posten lar deg spesifisere hovednavneserveren (primær), e-postadressen til en teknisk kontakt (med @ erstattet av en periode) og utløpsparametere.
Den angir autoriteten (autoritetens start ) eller personen som er ansvarlig for sonen i DNS-hierarkiet. Dette er fødselsattesten for DNS-sonen.
Disse parametrene er i orden:
wikipedia.org. IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2010060311 43200 7200 1209600 3600Nyere versjoner av BIND ( navngitt ) aksepterer suffikset M, H, D eller W for å indikere et tidsintervall i henholdsvis minutter, timer, dager eller uker.
Hver post er tilknyttet en Time to live (TTL) som bestemmer hvor lenge den kan oppbevares i en cache- server . Denne tiden er vanligvis en dag (86400 s), men kan være høyere for informasjon som sjelden endres, for eksempel NS-poster. Det er også mulig å indikere at informasjon ikke skal caches ved å spesifisere en TTL på null.
Noen applikasjoner, for eksempel nettlesere , har også en DNS-cache, men som ikke nødvendigvis respekterer DNS TTL. Denne applikasjonsbufferen er vanligvis i størrelsesorden ett minutt, men Internet Explorer beholder for eksempel informasjon i opptil 30 minutter, uavhengig av konfigurert TTL.
Når et domene delegeres til en navneserver som tilhører dette underdomenet, er det nødvendig å oppgi IP-adressen til denne serveren for å unngå sirkulære henvisninger. Dette avviker fra det generelle prinsippet om at informasjonen til et domene ikke dupliseres andre steder i DNS.
For eksempel i følgende svar om NS-er for domenet wikimedia.org:
wikimedia.org. IN NS ns2.wikimedia.org. wikimedia.org. IN NS ns1.wikimedia.org. wikimedia.org. IN NS ns0.wikimedia.org.Det er også nødvendig å oppgi IP-adressene til serverne som er angitt i svaret ( limposter ), siden de er en del av det aktuelle domenet:
ns0.wikimedia.org. IN A 208.80.152.130 ns1.wikimedia.org. IN A 208.80.152.142 ns2.wikimedia.org. IN A 91.198.174.4En DNS-utvidelse kalt Dynamic DNS (DDNS) gjør det mulig for en klient å oppdatere en sone med informasjon om den ( RFC 2136). Dette er nyttig når klienter får en IP-adresse fra DHCP og vil at DNS skal gjenspeile maskinens faktiske navn.
Oppdateringene gjøres på den primære serveren til domenet, de sekundære serverne kopierer informasjon fra den primære serveren i en mekanisme som kalles soneoverføring . For å avgjøre om en soneoverføring skal finne sted, ser den sekundære serveren på sonens versjonsnummer og sammenligner den med den versjonen den har. Den primære serveren bestemmer hvor ofte versjonsnummeret blir sjekket. Når en endring er gjort, sender serverne varslingsmeldinger til de sekundære serverne for å øke hastigheten på prosessen.
Imidlertid kan informasjon som ikke lenger er oppdatert lagres i cache-servere. Det er da nødvendig å vente til utløpet av deres tid for å leve for at denne skjulte informasjonen forsvinner og derfor for at oppdateringen skal være fullt effektiv. Tiden som kreves kan minimeres ved å redusere TTL assosiert med domenenavnene som vil bli endret før en endringsoperasjon.
Når listen over navneservere endres, eller når en IP-adresse som er underlagt en ' Lim-post ' endres, må administratoren for toppnivådomenet utføre den tilsvarende oppdateringen.
For å unngå individuelle feilpunkter , unngår du å dele infrastrukturen mellom autoritative servere. En sekundær server vil fortrinnsvis bli avlokalisert og rutet annerledes enn den primære serveren.
Selv om dette er teknisk mulig, unngår vi å blande rollen som rekursiv DNS og den autoritative serveren på den samme serveren.
Likeledes vil en vert konfigureres med flere rekursive servere, slik at hvis den første ikke svarer på forespørselen, vil den neste bli brukt. Generelt avviser rekursive servere fra Internett-leverandører forespørsler fra IP-adresser som tilhører andre Internett-leverandører.
Det er åpne rekursive DNS-tjenester, det vil si at de godtar forespørsler fra alle klienter. Det er derfor mulig for en bruker å konfigurere disse i stedet for de som leveres av ISP. Dette gir imidlertid følgende problemer:
DNS-protokollen er designet med minimal bekymring for sikkerhet. Flere DNS-protokollsikkerhetsproblemer har siden blitt identifisert. Hovedfeilene i DNS ble beskrevet i RFC 3833 publisert iAugust 2004.
En av feilene som er fremmet er muligheten for å fange opp sendte pakker. DNS-servere kommuniserer ved hjelp av unike, usignerte pakker. Disse to spesifikasjonene gjør avlytting veldig enkelt. Avlytting kan foregå på forskjellige måter, særlig via et "mann i midten" -typeangrep, å lytte til de overførte dataene og sende et forfalsket svar (se avsnitt nedenfor).
Pakkene til DNS-serverne er svakt sikret, autentisert av et forespørselsnummer, det er mulig å produsere falske pakker. For eksempel, en bruker som ønsker å få tilgang til nettstedet http://mabanque.example.com, ber om en forespørsel til DNS-nettstedet. På dette punktet trenger en hacker bare å svare på brukerens forespørsel før DNS-serveren og brukeren havner på et phishing-nettsted .
Serverforræderi, eller datakorrupsjon, er teknisk sett det samme som pakkeoppfanging. Den eneste forskjellen kommer fra det faktum at brukeren frivillig sender sin forespørsel til serveren. Dette kan skje når for eksempel operatøren av DNS-serveren ønsker å markere en forretningspartner.
DNS-cache-forgiftning er en teknikk som brukes til å lure DNS-servere til å tro at de mottar en gyldig forespørsel mens den er uredelig.
Et denial of service-angrep (eller denial of service-angrep eller DoS-angrep) er et angrep på en datamaskinserver som resulterer i at serveren ikke kan svare på forespørsler fra sine klienter.
For å motvirke disse sårbarhetene (datakorrupsjon, DNS-cache-forgiftning osv.), Er DNSSEC- protokollen ( RFC 4033, RFC 4034, RFC 4035) utviklet. Den bruker prinsippene for asymmetrisk kryptografi og digital signatur for å sikre dataintegritet, samt bevis på manglende eksistens hvis den forespurte posten ikke eksisterer. DNS-rotsonen ble pålogget15. juli 2010, og distribusjonen av DNSSEC på toppdomener (TLD: Top Level Domain) fortsetter, en liste over dekkede domener er tilgjengelig.
Siden 2015 har IETF jobbet med sikkerheten til DNS-kommunikasjonskanalen (der DNSSEC beskytter data). Dette resulterte i publisering av flere RFC-er som tillater bruk av TLS for å kryptere kommunikasjon mellom DNS-klienter og resolvere. Disse er hovedsakelig: DNS over TLS ( RFC 7858, bruker port 853) og DNS over HTTPS ( RFC 8484, DNS-forespørsel innkapslet i en HTTP- forespørsel , og behandlet av en webserver).
I 2018 er det ingen muligheter for å kryptere - via TLS - kommunikasjon mellom en resolver og en autoritativ server.
I juli 2008, noen dager etter publiseringen av United States Computer Emergency Readiness Teams rapport om DNS-serverens sikkerhetsfeil som forgiftet cachen deres, ble flere store DNS-servere angrepet. En av de viktigste var den mot AT & T- serverne . Angrepet som forgiftet hurtigbufferen til AT & Ts DNS-servere, tillot hackeren å omdirigere alle Google-forespørsler til et phishing-nettsted .
DNS bruker vanligvis UDP og port 53. Maksimal pakkestørrelse som brukes er 512 byte. Hvis et svar overstiger denne størrelsen, forutsetter standarden at forespørselen må sendes tilbake til TCP-port 53. Denne saken er imidlertid sjelden og unngås, og brannmurer blokkerer ofte TCP-port 53.
EDNS 0 ( RFC 2671) -utvidelse tillater bruk av større pakkestørrelse. Støtten anbefales for både IPv6 og DNSSEC.
Standarden gir at det er en klasse assosiert med spørsmål. IN (Internett), CH (Chaos) og HS ( Hesiod ) klassene er definert, bare IN klassen blir faktisk brukt i praksis. Den kaos klassen brukes av BIND å avsløre versjonsnummeret.
For å kontrollere sammenhengen mellom et navn og en IP-adresse, er flere kommandoer tilgjengelige, avhengig av operativsystemene som brukes.
For eksempel på Windows er nslookup- kommandoen tilgjengelig via ledeteksten:
> nslookup www.google.fr Serveur : Livebox-6370 Address: 192.168.1.1 Réponse ne faisant pas autorité : Nom : www.l.google.com Addresses: 209.85.229.104 209.85.229.106 209.85.229.103 209.85.229.147 209.85.229.105 209.85.229.99 Aliases: www.google.fr www.google.comeller grave på systemer som er kompatible med UNIX :
> dig www.google.com aaaa ; <<>> DiG 9.7.0-P1 <<>> www.google.com aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47055 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN AAAA ;; ANSWER SECTION: www.google.com. 422901 IN CNAME www.l.google.com. www.l.google.com. 77 IN AAAA 2a00:1450:8004::67 www.l.google.com. 77 IN AAAA 2a00:1450:8004::68 www.l.google.com. 77 IN AAAA 2a00:1450:8004::69 www.l.google.com. 77 IN AAAA 2a00:1450:8004::6a www.l.google.com. 77 IN AAAA 2a00:1450:8004::93 www.l.google.com. 77 IN AAAA 2a00:1450:8004::63 ;; AUTHORITY SECTION: google.com. 155633 IN NS ns2.google.com. google.com. 155633 IN NS ns1.google.com. google.com. 155633 IN NS ns3.google.com. google.com. 155633 IN NS ns4.google.com. ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Sun May 23 16:23:49 2010 ;; MSG SIZE rcvd: 292