DNS-Resolver vs. NS-Eintrag TTL

Question

Wenn ein DNS-Resolver eine Domäne/Zone nach einem autoritativen Nameserver sucht, berücksichtigt er dann alle sechs Datensätze und durchläuft sie?

Ja, ein richtiger rekursiver Nameserver berücksichtigt alle Nameserver und versucht später jedes Mal, den schnellsten abzufragen.

Ein grober Algorithmus sieht etwa so aus:

Probieren Sie bei einem Kaltstart (ohne Cache) alle nach dem Zufallsprinzip aus und zeichnen Sie auf, wie schnell sie antworten (hier müssen Sie möglicherweise den UDP-Fall vom TCP-Fall unterscheiden).
nach einiger Zeit beginnen Sie, häufiger die schnellste zu verwenden, basierend auf früheren Antworten
Beachten Sie jedoch, dass Sie nicht auf unbestimmte Zeit bei einem bestimmten Nameserver bleiben dürfen, sondern auch „von Zeit zu Zeit“ die anderen ausprobieren müssen. Warum? Weil sich die Netzwerktopologie ändern kann, ebenso wie die Nameserver selbst. ns3Einer ist für Ihren speziellen Standpunkt heute vielleicht der schnellere, aber morgen vielleicht ns5schon. Sie müssen also den schnellsten verwenden, aber nicht immer, nur um sicherzustellen, dass Sie automatisch einen anderen finden können, der schneller ist als der, von dem Sie glauben, dass er gerade der schnellste ist.

Wenn ein Resolver den 1. NS-Server verwendet

Hier aufhören. Die Datensätze werden in einem Satz und nicht in einer Liste geliefert. Das heißt, es gibt keine inhärente Ordnung im DNS. Natürlich gibt es eine Ordnung in der Darstellung auf dem Draht oder auf dem Display, aber sie kommt nicht vom Protokoll.

Datensatzsätze sind Säcke: Sie erhalten Datensätze ohne Reihenfolge. Tatsächlich können Sie sehen, dass viele Nameserver bei genau derselben Abfrage, wenn die Antwort mehrere Datensätze enthält, die Datensätze bei jeder Abfrage anders anordnen, um genau Clientsystemen entgegenzuwirken, die nur das erste Element berücksichtigen und die anderen ignorieren würden.

wenn dieser autoritative Nameserver nicht antwortet

Siehe Algorithmus oben: Wenn einer der Nameserver im NSSet nicht antwortet, können Sie das als dasselbe betrachten wie „Antworten als langsamste Antwort von jedem anderen“. Der Client-DNS hat Timeouts, sodass er nicht unendlich wartet, sondern diesen bestimmten Nameserver als zu langsam markiert und zu anderen wechselt. Beim ersten Mal erleiden Sie also eine Strafe, weil das System versuchen muss, diesen Nameserver zu kontaktieren, ein wenig (ein paar Sekunden) warten, es erneut versuchen und irgendwann aufhören muss, diesen Nameserver zu verwenden. Nach dieser Rampe wird es die anderen Nameserver verwenden und alles wird schnell gehen. Aber wenn Sie beim ersten Mal feststellen müssen, dass ein bestimmter Nameserver langsam ist/nicht antwortet, indem Sie wirklich versuchen, ihn zu kontaktieren, können Sie das Problem nicht ohne Versuch ableiten.

Bedeutet das, dass ich für NS-Einträge eine kurze TTL festlegen muss?

Vielleicht, aber es ist größtenteils irrelevant. Warum? Weil Ihre NSEinträge in der übergeordneten Zone Ihrer Domain veröffentlicht werden, um die DNS-Delegation sicherzustellen. Sie werden dort natürlich mit einer TTL veröffentlicht, da allen Einträgen eine TTL zugeordnet ist, aber sie werden in einer Zone veröffentlicht, die Sie nicht kontrollieren, daher können Sie ihre TTL-Werte NICHT wählen!

