Vraag Waarom werkt DNS zoals het werkt?


Dit is een Canonical Question over DNS (Domain Name Service).

Als mijn kennis van het DNS-systeem correct is, bevat het .com-register een tabel die domeinen (www.example.com) toewijst aan DNS-servers.

  1. Wat is het voordeel? Waarom niet rechtstreeks toewijzen aan een IP-adres?

  2. Als de enige record die moet worden gewijzigd wanneer ik een DNS-server zodanig configureer dat deze naar een ander IP-adres verwijst, zich op de DNS-server bevindt, waarom is het proces dan niet onmiddellijk?

  3. Als de enige reden voor de vertraging DNS-caches zijn, is het dan mogelijk om ze te omzeilen, zodat ik kan zien wat er in realtime gebeurt?


40
2018-02-01 17:24


oorsprong


Aan alle mensen die proberen deze vraag te migreren / sluiten: laat het hier alstublieft achter. Het heeft hier een huis waar het geliefd en teder verzorgd kan worden. En we kunnen alle vragen "Hoe werkt DNS-werk" hier stellen als een canoniek antwoord, want deze is buitengewoon goed beantwoord. - Mark Henderson♦
You can not able full understand DNS unless you are name Paul Mockapetris, Paul Vixie or Cricket Liu.  twitter.com/DEVOPS_BORAT/status/249006925767909376 - Anthony Hatzopoulos


antwoorden:


Eigenlijk is het gecompliceerder dan dat - in plaats van één "centraal register (dat) een tabel bevat die domeinen (www.mysite.com) toewijst aan DNS-servers", zijn er verschillende lagen van hiërarchie

Er is een centraal register (de root-servers) dat slechts een kleine set vermeldingen bevat: de NS-records (naamserver) voor alle domeinen op het hoogste niveau - .com, .net, .org, .uk, .us, .au, enzovoorts.

Die servers bevatten alleen NS-records voor het volgende niveau lager. Om een ​​voorbeeld te kiezen, de nameservers voor de .uk domein heeft gewoon vermeldingen voor .co.uk, .ac.uken de andere second-level zones die in gebruik zijn in het VK.

Die servers bevatten alleen NS-records voor het volgende niveau omlaag - om het voorbeeld voort te zetten, vertellen ze je waar je de NS-records voor kunt vinden google.co.uk. Het is op die servers dat je uiteindelijk een afbeelding vindt tussen een hostnaam zoals www.google.co.uk en een IP-adres.

Als extra rimpel zal elke laag ook 'lijm'-records bevatten. Elke NS-record koppelt een domein aan een hostnaam - bijvoorbeeld de NS-records voor .uk lijst nsa.nic.uk als een van de servers. Om naar het volgende niveau te komen, moeten we de NS-records vinden voor nic.uk zijn, en ze blijken te bevatten nsa.nic.uk ook. Dus nu moeten we de IP van kennen nsa.nic.uk, maar om dat te weten te komen, moeten we een vraag stellen nsa.nic.uk, maar we kunnen die vraag niet stellen voordat we de IP kennen nsa.nic.uk...

Om dit dilemma op te lossen, de servers voor .uk voeg het A-record toe voor nsa.nic.uk in de ADDITIONAL SECTION van de reactie (antwoord korter gemaakt voor beknoptheid):

jamezpolley@li101-70:~$dig nic.uk ns

; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14

;; QUESTION SECTION:
;nic.uk.                IN  NS

;; ANSWER SECTION:
nic.uk.         172800  IN  NS  nsb.nic.uk.
nic.uk.         172800  IN  NS  nsa.nic.uk.

;; ADDITIONAL SECTION:
nsa.nic.uk.     172800  IN  A   156.154.100.3
nsb.nic.uk.     172800  IN  A   156.154.101.3

Zonder deze extra lijmrecords zouden we de nameservers nooit kunnen vinden nic.uk. en dus kunnen we nooit domeinen opzoeken die daar worden gehost.

Om terug te gaan naar uw vragen ...

a) Wat is het voordeel? Waarom niet rechtstreeks toewijzen aan een IP-adres?

