Vraag Hoe lang duurt het voordat DNS-records worden doorgegeven?


Dit is een Canonical Question over DNS-propagatie

Hoe lang duurt het voordat een van de verschillende soorten records zich heeft uitgebreid?
Sommigen propageren sneller dan anderen?
Waarom duurt het even voordat DNS-records zijn doorgevoerd en hoe werkt het?


64
2018-03-23 13:32


oorsprong


Opmerking: Historisch gezien was er een opvallend en significant verschil in de tijd die nodig is om verschillende typen records bij te werken (afhankelijk van wie ze heeft bewaard en dergelijke). Dit is vandaag niet meer het geval. - Chris S
Wanneer ppl het woord "propagate" voor DNS gebruikt, laat het duidelijk zien dat ze niet weten wat DNS is en hoe het werkt. Laten we hopen dat de documentatie snel genoeg "verspreidt" (vingers kruisen). - poige
@tonygil Zie de opmerking van Poige. Er is niet zoiets als dns-propagatie. Ook hebben ISP's geen controle over de root-servers. Als de DNS-servers van die internetproviders langer cachen dan de TTL van het record, dan schenden ze RFC. U lijkt verschillende misverstanden te hebben met de manier waarop DNS werkt; maar RFC-overtredingen breken meestal de manier waarop het zou moeten werken. Dit heeft niets te maken met de VS of Europa. - Chris S
@tonygil: De "cyberpolice" om ze bij te werken, zijn alle sysadmins, netwerkbeheerders, enz., die sociale druk uitoefenen op slechte acteurs. Internet werkt omdat we het er allemaal over eens zijn dat het zou moeten. De beste belangen van onze gebruikers, netwerken, enz. Bevinden zich in het manifeste "beste belang" van het internet. re: "gebruikers zijn geen technogurus" - dit is een site voor professionele systeembeheerders en geen eindgebruikers. Eerlijk gezegd verwacht ik dat sysadmins een soort van "technoguru" zijn (om je terminologie te gebruiken). systeembeheerders zijn, van beroep, verondersteld te geven hoe dit spul werkt. - Evan Anderson
@EvanAnderson Ik ben het er volledig mee eens dat druk verandering bewerkstelligt. aan de andere kant is de realiteit dat er luie of incompetente sysadmins zijn in hordes. en hoe verder je van de vs en europa vertrekt, hoe frequenter ze worden. je verwachtingen zijn goed, 4 VS maar ze zijn niet haalbaar in de meeste delen van de echte wereld, waar onvoorbereide sysadmins de regel zijn. dus, terwijl je verwacht dat alles in orde komt, moet je de echte wereld aanpakken, waar ze NIET zijn. hoe dan ook, merkte ik op, jij hebt de jouwe gemaakt. laten we het eens zijn om het oneens te zijn. - tony gil


antwoorden:


"DNS-propagatie" is op zichzelf geen echt fenomeen. Het is eerder het manifeste effect van de cachefunctionaliteit die is opgegeven in het DNS-protocol. Zeggen dat veranderingen "propageren" tussen DNS-servers is een handige onwaarheid die, misschien wel beter uit te leggen is aan niet-technische gebruikers dan alle details van het DNS-protocol te beschrijven. Het is echter niet echt hoe het protocol werkt.

Recursieve DNS-servers vragen namens klanten. Recursieve DNS-servers, meestal beheerd door ISP's of IT-afdelingen, worden door clientcomputers gebruikt om namen van internetbronnen op te lossen. Recursieve DNS-servers cachen de resultaten van query's die ze maken om de efficiëntie te verbeteren. Query's voor reeds in de cache opgeslagen informatie kunnen worden beantwoord zonder aanvullende vragen te stellen. De duur, in seconden, dat een resultaat in de cache wordt opgeslagen, is vermeend te zijn gebaseerd op een configureerbare waarde die de Time To Live (TTL) wordt genoemd. Deze waarde wordt opgegeven door de gezaghebbende DNS-server voor de opgevraagde record.