(Hier gibt es eine komplizierte/nicht ganz abgeschlossene Diskussion über diese Datensätze, NSdie beispielsweise aus zwei Teilen bestehen: dem übergeordneten und dem untergeordneten Teil, mit der Frage „Welcher ist wirklich maßgebend?“ Wenn der übergeordnete Teil eine TTL von 1 Woche für NSDatensätze hat und Sie in Ihrer Zone dieselben NSDatensätze eine TTL von 1 Sekunde haben, was sollte der rekursive Nameserver dann tun? Man könnte zu dem Schluss gelangen, dass normalerweise der untergeordnete Teil der Delegation maßgebend IST, sodass 1 Sekunde hier gewinnt; in der Praxis sind mehrere DNS-Implementierungen „übergeordnet-zentriert“, d. h. sie verwenden die Daten auf der übergeordneten Seite, sodass 1 Woche hier gewinnt.)

TTLs sind immer ein Kompromiss. Wenn man sie kennt, kommen manche Leute sofort zu dem Schluss, dass die Dinge mit sehr niedrigen TTLs besser funktionieren ... was in manchen Fällen zutrifft, in anderen jedoch nicht so sehr. Caches sind gut, aber wenn sie nicht da wären (d. h. wenn man nicht genügend große TTLs verwendet), ist man nicht gegen kleine Probleme gewappnet, die alles verschwinden lassen würden, weil die Caches die Namen bereits abgelaufen hätten.

Außerdem hat der TTL-Wert keine (oder nur geringe) Auswirkungen auf den obigen Algorithmus, der alle Nameserver durchläuft, es mit Timeout versucht und beim schnellsten ankommt.

Wenn Sie sich also ansehen, was in TLD-Nameservern (die NSDatensätze für alle Domänen unter dieser TLD hosten) oder in verschiedenen Empfehlungen passiert, werden Sie häufig NSDatensätze mit einer TTL von 1 oder 2 Tagen sehen.

Irgendwelche Ratschläge, wie Resolver-DNS mit nicht reagierendem NS und seinem TTL funktioniert?

Jeder Resolver macht das auf seine Weise :-) Dies ist im Protokoll nicht wirklich festgelegt, es ist ein Implementierungsdetail. Sie können den Quellcode für den Code studieren, den Sie installieren können, aber Sie werden wahrscheinlich keine Details dazu von großen öffentlichen rekursiven DNS-Anbietern erhalten.

Nähere Einzelheiten findet ihr jedoch hier:

RFC 1034 §5.3.3 enthält ebenfalls einige Informationen (beachten Sie auch, dass ein Fall berücksichtigt wird, den Sie vergessen haben: Ein bestimmter Nameserver kann mehrere IP-Adressen haben – heute sollte dies sogar immer der Fall sein, mit einer IPv4- und einer IPv6-Adresse – und es gibt keine Garantie, dass Sie mit jeder in der gleichen Zeit Ergebnisse erzielen):

Zusätzlich zu den Namen und Adressen der Server kann die SLIST-Datenstruktur sortiert werden, um zuerst die besten Server zu verwenden und sicherzustellen, dass alle Adressen aller Server im Round-Robin-Verfahren verwendet werden. Die Sortierung kann eine einfache Funktion sein, bei der Adressen im lokalen Netzwerk gegenüber anderen bevorzugt werden, oder sie kann Statistiken aus vergangenen Ereignissen beinhalten, wie z. B. frühere Antwortzeiten und Schlagdurchschnitte.

Schritt 3 sendet Anfragen, bis eine Antwort empfangen wird. Die Strategie besteht darin, alle Adressen aller Server mit einem Timeout zwischen jeder Übertragung zu durchlaufen. In der Praxis ist es wichtig, alle Adressen eines Multihomed-Hosts zu verwenden, und eine zu aggressive Weiterleitungsrichtlinie verlangsamt die Antwort tatsächlich, wenn sie von mehreren Resolvern verwendet wird, die um denselben Nameserver konkurrieren, und gelegentlich sogar nur um einen einzigen Resolver. SLIST enthält normalerweise Datenwerte, um die Timeouts zu steuern und vorherige Übertragungen zu verfolgen.

RFC 1035 §7.2 besagt Folgendes:

Um die Initialisierung von SLIST abzuschließen, fügt der Resolver alle ihm zur Verfügung stehenden Verlaufsinformationen jeder Adresse in SLIST hinzu. Dies besteht normalerweise aus einer Art gewichtetem Durchschnitt für die Antwortzeit der Adresse und dem Batting Average der Adresse (d. h. wie oft die Adresse überhaupt auf die Anfrage geantwortet hat). Beachten Sie, dass diese Informationen pro Adresse und nicht pro Nameserver gespeichert werden sollten, da die Antwortzeit und der Batting Average eines bestimmten Servers von Adresse zu Adresse erheblich variieren können. Beachten Sie auch, dass diese Informationen tatsächlich spezifisch für ein Paar aus Resolveradresse und Serveradresse sind, sodass ein Resolver mit mehreren Adressen möglicherweise separate Verlaufsinformationen für jede seiner Adressen speichern möchte. Ein Teil dieses Schritts muss sich mit Adressen befassen, die keinen solchen Verlauf haben; in diesem Fall sollte eine erwartete Roundtrip-Zeit von 5-10 Sekunden der schlimmste Fall sein, mit niedrigeren Schätzungen für dasselbe lokale Netzwerk usw.

Beachten Sie, dass der Resolver-Algorithmus SLIST immer dann neu initialisiert, wenn eine Delegierung erfolgt.

Die Informationen legen eine Teilrangfolge der verfügbaren Nameserveradressen fest. Jedes Mal, wenn eine Adresse ausgewählt wird, sollte der Status geändert werden, um eine erneute Auswahl zu verhindern, bis alle anderen Adressen ausprobiert wurden. Das Timeout für jede Übertragung sollte 50-100 % größer sein als der durchschnittliche vorhergesagte Wert, um Abweichungen in der Antwort zu berücksichtigen.

Und zum Schluss noch etwas spezieller dazu:

Wie in diesem Artikel von imperva dargestellt

In diesem Artikel, auf den Sie sich beziehen, geht es um das Problem, das bei Benutzern auftrat, die Dyn-Nameserver verwenden, als es zu einem Ausfall kam. Wenn Sie also nur Dyn-Nameserver verwenden, haben Sie ein Problem. Denn selbst wenn Sie Ihre Zone ändern, um andere zu verwenden, NSbedeutet die TTL der Datensätze, dass Ihre Änderung nicht sofort sichtbar ist. Aber das sagt in Wirklichkeit nicht viel über TTLs aus, sondern nur viel über die DNS-Verwaltung: Wenn Sie für wichtige Zonen ausfallsicher sein möchten, verwenden Sie nicht einen einzigen DNS-Anbieter, sondern mehrere (was natürlich eine gewisse Koordination zwischen ihnen erfordert, Sie können Anbieter X und Y nicht einfach beliebig mischen und anpassen, und es ist noch komplizierter, wenn Sie DNSSEC in die Mischung einbeziehen, aber es ist möglich). Auf diese Weise wird, genau aufgrund des oben schnell skizzierten Algorithmus, selbst wenn beispielsweise 2 von 5 Nameservern vollständig ausfallen, weil dieser bestimmte Anbieter ein Problem hat, der andere die Last übernehmen und dafür sorgen, dass Ihre Domäne funktioniert. Bei jeder neuen Abfrage von Besuchern kann es zu einer zusätzlichen Verzögerung kommen (weil nicht alle rekursiven Nameserver sofort verstehen, dass sie zu bestimmten Nameservern wechseln müssen, da zwei von fünf ausgefallen sind). Außerdem kann es zu weiteren Verzögerungen kommen, weil die anderen drei mit mehr Abfragen als normal überlastet sind (das DNS führt standardmäßig einen Lastausgleich durch, sodass theoretisch jeder Nameserver ungefähr das gleiche Abfragevolumen erhält). Es wird jedoch trotzdem eine Antwort gegeben.

PS: nicht gefragt, aber da es manchmal nicht klar ist, müssen alle Datensätze in einem bestimmten Datensatz dieselbe TTL haben. Die TTL gilt pro Datensatz, muss aber in einem bestimmten Datensatz gleich sein, d. h. für ein bestimmtes Tupel aus (Name, Datensatztyp) [und Klasse, aber niemand verwendet etwas anderes INals Klasse]

Answer 1