Om te beginnen kunnen bewerkingen voor elke individuele zone worden gedistribueerd. Als u de vermelding wilt bijwerken voor www.mydomain.co.uk, je hoeft alleen de informatie op je te bewerken mydomain.co.ukde naamserver. Het is niet nodig om de centrale op de hoogte te stellen .co.uk servers of de .uk servers of de rootnaamservers. Als er slechts één centraal register was dat alle niveaus helemaal naar beneden in de hiërarchie bracht die over elke wijziging van een DNS-invoer helemaal in de keten moesten worden aangemeld, zou dit absoluut overspoeld worden met verkeer.

Voor 1982 was dit eigenlijk de naamomzetting. Eén centraal register werd op de hoogte gebracht van alle updates en ze verspreidden een bestand met de naam hosts.txt die de hostnaam en het IP-adres van elke computer op internet bevatte. Om de paar weken werd een nieuwe versie van dit bestand gepubliceerd en elke computer op het internet moest een nieuw exemplaar downloaden. Ruim voor 1982 begon dit problematisch te worden, en daarom werd DNS uitgevonden om een ​​meer gedistribueerd systeem te bieden.

Voor een ander ding, zou dit een Single Point of Failure zijn - als het centrale register zou uitvallen, zou het hele internet offline zijn. Het hebben van een gedistribueerd systeem betekent dat storingen alleen van invloed zijn op kleine delen van het internet, niet het hele ding.

(Om extra redundantie te bieden, zijn er eigenlijk 13 afzonderlijke clusters van servers die de rootzone bedienen.) Alle wijzigingen aan de domeinarchieven op het hoogste niveau moeten naar alle 13 worden gepusht; stel je voor dat je alle 13 updates voor elke wijziging moet coördineren naar elke hostnaam waar ook ter wereld ...)

b) Als de enige record die moet worden gewijzigd tijdens het configureren van een DNS   server om naar een ander IP-adres te verwijzen bevindt zich op de DNS   server, waarom is het proces niet direct?

Omdat DNS veel caching gebruikt om zowel de snelheid te versnellen als de belasting van de NS te verminderen. Zonder caching, elke keer dat u bezocht google.co.uk je computer zou naar het netwerk moeten gaan om de servers op te zoeken .uk, dan .co.uk, dan .google.co.uk, dan www.google.co.uk. Die antwoorden veranderen niet echt veel, dus elke keer dat je ze opzoekt, is verspilling van tijd en netwerkverkeer. In plaats daarvan, wanneer de NS records naar uw computer retourneert, zal deze een TTL-waarde bevatten die uw computer vertelt om de resultaten voor een aantal seconden in de cache op te slaan.

Bijvoorbeeld de NS-records voor .uk heb een TTL van 172800 seconden - 2 dagen. Google is nog conservatiever - de NS-records voor google.co.uk heb een TTL van 4 dagen. Diensten die afhankelijk zijn van het snel kunnen updaten, kunnen een veel lagere TTL kiezen - bijvoorbeeld telegraph.co.uk heeft een TTL van slechts 600 seconden op hun NS-records.

Als u updates in uw zone bijna onmiddellijk wilt hebben, kunt u ervoor kiezen om uw TTL zo ver naar beneden te verlagen als u wilt. Hoe lager uw set, hoe meer verkeer uw servers zullen zien, omdat clients hun gegevens vaker vernieuwen. Telkens wanneer een klant contact moet opnemen met uw servers om een ​​zoekopdracht uit te voeren, zal dit enige vertraging veroorzaken omdat het langzamer is dan het antwoord op te zoeken in hun lokale cache, dus u zult ook de afweging tussen snelle updates en een snelle service overwegen.

c) Als de enige reden voor de vertraging DNS-caches zijn, is het mogelijk om dit te doen   omzeilen, zodat ik kan zien wat er in realtime gebeurt?

Ja, dit is eenvoudig als u handmatig test met dig of soortgelijke tools - vertel het gewoon aan welke server contact moet worden gelegd.

Hier is een voorbeeld van een reactie in de cache:

jamezpolley@host:~$dig telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    319 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    319 IN  NS  eur3.akam.net.
telegraph.co.uk.    319 IN  NS  use2.akam.net.
telegraph.co.uk.    319 IN  NS  usw2.akam.net.
telegraph.co.uk.    319 IN  NS  use4.akam.net.
telegraph.co.uk.    319 IN  NS  use1.akam.net.
telegraph.co.uk.    319 IN  NS  usc4.akam.net.
telegraph.co.uk.    319 IN  NS  ns1-224.akam.net.

;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb  2 05:46:02 2012
;; MSG SIZE  rcvd: 198

De sectie vlaggen bevat hier niet de aa vlag, dus we kunnen zien dat dit resultaat uit een cache kwam in plaats van rechtstreeks uit een gezaghebbende bron. In feite kunnen we zien dat het vandaan kwam 97.107.133.4, wat toevallig een van Linode's lokale DNS-resolvers is. Het feit dat het antwoord heel dicht bij mij uit een cache werd geserveerd, betekent dat het 0 ms voor mij was om een ​​antwoord te krijgen; maar zoals we zo dadelijk zullen zien, is de prijs die ik betaal voor die snelheid dat het antwoord bijna 5 minuten achterhaald is.

Om de resolver van Linode te omzeilen en direct naar de bron te gaan, kies je gewoon een van die NS's en vertel je graven om direct contact met hem op te nemen:

jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS

; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;telegraph.co.uk.       IN  NS

;; ANSWER SECTION:
telegraph.co.uk.    600 IN  NS  use2.akam.net.
telegraph.co.uk.    600 IN  NS  eur3.akam.net.
telegraph.co.uk.    600 IN  NS  use1.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-63.akam.net.
telegraph.co.uk.    600 IN  NS  usc4.akam.net.
telegraph.co.uk.    600 IN  NS  ns1-224.akam.net.
telegraph.co.uk.    600 IN  NS  usw2.akam.net.
telegraph.co.uk.    600 IN  NS  use4.akam.net.

;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb  2 05:48:47 2012
;; MSG SIZE  rcvd: 198

U kunt zien dat deze keer de resultaten direct vanuit de bron werden geserveerd - noteer de aa vlag, wat aangeeft dat de resultaten afkomstig zijn van een gezaghebbende bron. In mijn eerdere voorbeeld waren de resultaten afkomstig van mijn lokale cache, dus ze missen de aa vlag. Ik zie dat de gezaghebbende bron voor dit domein een TTL van 600 seconden instelt. De resultaten die ik eerder kreeg van een lokale cache hadden een TTL van slechts 319 seconden, wat me vertelt dat ze al (600-319) seconden - bijna 5 minuten - in de cache zaten voordat ik ze zag.

Hoewel de TTL hier slechts 600 seconden is, zullen sommige ISP's proberen hun verkeer nog verder terug te dringen door hun DNS-resolvers te dwingen de resultaten langer te cachen - in sommige gevallen 24 uur of langer. Het is traditioneel (op een wij-niet-weten-als-dit-echt-nodig-maar-laten-zijn-veilig soort manier) om te veronderstellen dat elke DNS-verandering die je maakt niet overal zichtbaar zal zijn op de internet voor 24-48 uur.


87
2018-02-01 18:52



+1 Dat is een geweldige verklaring. Zal dit zeker een bladwijzer geven! - Trollhorn
Het echte antwoord op de vraag of een DNS-reactie al dan niet uit een cache komt, staat in het gedeelte 'flags' van het antwoord. Er is geen technische reden waarom men geen DDL van bijvoorbeeld 319 seconden kon instellen. Zoek in plaats daarvan naar de aa (gezaghebbend antwoord) flag in het antwoord. Als aa is aanwezig, het antwoord kwam rechtstreeks van een gezaghebbende naamserver. (Als het ontbreekt, is het antwoord mei nog steeds vers; sommige recursieve naamservers wissen de aa vlag voordat het antwoord aan de client-resolver wordt doorgegeven.) - α CVn
Ook, voor het uitzoeken van dingen, heb ik de neiging om graven te gebruiken +norec en +trace opties nogal een beetje. "norec" zegt om geen recursie in naamomzetting uit te voeren (het wissen van de rd of recursion desired bit in de query; merk op dat zelfs als rd, DNS-servers bieden mogelijk geen recursie voor u aan, aangegeven door het ontbreken van ra recursie beschikbaar in het antwoord). "traceren" zegt start bij de root-naamservers zoals verkregen uit de resolver van uw systeem en voer de recursie handmatig uit door de tussenresultaten af ​​te drukken. - α CVn
Houd er rekening mee dat sommige internetproviders DNS-records veel langer in cache opslaan dan de TTL zegt dat dit zou moeten, dus zelfs met zeer korte TTL's kunt u niet garanderen dat bezoekers van alle sites de juiste IP krijgen voor een dag of twee nadat u bent verhuisd een site. - Dan Neely
@JamesPolley er is een (kleine) fout in je uitleg met je gebruik van de .uk servers. Momenteel zijn de door Nominet beheerde tweedegelddomeinen op dezelfde servers als uk., dus een zoekopdracht voor example.co.uk naar de uk servers zullen onmiddellijk een delegatie ontvangen zonder eerst een delegatie naar de co.uk servers. - Alnitak


