Inwiefern verändert es die Internetgeschwindigkeit, wenn man die DNS-Adresse ändert?
Z.B. die von Cloudflare oder Google Public DNS
6 Antworten
Wenig.
DNS requests dauern dann vielleicht ein paar millisekunden kürzer oder länger (der von deinem Provider ist in der regel auch schnell und nah).
Aber in der praxis gehst du ja meist auf die gleichen seiten, da wird dann eh der DNS cache auf dem eigenen Rechner verwendet.
Gibt so benchmarks dafür https://www.grc.com/dns/benchmark.htm
Ja, 5 Minuten ist üblich.
Wenn die DNS Anfrage 40 ms länger dauert macht das den Braten meist nicht fett. Je nach Internetgeschwindigkeit und Endgerät dauert es schonmal ne Sekunde ne Website zu laden. Das fällt nicht auf wenn es alle 5 Minuten 40 ms länger dauert.
Bei einer Webseite macht das mit großer Wahrscheinlichkeit nichts aus. Allerdings benötigt eine Webseite, die eine Sekunde lädt, auch mehrere bis viele DNS-Aufrufe. Wir sind uns aber einig, dass das beim Surfen wenig ins Gewicht fällt. Wie sich das beim Gaming verhält, kann ich mangels Erfahrung nicht sagen.
Beim gaming wird garkein DNS benutzt, das läuft alles direkt über IPs.
In der Regel.
Sowas wie Minecraft ist da die Ausnahme, weil man da die Adresse für die Server eintippen muss. Aber da wird die Domain natürlich auch nur einmal aufgelöst wenn man den Server beitritt.
Die Namensauflösung kann ein wenig schneller oder langsamer sein, je nach Entfernung des DNS Resolvers.
Beim Internetsurfen ist das möglicherweise spürbar. Auf die Übertragung von größeren Dateien gibt es keine spürbaren Auswirkungen.
Kaum. Beim ersten Namensauflösen würde das einige bis einige Dutzend Millisekunden länger dauern - allerdings würde üblicherweise der empfangene record in deinem DNS forwarder für unbestimmte Zeit (oft ein Tag, kann aber auch kürzer) zwischengespeichert werden. Neues Auflösen innerhalb dieser Zeit würde damit genauso schnell gehen.
Aber eventuell wäre eine bessere und potentiell schnellere Alternative (muss aber nicht unbedingt schneller - das hängt bissel von deiner Nutzung ab) selbst einen rekursiven nameserver ins LAN zu tun, und den dann zu befragen. Die, welche du ansonsten alternativ befragen würdest, tun auch nichts anderes.
Einrichten von einem rekursiven name server ist Kinderspiel. Konfigurationsaufwand ist minimal, und Ersteinrichtung beschränkt sich oft auf lediglich das Installieren. Und natürlich deine Geräte anweisen, deinen rekursiven name server zum Auflösen zu verwenden. Das können die sogar automatisch mitgeteilt bekommen, über DHCP.
Ein populärer rekursiver name server wäre zum Beispiel einer, der "unbound" heißt.
allerdings würde üblicherweise der empfangene record in deinem DNS forwarder für unbestimmte Zeit (oft ein Tag, kann aber auch kürzer) zwischengespeichert werden.
Nach meinen Recherchen ist es oft viel kürzer als ein Tag, häufig in der Größenordnung von 5 Minuten bis unter einer Stunde.
Aber eventuell wäre eine bessere und potentiell schnellere Alternative (muss aber nicht unbedingt schneller - das hängt bissel von deiner Nutzung ab) selbst einen rekursiven nameserver ins LAN zu tun, und den dann zu befragen. Die, welche du ansonsten alternativ befragen würdest, tun auch nichts anderes.
Auch dieser Resolver ist abhängig von der TTL, die der authoritative Server mitliefert. Sprich: Der Eintrag altert auf dem lokalen Resolver genau so schnell aus wie auf dem Endgerät.
Wie lange, wird im DNS record selbst angegeben, mittels der TTL (time to live). 86400 (Sekunden, ein Tag) ist lediglich ein oft verwendeter Wert, aber der kann nahezu beliebig sein.
Dass ein rekursiver name server die TTL respektiert, möge deutlich sein. Das "potentiell schneller" bezieht sich auf die geringe Latenz, dadurch dass sich der rekursive name server im LAN befindet.
Wie lange, wird im DNS record selbst angegeben, mittels der TTL (time to live).
Ich weiß das. Er wird im Ursprung vom authoritativen DNS geliefert.
86400 (Sekunden, ein Tag) ist lediglich ein oft verwendeter Wert, aber der kann nahezu beliebig sein.
Nach meiner Beobachtung wird dieser Wert eben nicht oft verwendet. Oft ist der Wert viel kürzer.
Das "potentiell schneller" bezieht sich auf die geringe Latenz, dadurch dass sich der rekursive name server im LAN befindet.
Das ist natürlich ein Aspekt. Muss der rekursive Resolver auch erst einmal die Informationen einholen. Das Endgerät muss also die Antwortzeit des externen und die des internen Servers abwarten. Die Caches laufen ja auf Endgerät und dem Resolver im LAN nahezu zeitgleich ab.
Deswegen "abhängig von wie verwendet". Z.B. wenn der authoritative NS vom zone apex schon gecached ist, und jetzt ein A oder AAAA record eines hosts der zone aufgelöst werden soll, hat dies gute Chancen, schneller erledigt zu sein als erst einen externen rekursiven nameserver dazu befragen zu müssen, der womöglich erst mehrfache NS Abfragen bis zum Ermitteln des authoritativen NS senden muss. Es ist schwer, so nicht unmöglich, eine verbindliche Aussage zur Performance zu treffen ohne Art der Nutzung genau zu kennen.
Und nicht zu vergessen der Aspekt, dass Informationsbeschaffung nicht nur an eine Stelle delegiert wird, was einen zusätzlichen Schutz gegen allzu neugierige Diensteanbieter bietet.
Deswegen "abhängig von wie verwendet". Z.B. wenn der authoritative NS vom zone apex schon gecached ist,
Das ist er in der Regel aber nicht, vor allem nicht mit der Standardkonfiguration z. B. von unbound. Für die authoritative Auflösung musst Du ja den authoritativen DNS fragen. Eine Rekursive Anfrage bedeutet aber, dass Dein Rechner den lokalen DNS fragt, der fragt selbstständig seinen Upstream DNS usw. bis eine Antwort erhalten wurde. Die Antwort ist in der Regel nicht-authoritativ. Der rekursive resolver cached DNS-Antworten, also das Ergebnis der Auflösung, nicht aber DNS-Adressen. Das wäre allenfalls bei der ungebräuchlichen iterativen Anfrage der Fall.
Es ist schwer, so nicht unmöglich, eine verbindliche Aussage zur Performance zu treffen ohne Art der Nutzung genau zu kennen.
Das ist allerdings richtig.
ist aber dann schon gecached, when er davor schon angefragt wurde. also apex ja, host nicht. "Eine Rekursive Anfrage bedeutet aber, dass Dein Rechner den lokalen DNS fragt" - nee. ausser wir reden jetzt aneinander vorbei. Der rekursive name server muss niemals einen nicht-authoritativen name server befragen. dafür ist er ja ein rekursiver name server, um alle abfragen selbst vornehmen zu können. Er kennt keine upstream server. Er kennt root server, TLD server, und weiss wie er die jeweils befragen muss, um sich nach "unten" zu hangeln. Und gesehen dass er auch namen von name servern nach adressen auflöst, cacht er die ebenfalls (NS records lösen ja zu Namen der nameserver auf, die dann wiederum zu Adressen aufgelöst werden - und beide werden gecached).
Der rekursive name server muss niemals einen nicht-authoritativen name server befragen. dafür ist er ja ein rekursiver name server, um alle abfragen selbst vornehmen zu können. Er kennt keine upstream server. Er kennt root server, TLD server, und weiss wie er die jeweils befragen muss, um sich nach "unten" zu hangeln.
Ja, Du hast Recht. Ich hatte da einen Knoten im Hirn. Danke für die Klarstellung.
Ein Recursor kennt genaugenommen nicht einmal <.>, er kennt nur einige Rootserver.
Das große Problem ist die Latenz des Anschlusses. Nehmen wir an, ein lokaler Recursor muß einen Authoriative kontaktieren - in der gleichen Zeit kontaktiert der Recursor eines großen Anbieters mehrere Authoriatives nacheinander. Dazu kommt, daß aufgrund der schieren Größe von Cache und Nutzerschaft die Wahrscheinlichkeit eines notwenidgen Lookups beim Authoriative deutlich kleiner ist.
Ganz klar, kann der lokale Recursor aus dem Cache bedienen wird er immer obsiegen, braucht er externe Lookups kann sich das Blatt schnell wenden. (Cache Refreshing mal außen vor)
Und mickrige TTLs, wie sie anscheinend inzwischen Usus sind, verschieben zu Gunsten des großen Anbieters.
Andererseits, selbst wenn ich bei ner Webseite mal eine Latenz von 100ms extra zahle, was solls? Wieviel Latenz entsteht denn alleine durch die Handshakes zu allen Quellen einer Webseite?
Und es gibt natürlich auch andere Gründe für einen eigenen Recursor.
Jetzt kommt noch das prefetch von verschiedenen web browsern mit ins Spiel, und Zeitunterschied wird gänzlich unvorhersehbar.
Was den Nutzen dann tatsächlich in Richtung "andere Gründe" verschiebt.
Ich glaube, das wird überschätzt. Aber man muss ein paar Details berücksichtigen:
Wenn Du eine Webseite aufrufst, werden viele Ressourcen geladen. Diese kommen oft von unterschiedlichen Servern. Hier bei gutefrage.net wird nicht nur von www.gutefrage.net geladen, sondern auch von consent.gutefrage.net, images.gutefrage.net und cp.gutefrage.net. Für alle vier Subdomains sind DNS-Anfragen notwendig. Zudem wir google-analytics.com kontaktiert.
DNS-Antworten werden vom Endgerät gespeichert, sodass nicht bei jedem Aufruf einer Seite erneut die Anfragen erforderlich sind. Allerdings werden die DNS-Anfragen mit einem TTL-Wert (Time-to-Live), also einer Lebensdauer ausgeliefert. Nach Ablauf dieser Lebensdauer muss das Endgerät erneut fragen. Die TTL-Werte der genannten Subdomains sind:
cp.gutefrage.net: 300 s
consent.gutefrage.net, images.gutefrage.net, www.gutefrage.net: 60 s
Die DNS-Anfragen müssen also relativ häufig wiederholt werden.
Eine DNS-Abfrage geht rasend schnell. Wenn der DNS-Server keine chronische Überlastung hat oder sonstige Probleme, wirst du den Unterschied nicht merken.
Viele Einträge haben nur eine Lebensdauer zwischen 5 Minuten und einer Stunde. Die von Gutefrage verwendeten Einträge sind z. B. nur 5 Minuten gültig. Also alle 5 Minuten eine erneute Anfrage ...
Ja, richtig, immer noch besser als bei jedem Seitenaufruf.