Die URL für Ubuntu 20.04.2 in Schritt 2 lautet:
http://at.archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/
Die URL für Ubuntu 20.04.2 in Schritt 2 lautet:
http://at.archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/
Wer ärgert sich nicht, wenn der geliebte Internetbrowser plötzlich ein völlig anderes Verhalten, als das, das man erwartet, an den Tag legt?
Beim Einstellen einer IP-Cam etwa, wenn man http://192.168.1.254 eingibt, weil die Kamera eben nur http kann, er es aber besser weiß und https everywhere versucht. Oder beim Testen eines frisch aufgesetzten haproxy. Die Liste, wo das lästig wird, kann man beliebig fortsetzen.
Aber es gibt Mittel und Wege dagegen:
Chrome:
Etwa beschreibt Howtogeek.com das Vorgehen, wie man Chrome das abgewöhnt.
Kurzfassung. Man rufe chrome://flags/#omnibox-context-menu-show-full-urls auf, aktiviere diese Einstellung und surfe eine Seite an. Der Browser hat das https everywhere immer noch aktiviert. Ich klicke mit der rechten Maustaste auf die URL und wähle im Kontextmenü „Immer vollständige URLs anzeigen“. Voilà http wird nicht mehr automatisch auf https umgeschrieben, und ich sehe die komplette URL wieder. Ich habe das bei mir unter Chromium 85.0.4183.102 getestet.
Firefox:
https-everywhere abschalten: about:config aufrufen. Nach browser.fixup.fallback-to-https suchen. Den Wert auf false setzen.
Vollständige URL in der Adressleiste anzeigen: browser.
Erstentwurf – Review ausständig; Fehler möglich; Änderungen vorbehalten.
In diesem Artikel beschreibe ich stark vereinfacht und gekürzt ein paar Grundlagen des Domain Name Systems, die für Domaininhaber, die den Registrar wechseln möchten, von Relevanz sind. Immer wieder liest man in Support-Foren von verzweifelten Nutzern, denen offenbar nicht klar ist, dass ein Domain-Umzug nicht in Echtzeit abläuft, sondern, dass ein Domaintransfer ein paar Vorbereitungen und etwas Nachbearbeitung erfordert, damit die Ausfallzeiten möglichst gering ausfallen.
Wenn man sich vorher informiert, schont das die Nerven aller Beteiligten – vor allem aber die eigenen.
Für Laien erklärt, ist das DNS am ehesten mit einem Telefonbuch für eine Region vergleichbar. Es übersetzt Namenseinträge (Domainnamen und Hostnamen) in Nummern (Internetprotokolladressen – kurz IP-Adressen). Die einfachste Art eines solchen Datensatzes ist ein sogenannter „A-Eintrag“ für das Internetprotokoll in der Version 4 (IPv4), dem heutzutage noch gängigen Protokoll, oder einem „AAAA-Eintrag“ für das Nachfolgeprotokoll IPv6.
Solche Einträge sehen in etwa so aus – im Beispiel sind die öffentlich abrufbaren Google-Nameserver:
dns.google.com. IN A 8.8.8.8
dns.google.com. IN AAAA 2001:4860:4860::8888
Dieses „Telefonbuch“ ist hierarchisch aufgebaut, d.h. es gibt einen Haupteintrag, unter dem dann weitere Einträge oder Verweise zu finden sind.
Ganz oben steht die Top Level Domain („TLD“). Ein prominentes Beispiel für eine TLD ist „.com“. Für eine TLD zuständig ist eine Vergabestelle (Registry). Sie regelt, wer unter welchen Voraussetzungen einen Namen unterhalb der TLD registrieren darf. Wer eine Domain registriert, wird zum Domaininhaber (Registrant). Die Registry bedient sich meist mehrerer Vertragspartner (Registrare), um diese Domains zu verkaufen – sprich: Namensrechte auf Zeit zu lizenzieren. Die Registrare sind die primären Vertragspartner der Registrants und vermitteln gegenüber der Registry – sie verrechnen dem Registrant auch die anfallenden Gebühren und rechnen sie mit der Registry ab.
Die Registry betreibt sogenannte Root-Nameserver, die in aller Regel nur einen Verweis vom registrierten Namen vorhalten, der auf untergeordnete Nameserver (DNS-Server) zeigt. Haben diese DNS-Server einen Hostnamen, der innerhalb der Domain, um die es geht, liegen -es geht zum Beispiel um die Domain example.com, und der DNS-Server heißt ns1.example.com- ist zusätzlich ein sogenannter „Glue-Record“ vonnöten. Dabei handelt es sich schlicht um einen „A“ oder „AAAA“ -Eintrag, den allerdings der Registrar bei den Nameservern der Registry hinterlegen muss, damit er funktioniert.
Zusätzlich können die Rootserver auch noch kryptographische Schlüssel und Signaturen ausliefern, anhand derer man gefälschten Domaininformationen vorbeugen kann. Das gegenwärtig vorherrschende System dafür heißt DNSSEC.
Die Verweise vom Root-Nameserver zu den Servern des DNS-Providers (in der der Regel sind das zugleich die des Registrars) heissen „NS-Einträge“.
Im Falle dieses Blogs ist der Registrar der deutsche Hoster „netcup“ und die Einträge sehen so aus:
grundsoli.de. 120 IN NS root-dns.netcup.net.
grundsoli.de. 120 IN NS second-dns.netcup.net.
grundsoli.de. 120 IN NS third-dns.netcup.net.
Wir sehen also, dass für den Namen „grundsoli“ innerhalb der TLD „.de“ drei verschiedene Server zuständig („autoritativ“) sind.
Jeder dieser drei Server hält die sogenannte „Zone“ vor. Die Zone kann im einfachsten Fall eine Textdatei sein, oder die in ihr enthaltenen Informationen liegen in einer Datenbank.
Eine Zone setzt sich aus mehreren Resource Records („RR“) zusammen. Zu diesen RRs gehören auch die zuvor genannten NS, A und AAAA-Einträge.
Resource Records setzen sich zusammen wie folgt:
Am Beginn der Zone steht stets ein Eintrag vom Typ SOA. Kehren wir zum Beispiel mit example.com zurück:
@ 3600 IN SOA dns1.example.com. hostmaster.example.com. (
2019090900 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
600 ; nc-ttl
);
Wir haben also die Variable für den Domainnamen „@“, die Gültigkeitsdauer des SOA-Eintrag in Caches „3600“, die Klasse Internet „IN“, die Art des Eintrags „SOA“ den primären Nameserver, das ist jener autoritative Nameserver, von dem aus die Zone vervielfältigt wird „dns1.example.com“ und eine E-Mailadresse in besonderer Schreibweise „hostmaster.example.com“ für hostmaster@example.com. Die Punkte am Ende von dns1.example.com. und hostmaster.example.com. sind extrem wichtig, da sie das Ende des Werts markieren. Fehlt der Punkt am Ende wird der Domainname an den Wert erneut angehängt. Aus „dns1.example.com“ würde dann „dns1.example.com.example.com“ – ein von Anfängern häufig gemachter Fehler. Die in Klammern folgenden Zahlenwerte schlüsseln sich wie folgt auf:
1: Die RIPE-Empfehlungen gelten stets für „für kleine und stabile Zonen“.
Der Wert für Retry muss kleiner sein, als der für Refresh. Der Wert für expire darf nicht kleiner sein als die Summe von Refresh und Retry.
Und damit haben wir die technischen Grundlagen für beeinflussbare Verzögerungen beim Domaintransfer im Grunde vollständig besprochen.
Die nicht beeinflussbaren Faktoren liegen bei der Registry, die etwa Widerspruchsfristen für einen Transfer definieren kann. Sie ist es auch, die festlegt, zu welchen Tageszeiten die Root-Nameserver eine neue Information, die von einem ihrer Registrare eingemeldet worden ist – wir reden da von neuen Nameserver-Einträgen – verarbeitet wird.
Um also einen Transfer so durchzuführen, dass er möglichst schnell über die Bühne geht, sollte man Tage oder Wochen vor dem Transfer die Werte für TTL, Refresh und NC-TTL verringern, wodurch in aller Regel auch der Wert für Retry verringert werden wird müssen. Dadurch setzt man sich vorübergehend zwar einem erhöhten Risiko aus, dass die Zone im Fehlerfall des Primärservers auch auf den Sekundärservern schneller mit ausfällt, umgekehrt müssen aber auch DNS-Resolver Dritter, auf die wir im Normalfall keinen Einfluss nehmen können, sofern sie standardkonform arbeiten, die vorgehaltenen Informationen schneller verwerfen.
Wenn man sich nun noch informiert, wann die Registry die Daten neu laden lässt, kann man den Umzug auch dahingehend zeitlich koordinieren.
Laden beispielsweise etwa die Root-Nameserver laut Registry um 13 und um 16 Uhr die Daten neu, und der Registrar aktualisiert alle 15 Minuten, so kann man nach 13 Uhr die Änderungen machen. Die anderen Kunden des Registrars hätten die neuen Informationen so – sofern sie nicht in einem Cache liegen, um 13.15 Uhr, weltweit würde der Verweis auf die neuen Server erst um 16 Uhr aktiv. Um also Gleichzeitigkeit zu erwirken, wären die Änderungen nach 15.45 Uhr, aber vor 16.00 in Auftrag zu geben. Caching Server würden die alte Information aber zumindest noch für die in TTL definierte Zeit ausliefern, wenn sie die Standards einhalten – sonst länger.
Da sich heutzutage aber auch sogenannte Public-DNS-Resolver-Dienste großer Beliebtheit erfreuen – gemeint sind damit Google DNS, Cloudflare, OpenDNS und dergleichen, und diese oft eine Möglichkeit bieten, die Cache-Information über ein Webinterface neu zu laden, also den „Cache“zu „flushen“, kann man auch hier mit globaler Wirkung für alle Nutzer dieses Dienstes Einfluss auf die Erneuerung der Information nehmen. In der Linksammlung stehen einige Dienste gelistet.
Interessante Beobachtung: Bei einer Olympia Protect Serie 96XX GSM-Alarmanlage funktioniert anscheinend eine Charge von Yesss/A1 SIM-Karten nicht.
Während die Karten in einem alten Handy klaglos funktionieren, findet die Basiseinheit eines getesteten Alarmsets schlicht kein Netz. Die sonst bei GSM in einem Radiolautsprecher typischen Geräusche, wenn ein Handy sich ins Netz einbucht, fehlen in diesem Fall gänzlich. Konkret sind mit mehreren Yesss-SIM Serie 89431215071000XXXXX mit einer Olympia Protect 9061 (5943 rev.03) diese Anomalien zu beobachten gewesen, während folgende Serien funktionieren:
89431215050304XXXXX
89431214093005XXXXX
89431214093005XXXXX
Spannend…
Willkommen auf grundsoli(.)de!
Hier befassen wir uns mit Reviews von IT- und Telekommunikationsprodukten, Security Audits, OpenSource und Sparangeboten. Wenn ich einem Thema begegne, das mich bewegt, schreibe ich einfach einmal meine Gedanken hier nieder und nehme Feedback entgegen. Betrachten wir es als öffentlich einsehbares Notizbuch, das auch dem Leser punktuell grundsolides IT-Wissen vermitteln und andererseits eine Entscheidungshilfe sein soll. Die Beiträge werden, soweit es für das deutschsprachige Publikum dieses Blogs von Interesse ist, mit https://technicalexperiments.wordpress.com abgestimmt.
Es ist geplant, die geringen Kosten des Betriebs dieses Blogs durch Werbeeinnahmen zu decken. Auf Werbung wird auch als solche hingewiesen werden. Soweit jedoch ein Artikel Produkte behandelt , die auf Amazon.de erhältlich sind, werden diese auch verlinkt. Ungeachtet dessen wird die Kritik schonungslos sein, denn meine Leser möchte ich ja nun wirklich nicht vergrämen.
Wir starten am heutigen 30. November 2018.
In diesem Sinne, herzlich willkommen!