Wenn ein DNS-Resolver eine Domäne/Zone nach einem autoritativen Nameserver sucht, berücksichtigt er dann alle sechs Datensätze und durchläuft sie?

Ja, ein richtiger rekursiver Nameserver berücksichtigt alle Nameserver und versucht später jedes Mal, den schnellsten abzufragen.

Ein grober Algorithmus sieht etwa so aus:

Probieren Sie bei einem Kaltstart (ohne Cache) alle nach dem Zufallsprinzip aus und zeichnen Sie auf, wie schnell sie antworten (hier müssen Sie möglicherweise den UDP-Fall vom TCP-Fall unterscheiden).
nach einiger Zeit beginnen Sie, häufiger die schnellste zu verwenden, basierend auf früheren Antworten
Beachten Sie jedoch, dass Sie nicht auf unbestimmte Zeit bei einem bestimmten Nameserver bleiben dürfen, sondern auch „von Zeit zu Zeit“ die anderen ausprobieren müssen. Warum? Weil sich die Netzwerktopologie ändern kann, ebenso wie die Nameserver selbst. ns3Einer ist für Ihren speziellen Standpunkt heute vielleicht der schnellere, aber morgen vielleicht ns5schon. Sie müssen also den schnellsten verwenden, aber nicht immer, nur um sicherzustellen, dass Sie automatisch einen anderen finden können, der schneller ist als der, von dem Sie glauben, dass er gerade der schnellste ist.

Wenn ein Resolver den 1. NS-Server verwendet

Hier aufhören. Die Datensätze werden in einem Satz und nicht in einer Liste geliefert. Das heißt, es gibt keine inhärente Ordnung im DNS. Natürlich gibt es eine Ordnung in der Darstellung auf dem Draht oder auf dem Display, aber sie kommt nicht vom Protokoll.

Datensatzsätze sind Säcke: Sie erhalten Datensätze ohne Reihenfolge. Tatsächlich können Sie sehen, dass viele Nameserver bei genau derselben Abfrage, wenn die Antwort mehrere Datensätze enthält, die Datensätze bei jeder Abfrage anders anordnen, um genau Clientsystemen entgegenzuwirken, die nur das erste Element berücksichtigen und die anderen ignorieren würden.

wenn dieser autoritative Nameserver nicht antwortet

Siehe Algorithmus oben: Wenn einer der Nameserver im NSSet nicht antwortet, können Sie das als dasselbe betrachten wie „Antworten als langsamste Antwort von jedem anderen“. Der Client-DNS hat Timeouts, sodass er nicht unendlich wartet, sondern diesen bestimmten Nameserver als zu langsam markiert und zu anderen wechselt. Beim ersten Mal erleiden Sie also eine Strafe, weil das System versuchen muss, diesen Nameserver zu kontaktieren, ein wenig (ein paar Sekunden) warten, es erneut versuchen und irgendwann aufhören muss, diesen Nameserver zu verwenden. Nach dieser Rampe wird es die anderen Nameserver verwenden und alles wird schnell gehen. Aber wenn Sie beim ersten Mal feststellen müssen, dass ein bestimmter Nameserver langsam ist/nicht antwortet, indem Sie wirklich versuchen, ihn zu kontaktieren, können Sie das Problem nicht ohne Versuch ableiten.

Bedeutet das, dass ich für NS-Einträge eine kurze TTL festlegen muss?

Vielleicht, aber es ist größtenteils irrelevant. Warum? Weil Ihre NSEinträge in der übergeordneten Zone Ihrer Domain veröffentlicht werden, um die DNS-Delegation sicherzustellen. Sie werden dort natürlich mit einer TTL veröffentlicht, da allen Einträgen eine TTL zugeordnet ist, aber sie werden in einer Zone veröffentlicht, die Sie nicht kontrollieren, daher können Sie ihre TTL-Werte NICHT wählen!