Er is geen antwoord op alle vragen die worden gesteld, omdat DNS een gedistribueerd protocol is. Het gedrag van DNS is afhankelijk van de configuratie van de gezaghebbende DNS-server voor een gegeven record, de configuratie van recursieve DNS-servers die query's maken namens clientcomputers en DNS-cachingfunctionaliteit die is ingebouwd in de besturingssystemen van de clientcomputers.

Het is een goede gewoonte om een ​​TTL-waarde op te geven die kort genoeg is om geschikt te zijn voor dagelijkse wijzigingen in DNS-records, maar lang genoeg om een ​​"win" in caching te creëren (dwz niet zo kort dat de cache te snel verouderd wordt om zorgen voor een verbetering van de efficiëntie). Het gebruik van een uitgebalanceerde strategie met TTL-waarden resulteert in een "winst" voor iedereen. Het vermindert zowel het laad- als bandbreedtegebruik voor de gezaghebbende DNS-servers voor een bepaald domein, de root-servers en de TLD-servers. Het vermindert het stroomopwaartse bandbreedtegebruik voor de operator van de recursieve DNS-server. Het resulteert in snellere queryantwoorden voor clientcomputers.

Naarmate de TTL van een DNS-record lager wordt ingesteld, neemt het bandbreedtegebruik op de gezaghebbende DNS-servers toe, omdat recursieve DNS-servers het resultaat niet langdurig in het cachegeheugen kunnen opslaan. Omdat de TTL van een record hoger is, lijken wijzigingen in records niet snel effect te hebben, omdat clientcomputers de resultaten in de cache blijven ontvangen die zijn opgeslagen op hun recursieve DNS-servers. Het instellen van de optimale TTL komt neer op een evenwichtsoefening tussen gebruik en de mogelijkheid om snel van record te veranderen en deze wijzigingen weerspiegeld te zien in clients.

Het is vermeldenswaard dat sommige internetaanbieders beledigend zijn en de TTL-waarden negeren die zijn opgegeven door de gezaghebbende DNS-servers (in de plaats van hun eigen administratieve overschrijving, wat een overtreding is van RFC). Er is niets aan te doen, vanuit een technisch perspectief. Als de operators van misbruikende DNS-servers kunnen worden gelokaliseerd, kunnen klachten bij hun systeembeheerders resulteren in de implementatie van best practices (wat betwistbaar is wat logisch is voor elke netwerkexpert die bekend is met DNS). Dit specifieke type misbruik is geen technisch probleem.

Als iedereen "speelt volgens de regels" wijzigingen in DNS-records kan "effect hebben" heel snel. In het geval van het wijzigen van het IP-adres dat is toegewezen aan een "A" -record, bijvoorbeeld, zou een exponentiële backoff van de TTL-waarde worden uitgevoerd, in de aanloop naar het tijdstip waarop de wijziging zal plaatsvinden. De TTL kan bijvoorbeeld starten op 1 dag en worden verlaagd naar 12 uur voor een periode van 24 uur, vervolgens 6 uur voor een periode van 12 uur, 3 uur voor een periode van 6 uur, enz., Tot een geschikt klein interval. Nadat de TTL is teruggezet, kan de record worden gewijzigd en kan de TTL worden teruggebracht naar de gewenste waarde voor dagelijkse bewerkingen. (Het is niet nodig om een ​​exponentiële back-up te gebruiken, maar deze strategie minimaliseert de tijd dat de record een lage TTL heeft en verlaagt de belasting op de gezaghebbende DNS-server.)

Na het maken van een DNS-record moeten wijzigingslogboeken worden gecontroleerd op toegangspogingen die worden gedaan als gevolg van het oude DNS-record. In het voorbeeld van het wijzigen van een "A" -record om te verwijzen naar een nieuw IP-adres, moet een server aanwezig blijven op het oude IP-adres om toegangspogingen af ​​te handelen die voortvloeien uit clientcomputers die nog steeds het oude "A" -record gebruiken. Zodra toegangspogingen op basis van het oude record een acceptabel laag niveau hebben bereikt, kan het oude IP-adres worden verwijderd. Als de verzoeken met betrekking tot een oude record niet snel afnemen, is het mogelijk dat (zoals hierboven beschreven) een recursieve DNS-server de gezaghebbende TTL negeert. Het kennen van het bron-IP-adres van een toegangspoging biedt echter geen directe informatie over de recursieve DNS-server die verantwoordelijk is voor het leveren van een oud record. Als de IP-adressen van foutieve toegangspogingen allemaal verband houden met een enkele ISP, kan het mogelijk zijn de schadelijke DNS-server te lokaliseren en contact op te nemen met de netwerkaanbieder.