a) Het aantal IP -> hostnaamtoewijzingen ter wereld is ERG groot. Dit systeem verdeelt de verantwoordelijkheid voor het hosten van alle subdomein- en MX-records en elk ander DNS-record aan de eigenaar van de domeinnaam. Dit was zo ongeveer het punt van de domeinnaam. .com wordt gehouden door één register waar als .uk kan door een ander worden vastgehouden. hetzelfde example.com en otherexample.com kan afzonderlijk worden gehost zodat de bronnen kunnen worden gedistribueerd.

b) Het is opgeslagen in de cache, waardoor het aantal hits op uw DNS-host tot een klein deel vermindert van wat anders het geval zou zijn. Neemt standaard 2 dagen live op in de cache voordat deze wordt weggegooid. Dit kan worden gewijzigd door de TTL (time to live) van het record te wijzigen.

c) U kunt records die in de cache worden opgeslagen effectief stoppen door een echt korte TTL in te stellen. Dit is NIET aanbevelen, tenzij je het gebruikt voor dynamische DNS. Met caching worden de hits op de DNS-server vaak onderbroken. Om een ​​geraden nummer uit de lucht te halen, hebben we het over het afwijzen van 95% van de verzoeken.


9
2018-02-01 17:33



Wat betreft 'C', wees voorzichtig. Stel die TTL laag genoeg in en uw DNS-server kan worden gehamerd. Geen enorm probleem als iemand anders dan jij DNS behandelt. - Publiccert
Dus als het niet voor subdomeinen was, zou er niet veel voordeel zijn - sabof
Perhapse, maar nog meer yourdomain.com is een subdomein van .com. Als het maar één groot "hosts-bestand" was (zoals het was voordat DNS en elf nog in middle earth liepen) dan is dat wel zo. Je zou gewoon één groot bestand hebben en iedereen zou dat in de cache opslaan. - couling
De DNS-naamruimte was plat, zonder delegaties, voor een lange tijd; en het was geïmplementeerd als een enkele lijst, op één plek bewaard. Dat werd onwerkbaar en werd in 1982 vervangen door DNS ... - James Polley
@mfinni, Nou, het is "domeinnaamsysteem", geen "gedistribueerd naamsysteem" of iets dergelijks. Natuurlijk is het ontworpen om te worden verspreid, maar er is niets dat je absoluut zegt hebben om het op die manier uit te voeren. Voor sommige kleine kantoornetwerken zonder wereldwijde connectiviteit, alles in een rootzone (of een enkele TLD zoals local) maakt waarschijnlijk een beperkte hoeveelheid zin. - α CVn


Als u een * nix-systeem gebruikt, downloadt u een kopie van de djbdns van Dan Bernstein van http://cr.yp.to/djbdns.html en voer zijn dnstrace-programma uit om te zien hoe het recursieve query-systeem werkt. Het is zeer informatief.


3
2018-02-01 17:37



Kan ik het effect van een configuratiewijziging direct zien? - sabof
dnstrace (meestal via dnstracesort) geeft intense hoeveelheden details over de DNS-configuratie voor elk domein en elke query die u maakt. Als de server een wijziging heeft aangebracht, laten ze de wijziging zien en hoe deze is doorgevoerd. Ze zijn ook uitstekend geschikt voor het opsporen van propagatiefouten. - mikebabcock