(Hier gibt es eine komplizierte/nicht ganz abgeschlossene Diskussion über diese Datensätze, NSdie beispielsweise aus zwei Teilen bestehen: dem übergeordneten und dem untergeordneten Teil, mit der Frage „Welcher ist wirklich maßgebend?“ Wenn der übergeordnete Teil eine TTL von 1 Woche für NSDatensätze hat und Sie in Ihrer Zone dieselben NSDatensätze eine TTL von 1 Sekunde haben, was sollte der rekursive Nameserver dann tun? Man könnte zu dem Schluss gelangen, dass normalerweise der untergeordnete Teil der Delegation maßgebend IST, sodass 1 Sekunde hier gewinnt; in der Praxis sind mehrere DNS-Implementierungen „übergeordnet-zentriert“, d. h. sie verwenden die Daten auf der übergeordneten Seite, sodass 1 Woche hier gewinnt.)

TTLs sind immer ein Kompromiss. Wenn man sie kennt, kommen manche Leute sofort zu dem Schluss, dass die Dinge mit sehr niedrigen TTLs besser funktionieren ... was in manchen Fällen zutrifft, in anderen jedoch nicht so sehr. Caches sind gut, aber wenn sie nicht da wären (d. h. wenn man nicht genügend große TTLs verwendet), ist man nicht gegen kleine Probleme gewappnet, die alles verschwinden lassen würden, weil die Caches die Namen bereits abgelaufen hätten.

Außerdem hat der TTL-Wert keine (oder nur geringe) Auswirkungen auf den obigen Algorithmus, der alle Nameserver durchläuft, es mit Timeout versucht und beim schnellsten ankommt.

Wenn Sie sich also ansehen, was in TLD-Nameservern (die NSDatensätze für alle Domänen unter dieser TLD hosten) oder in verschiedenen Empfehlungen passiert, werden Sie häufig NSDatensätze mit einer TTL von 1 oder 2 Tagen sehen.

Irgendwelche Ratschläge, wie Resolver-DNS mit nicht reagierendem NS und seinem TTL funktioniert?

Jeder Resolver macht das auf seine Weise :-) Dies ist im Protokoll nicht wirklich festgelegt, es ist ein Implementierungsdetail. Sie können den Quellcode für den Code studieren, den Sie installieren können, aber Sie werden wahrscheinlich keine Details dazu von großen öffentlichen rekursiven DNS-Anbietern erhalten.

Nähere Einzelheiten findet ihr jedoch hier:

RFC 1034 §5.3.3 enthält ebenfalls einige Informationen (beachten Sie auch, dass ein Fall berücksichtigt wird, den Sie vergessen haben: Ein bestimmter Nameserver kann mehrere IP-Adressen haben – heute sollte dies sogar immer der Fall sein, mit einer IPv4- und einer IPv6-Adresse – und es gibt keine Garantie, dass Sie mit jeder in der gleichen Zeit Ergebnisse erzielen):

Zusätzlich zu den Namen und Adressen der Server kann die SLIST-Datenstruktur sortiert werden, um zuerst die besten Server zu verwenden und sicherzustellen, dass alle Adressen aller Server im Round-Robin-Verfahren verwendet werden. Die Sortierung kann eine einfache Funktion sein, bei der Adressen im lokalen Netzwerk gegenüber anderen bevorzugt werden, oder sie kann Statistiken aus vergangenen Ereignissen beinhalten, wie z. B. frühere Antwortzeiten und Schlagdurchschnitte.

Schritt 3 sendet Anfragen, bis eine Antwort empfangen wird. Die Strategie besteht darin, alle Adressen aller Server mit einem Timeout zwischen jeder Übertragung zu durchlaufen. In der Praxis ist es wichtig, alle Adressen eines Multihomed-Hosts zu verwenden, und eine zu aggressive Weiterleitungsrichtlinie verlangsamt die Antwort tatsächlich, wenn sie von mehreren Resolvern verwendet wird, die um denselben Nameserver konkurrieren, und gelegentlich sogar nur um einen einzigen Resolver. SLIST enthält normalerweise Datenwerte, um die Timeouts zu steuern und vorherige Übertragungen zu verfolgen.

RFC 1035 §7.2 besagt Folgendes:

Um die Initialisierung von SLIST abzuschließen, fügt der Resolver alle ihm zur Verfügung stehenden Verlaufsinformationen jeder Adresse in SLIST hinzu. Dies besteht normalerweise aus einer Art gewichtetem Durchschnitt für die Antwortzeit der Adresse und dem Batting Average der Adresse (d. h. wie oft die Adresse überhaupt auf die Anfrage geantwortet hat). Beachten Sie, dass diese Informationen pro Adresse und nicht pro Nameserver gespeichert werden sollten, da die Antwortzeit und der Batting Average eines bestimmten Servers von Adresse zu Adresse erheblich variieren können. Beachten Sie auch, dass diese Informationen tatsächlich spezifisch für ein Paar aus Resolveradresse und Serveradresse sind, sodass ein Resolver mit mehreren Adressen möglicherweise separate Verlaufsinformationen für jede seiner Adressen speichern möchte. Ein Teil dieses Schritts muss sich mit Adressen befassen, die keinen solchen Verlauf haben; in diesem Fall sollte eine erwartete Roundtrip-Zeit von 5-10 Sekunden der schlimmste Fall sein, mit niedrigeren Schätzungen für dasselbe lokale Netzwerk usw.

Beachten Sie, dass der Resolver-Algorithmus SLIST immer dann neu initialisiert, wenn eine Delegierung erfolgt.

Die Informationen legen eine Teilrangfolge der verfügbaren Nameserveradressen fest. Jedes Mal, wenn eine Adresse ausgewählt wird, sollte der Status geändert werden, um eine erneute Auswahl zu verhindern, bis alle anderen Adressen ausprobiert wurden. Das Timeout für jede Übertragung sollte 50-100 % größer sein als der durchschnittliche vorhergesagte Wert, um Abweichungen in der Antwort zu berücksichtigen.

Und zum Schluss noch etwas spezieller dazu:

Wie in diesem Artikel von imperva dargestellt

In diesem Artikel, auf den Sie sich beziehen, geht es um das Problem, das bei Benutzern auftrat, die Dyn-Nameserver verwenden, als es zu einem Ausfall kam. Wenn Sie also nur Dyn-Nameserver verwenden, haben Sie ein Problem. Denn selbst wenn Sie Ihre Zone ändern, um andere zu verwenden, NSbedeutet die TTL der Datensätze, dass Ihre Änderung nicht sofort sichtbar ist. Aber das sagt in Wirklichkeit nicht viel über TTLs aus, sondern nur viel über die DNS-Verwaltung: Wenn Sie für wichtige Zonen ausfallsicher sein möchten, verwenden Sie nicht einen einzigen DNS-Anbieter, sondern mehrere (was natürlich eine gewisse Koordination zwischen ihnen erfordert, Sie können Anbieter X und Y nicht einfach beliebig mischen und anpassen, und es ist noch komplizierter, wenn Sie DNSSEC in die Mischung einbeziehen, aber es ist möglich). Auf diese Weise wird, genau aufgrund des oben schnell skizzierten Algorithmus, selbst wenn beispielsweise 2 von 5 Nameservern vollständig ausfallen, weil dieser bestimmte Anbieter ein Problem hat, der andere die Last übernehmen und dafür sorgen, dass Ihre Domäne funktioniert. Bei jeder neuen Abfrage von Besuchern kann es zu einer zusätzlichen Verzögerung kommen (weil nicht alle rekursiven Nameserver sofort verstehen, dass sie zu bestimmten Nameservern wechseln müssen, da zwei von fünf ausgefallen sind). Außerdem kann es zu weiteren Verzögerungen kommen, weil die anderen drei mit mehr Abfragen als normal überlastet sind (das DNS führt standardmäßig einen Lastausgleich durch, sodass theoretisch jeder Nameserver ungefähr das gleiche Abfragevolumen erhält). Es wird jedoch trotzdem eine Antwort gegeben.

PS: nicht gefragt, aber da es manchmal nicht klar ist, müssen alle Datensätze in einem bestimmten Datensatz dieselbe TTL haben. Die TTL gilt pro Datensatz, muss aber in einem bestimmten Datensatz gleich sein, d. h. für ein bestimmtes Tupel aus (Name, Datensatztyp) [und Klasse, aber niemand verwendet etwas anderes INals Klasse]

DNS-Resolver vs. NS-Eintrag TTL

Antwort1

verwandte Informationen