Persoonlijk heb ik veranderingen na enkele dagen en in sommige gevallen met een bepaalde door de hersenen beschadigde ISP onmiddellijk "effect" zien krijgen. Als u een backoff van uw TTL doet en er rekening mee houdt hoe het proces werkt, zullen uw wijzigingen voor succes toenemen, maar u kunt er nooit zeker van zijn wat een goedbedoelende idioot doet met zijn recursieve DNS-servers.


66
2018-03-23 13:47



Dit is geen antwoord over "OpenDNS" - het is een antwoord over DNS. Elke recursieve DNS-provider zou alle interfaces kunnen implementeren die ze cachebewerkingen wilden toestaan, enz. We hebben het over DNS, niet over leveranciers-API's. In zoverre als je bewerkingen: ik sta voor de uitdrukking "beschadigd door de hersenen" als een uitdrukking die al lang wordt gebruikt in de hackercultuur, en ik gebruik het in die context (zie het Jargon-bestand, Steven Levy's "Hackers", enz.) . Wat betreft 'idioot', denk ik dat het redelijk vaststaat dat dit, buiten de wettelijke codes, een informele term is voor acties die van een incompetente aard zijn. Ik blijf erbij. - Evan Anderson
@tonygil - OpenDNS is geen DNS. Het is gewoon een dienst die iemand biedt. Wat als FooDNS morgen wordt geopend en een spannende nieuwe cache-opruiming-API heeft? Moet ik dat ook in mijn antwoord opnemen? Waar stopt het? Dit degenereert in waanzin. re: burgerrechten - ik ben geen werkgever of overheidsinstantie die burgerrechten ontzegt aan een lid van een beschermde klasse. Natuurlijk, ga je gang en kijk of je iemand kunt vinden die me wil vervolgen. Ze kunnen mij bereiken via e-mail bij P.O. Box 852, Troy, OH. (866) 569-9799, x801 doorsturen naar mijn mobiele telefoon 24x7. (Dat is goed speurwerk daar kijken naar mijn profiel, tussen haakjes.) - Evan Anderson
Zie je, je zei dat groepsdruk verandering brengt. dat was wat ik deed. op de hoogte gebracht dat ik het niet eens ben met het gebruik van "idioot" en "hersenbeschadiging" omdat ze aanstootgevend en denigrerend zijn. het feit dat iemand het overvloedig gebruikt (dat wil zeggen hackers) maakt het niet goed. de kkk gebruikte het n-woord overvloedig. Heb respect voor diegenen van ons die zorgen voor mentaal gehandicapten. ik begrijp dat je de termen metaforisch opneemt in je kleurrijke stijl, maar geloof me: ze zijn aanstootgevend en onnodig. - tony gil
Over TTL honoreren: de TTL is de maximale waarde om dingen in de cache te houden, een caching-resolver is vrij om de gegevens ervoor te dumpen. Dus ze kunnen het verlagen als ze willen. Het is echter waar dat ze het niet moeten verhogen, dat is een overtreding van het protocol. Maar voor de mensen die 1 seconde in de TTL stoppen, verdedigen sommige caches zichzelf door dat niet te eren en in plaats daarvan in 5 minuten vast te klemmen. - Patrick Mevzek
Recursieve DNS-servers, meestal beheerd door ISP's of IT-afdelingen, tegenwoordig zijn het enorme fleets (anycast cloud) van open recursieve nameservers zoals 1.1.1.1 of 8.8.8.8 of 9.9.9.9 of 80.80.80.80. Het is belangrijk om te weten dat ze anycasted zijn: het antwoord kan veranderen op basis van het bron-IP, omdat het mogelijk een geheel andere fysieke instantie raakt EN de cache die ze hebben mogelijk globaal is voor alle instanties, of niet. - Patrick Mevzek