a) Het aantal mogelijke domeinnamen is veel te groot om met één server te verwerken. En er is niet alleen .com; er zijn .net, .org, .se, .info en een aantal andere. Voeg daar nog aan toe dat u de verantwoordelijkheid voor een subdomein kunt delegeren (wat in feite is wat com doet). DNS is minder gecentraliseerd waardoor het allemaal eenvoudiger te beheren is.

b) Machines langs de weg van de gebruiker naar u hebben DNS-caches om het aantal benodigde verzoeken te minimaliseren. Het voorkomt bijvoorbeeld het spammen van het netwerk met verzoeken om het adres "serverfault.com" telkens wanneer u een pagina van SF krijgt. Die servers kunnen zelfs cache "domein bestaat niet" resultaten, en dat is waarom het even kan duren voordat zelfs een geheel nieuw domein verschijnt.

c) Hoewel u uw cache kunt uitschakelen, zijn er vaak andere DNS-servers tussen uw machine en de DNS-server van uwdomein.com. De DNS-server van uw internetprovider zal bijvoorbeeld proberen zoveel mogelijk caches in te voeren. De enige records die relatief snel worden bijgewerkt op het net zijn degenen met een korte TTL (die in feite zegt: "ik ben maar een paar seconden geldig, vraag me daarna opnieuw om actuele informatie"). De reden dat TTL's zo hoog zijn, is dat de server die verantwoordelijk is voor het domein, sommige van het werk naar andere servers kan overbrengen. Als u het hele netwerk had om contact te maken met uw een of twee DNS-servers met rinked-dink voor elke hit op uw website, zouden ze vrijwel onbruikbaar zijn op het moment dat iemand uw site zag op /., Digg, etc.


3
2018-02-01 17:41



Je (c) heeft het fout. Het is een wijdverbreid misverstand over DNS. Er is geen keten van servers - lokale machine om te routeren naar ISP om ... - elk contact met de volgende in de rij.  Verzoeken gaan van een DNS-client (bibliotheek), via een single het oplossen van proxy DNS-server, naar nul of meer inhoud DNS-servers. Behoudens het bestaan ​​van doorsturende proxy-DNS-servers, dat is het. - JdeBP
@JdeBP: het is een "wijdverbreid misverstand" omdat ik, voor zover ik het in de echte wereld heb gezien, het is grotendeels waar. Als u uw adres via DHCP ontvangt, zoals zowat iedereen doet, heeft u vrijwel zeker het adres gekregen van een DNS-server die u hoort te gebruiken. Wat in thuisnetwerken bijna altijd de router is - die in feite doorstuurt naar de DNS van je ISP. En in kleine bedrijfsnetwerken is dit meestal de domeincontroller - die meestal weer wordt doorgestuurd naar de DNS van de ISP. Het is meestal op dat punt dat de iteratieve dingen het overnemen. - cHao
Je moet meer van de echte wereld zien als je denkt dat 'grotendeels waar' helemaal past. Ik noemde eigenlijk het doorsturen van proxies als het enige extra item. U overschat echter hun gebruik in zakelijke netwerken; en inderdaad overschatten hoeveel hun domeincontrollers van de standaard veranderen, wat is (nadat een van de root-zones is verwijderd) a oplossen DNS-server met behulp van grondtips. Uw basisfout in (c) blijft niet gecorrigeerd. Het uitschakelen van een cache onthult niet op magische wijze een cache "erachter". DNS werkt gewoon niet zo. Als u het niet verkeerd begrijpt, dan stelt u het verkeerd voor. - JdeBP
Het is een feit: als u de cache op uw lokale computer uitschakelt, ziet u nog steeds de resultaten die worden opgeslagen in de cache van de DNS-server van uw lokale netwerk. En als je dat uitschakelt, heb je waarschijnlijk nog steeds de cache van je ISP om je zorgen over te maken. Of je dat nu als een gewoon geval accepteert of niet, het is het geval dat ik bijna elke keer heb gezien - wat het algemeen genoeg maakt om het vermelden waard te zijn. - cHao
@cHao de meeste CPE DNS-servers alleen "doorsturen" en cachen niet. - Alnitak