> [...]
>> Latenz hat nicht viel mit Bandbreite zu tun. /Spielen/ kann man dann
>> sicherlich nicht mehr (so gut), wenn sämtliche Unterseekabel gekappt
>> würden aber es käme dann wohl auf andere Anwendungen "im Netz" an.
>
> Die Latenz beeinflußt allerdings schon die nutzdatenrate wenn die ACK
> pakete später kommen und auf die gewartet werden muß. Die meisten
> anwendungen/Protokolle erlauben nur eine bestimmte Zahl ACKs die
> on-the-fly sein dürfen und reduzieren dann die Senderate. Receive-Window?
Erm, Kay,
dein Text hat suggeriert, dass die Bandbreite einer Satellitenverbindung
gering ist. Das ist schlicht nicht der Fall.
Zusätzlich hat niemand irgendwo behauptet, dass die Kappung sämtlicher
Unterseekabel /keine/ Auswirkungen haben würde. Natürlich hat eine
solche Massnahme Auswirkungen. Nur eben auf die verschiedenen Dienste
der verschiedenen Anbieter deutlich verschiedene Auswirkungen.
> [...]
>> Die Root Nameserver sind heutzutage georedundant, sodass Du eh vom
>> topologisch nächstgelegenen "[a-m].
root-server.net" eine Antwort
>> bekommst... Du bist ernsthaft der Meinung, dass nur 13 Root Nameserver
>> die entsprechenden DNS-Anfragen heutzutage wuppen!? %-D
>
> Nein, [...]
> [...]
> DNS wenn der root nicht erreichen könnte.
Das Szenario waren gekappte Unterseekabel. Eine (von vielen) in den Raum
gestellten Auswirkungen war die generelle Nichterreichbarkeit /aller/
Root Nameserver, weil die ja in den USA stehen würden.
Die Klarstellung war, dass die (meisten) Root Nameserver seit langem
georedundant aufgebaut sind.
Ja. Vermutlich nicht alle. Durch das RR cycling dürfte hin und wieder
ein tatsächlich nicht erreichbarer Root Nameserver als erstes gefragt
werden. Das verzögert die gewünschte Antwort (in einem solchen Fall)
etwas.
... Wie geschrieben: Niemand behauptet, dass es /keine/ Auswirkungen
geben würde.
> Und die rootserver müssen ihre Zonendaten auch untereinander abgleichen.
> Was machen die wenn ihre Verbindung kappt, mit den alternden Daten
> weiter arbeiten? Bis TTL erreicht oder ewig. Keiner weiß wie lange
> ausfall X dauern wird.
Ich weiß nicht, welche Vorstellung Du von Root Nameservers hast. TTLs
spielen keine Rolle, weil die sich nicht gegenseitig per "normaler
DNS-Anfragen" auf dem laufenden halten, nach meiner Kenntnis eher mit
einem RSync-artigen oder multimaster-LDAP-artigem Mechanismus als mit
Zone Transfers von einem (single point of failure) Root Master Server.
Sicherlich sollte man am Datenbestand der Root Nameserver nach einem
Ausfall wie dem im Szenario beschriebenen nicht weiter herumspielen.
Aber mach Dir klar, welche Informationen die Root Nameserver feeden! Die
diversen Top Level Domains, also so etwas wie "de.", "com.", "info." etc
pp you name it. Da ändert sich nicht im durchschnittlich täglichen
Massstab etwas, eher im monatlichen oder gar halbjährlichen.
Die Ebene der First Level Domains /könnte/ ein Problem sein. Ich weiss
nicht, ob die Betreiber derselben selbst für Massnahmen für
Ausfallsicherheit und ähnliches zuständig sind - ich würde es vermuten.
Wo man dann vielleicht davon ausgehen darf, dass eine "de."- oder
"us."-gTLD (ebenfalls) georedundant ausgeführt sind, trifft das auf eine
"tel."-TLD vermutlich nicht mehr zu.
Aber nochmal: Niemand behauptet, dass es /keine/ Auswirkungen haben
würde, die Unterseekabel zu kappen.
> Du geh'st ernsthaft davon aus das ein Ausfall aller Transatlantischen
> Verbindungen für längere Zeit die rootserver nicht out-of-sync bringt?
Ja. Insbesondere wenn entsprechende Konsequenzen gezogen und bis auf
weiteres keine (g)TLDs mehr angelegt werden; wie geschrieben: *(g)TLDs*.
> Satelliten kann man vermutlich leichter stören. Und dann... ist der
> WKIII auch schon da?
Bullshit! Weltuntergangsfantasie!
Ist Dein Ziel eine (halbwegs) realistische Einschätzung der Folgen des
beschriebenen Szenarios oder das Suhlen in Weltuntergangsfantasien?
Bei ersterem schreiben wir gerne weiter, bei letzterem lass bitte deiner
Fantasie in einer passenderen usenet group freien Lauf.
> [...]
>> Das liest sich ein wenig so, als sei die Verwendung von DNS-Namen etwas
>> dummes oder böses...
>
> Nein, das sicher nicht. Aber wenn du einen HTTPS-request absetzt dann
> fragt dein Browser doch wohl erst mal den DNS nach der IP. Und beim
> Sessionaufbau wird ein Zertifikat/DNSname geprüft, ggf. über eine CA
> deren IP auch erst ermittelt werden muß. Kein DNS=Keine IP-antwort=Ende.
IP-Adressen haben bei Zertifikaten heutzutage keine Relevanz mehr, weil
sie (sinnvoller Weise) nicht mehr zertifiziert werden.
Meiner Wahrnehmung nach werden bei Nichterreichbarkeit entsprechender
OCSP-Server Zertifikate nicht für ungültig erklärt.
Wo also siehst Du hier das Problem!?
> safebrowsing ist auch so ein Teil das besser nicht ausfallen dürfte oder?
Warum!? Führt das zur (technischen) Nichterreichbarkeit der Site? Wüßte
ich nicht.
>> man zwischen Technologie und Implementierung trennen - heutzutage
>> werden etliche (Internet-) Technologien, die als solche eine
>> ausfallsichere, verteilte, skalierende, flexible Implementierung erlauben,
>> starr, kaum skalierend und unflexibel implementiert.
>> ... DNS gehört nicht dazu.
>
> DOH, DOT, Iterativer Modus oder nicht?
DOH und DOT sind nach meiner Kenntnis bislang _keine_ DNS-Methoden.
Außerdem kann man sie im Browser und so etwas wie Smartphone-OSs
ausschalten. Insbesondere sind sie nicht die Regelmethoden für
DNS-Auflösung.
Was Du mit "Iterativer Modus" meinst, ist mir nicht klar. Wenn Du
Nicht-Forwarding meinst, dann wird es für Domains, die nicht "auf dem
selben Kontinent" liegen und (g)TLDs, die nicht (ausreichend)
georedundant implementiert sind, zu beeinträchtigungen und
möglicherweise irgendwann Nichterreichbarkeit führen, ja.
Wie mehrfach geschrieben...
> [...]
MfG Henning
--
Can't open /usr/fortunes. Lid stuck on cookie jar.