Nicht lange genug gewartet oder tatsächlich den Record nicht gesetzt?
error: one or more domains had a problem:\n[nginx.mydomain.at] propagation: time limit exceeded: last error: authoritative nameservers: NS third-dns.netcup.net.:53 did not return the expected TXT record
Schau mal in den DNS-Einstellungen der Domain, was da gesetzt ist. Es kann z.B. auch daran liegen, dass zu viele TXT-Records existieren, vielleicht von vorherigen gescheiterten Versuchen, die dann nicht wieder gelöscht wurden.
Ich hatte mal eine .EU Domäne aus einer Netcup-Aktion mit einer laut RFC max. TTL. von 7 Tagen "geparkt", und hatte sie dann aber in wenigen Stunden "zurück", als ich dann irgendwann doch recht spontan Änderungen machen wollte...
Der autoritative Server muss nicht auf irgendwelche TTLs warten. Sobald der die Zone neu lädt, gilt die. Netcup aktualisiert die Zonen alle 10 Minuten, deshalb ist hier eine kürzere TTL als 300s selten sinnvoll. Schneller kann man im Mittel sowieso nichts ändern. Aber die TTL gilt nicht nur für den Nameserver, den du fragst, sondern auch für alle anderen, die du nicht mal kennst. Deswegen kann es immer noch zu DNS-Problemen kommen, auch wenn du schon lange denkst, die Domain ist wieder zurück. Vor Änderungen setzt man die TTL deshalb rechtzeitig* runter, wenn man nicht für längere Zeit Anfragen an die neue und die alte Konfiguration bearbeiten will oder kann. Für eine geparkte Domain kann einem das aber wahrscheinlich egal sein, solange man nicht erwartet, dass die nach der Umstellung für alle sofort erreichbar ist.
*) rechtzeitig heißt so lange wie die alte TTL
irgendwas.dedyn.io -> A-Record mit der IP deines Servers, per Dyndns-Client aktuell halten.
_minecraft._tcp unter deiner Domain bei Netcup -> SRV Record mit Port des Servers und Hostname bei Desec.
Bitte versuche, etwas aufmerksamer zu lesen. Geh vielleicht auch nochmal im Text zurück, wenn etwas unklar ist. Du redest hier nicht mit einer Maschine.
Wenn du in dem bestehenden Account nicht wie beschrieben mit dem gelben Plus rechts oben eine dedyn.io Subdomain hinzufügen kannst, dann lösch den Account und mach einen neuen, ja.
Wenn du dich bei Desec anmeldest, bekommst du diese Auswahl, wo du deine gewünschte Subdomain direkt anlegen kannst:
Wenn du den Account ohne Domain erstellt hast, kannst du die Domain über das gelbe + rechts oben hinzufügen und dann den kompletten gewünschten Domainnamen angeben, also mit angehängtem .dedyn.io.
Den denkst du dir aus und legst ihn bei Desec an. Desec vergibt Domainnamen unter dedyn.io. Wichtig: Wenn du den Domainnamen hinzufügst, musst du den kompletten Namen eingeben, nicht nur die Subdomain, sonst bekommst du eine verwirrende Fehlermeldung. Also Beispiel: Du möchtest wallbreaker.dedyn.io verwenden. Dann fügst du genau das in deinem Desec Account als Domain hinzu. Wenn du mehr Hostnamen brauchst, kannst du Subdomains von deiner dedyn.io Subdomain anlegen.
SRV-Record nicht zwingend notwendig
Der SRV-Record ermöglicht zusätzlich zur Port-Angabe, die Hauptdomain zu verwenden, wenn die IP-Adresse dynamisch ist und der DynDNS Dienst nicht über die Netcup-API realisiert wird, wovon ich hier mal schwer ausgehe. Mit einem CNAME geht das nicht, weil CNAMEs im Zone-Apex nicht erlaubt sind und Netcup kein CNAME flattening unterstützt. Der SRV-Record ist wirklich kein Akt und wenn man es schon mit einem Protokoll zu tun hat, das SRV untersützt, dann sollte man das nutzen. Spätestens wenn man einen zweiten Server für Testzwecke auf der selben IPv4-Adresse laufen lassen will, kommt man sowieso nicht drum herum.
Du brauchst einen SRV Record:
Host: _minecraft._tcp.subdomain
Type: SRV
Target: 0 0 Port Domainname
Wenn du den Server direkt über deine Hauptdomain aufrufen willst, lässt du .subdomain weg. Sonst kannst du dir da einen Namen ausdenken und den Server dann als subdomain.deinedomain.example öffnen. Port ist die Portnummer und Domainname ist der Hostname deines Servers, für den ein A oder ein AAAA Record existieren muss, der die IP-Adresse deines Servers enthält. Wenn du das mit einer statischen IP Adresse machst, legst du dir einen weiteren Record an:
Host: meincraft
Type: A
Target: IPv4-Adresse
Mit dem Standardport wäre dann dein SRV-Record-Target 0 0 25565 meincraft.deinedomain.example. Für dynamische IP-Adressen machst du dir einen Dynamic-DNS Account bei Desec und nimmst statt meincraft.deinedomain.example deinen Hostnamen dort, also irgendwas.dedyn.io, und sorgst dafür, dass die IP-Adresse für diesen Hostnamen immer aktuell ist.
(Die beiden Nullen im SRV Record sind Priorität und Gewicht und brauchen dich erstmal nicht zu interessieren.)
Du musst dich um DNSSEC gar nicht kümmern. Du kannst zwar deine Domain bei Desec hosten, aber das ist nicht notwendig. Wenn du Desec als Dynamic-DNS Dienst nutzt, mit einer Domain unter dedyn.io, dann kannst du mit einem SRV-Record bei Netcup, mit oder ohne DNSSEC, auf deinen dedyn.io Namen verweisen. Die Dienste sind im Prinzip völlig voneinander getrennt und Desec muss von der Netcup-Domain gar nichts wissen.
Die IP steht in der Domain bei Desec. Wenn du keine feste IP-Adresse hast, wirst du die dort mit einem DynDNS Client updaten müssen, wann immer sich deine Adresse ändert. Wenn du eine feste IP-Adresse hast, kannst du dir Desec komplett sparen und einen Hostnamen mit der Adresse bei Netcup anlegen, z.B. meincraft.deinedomain.example, wenn deinedomain.example deine Domain ist.
Den SRV-Record legst du trotzdem an, denn das ist die Methode, um die Portnummer im DNS abzulegen. Das geht nur mit einem A/AAAA-Record nicht.
Du brauchst (wahrscheinlich) einen Dynamic DNS Dienst, wenn dein Server eine dynamische IP-Adresse hat. Der ist bei Netcup nicht inklusive. Du würdest ein Webhostingpaket oder einen Server dafür brauchen. Glücklicherweise kannst du aber auch irgendeinen der unzähligen kostenlosen Dienste verwenden. Zu empfehlen ist Desec.io, wo du eine kostenlose Subdomain unter dedyn.io bekommst.
Der zweite Teil ist, dass Minecraft zu den Protokollen gehört, die SRV-Records unterstützen. Du kannst also den Hostnamen und die Portnummer im DNS hinterlegen. Die DNS-Einstellungen findest du im CustomerControlPanel. Den SRV-Record lässt du auf deinen dedyn.io Namen und den Port, den du dir für den Server ausgesucht hast, zeigen. Der Name ("Host"), den du dafür im DNS hinterlegst, ist _minecraft._tcp. Der "Host" ist nur die Subdomain unter deiner Domain, also nicht deine Domain nochmal anhängen. Die Verbindung wird dann ohne diesen Namen gemacht. Das heißt, mit dem SRV-Record auf _minecraft._tcp.deinedomain.example legst du fest, wohin sich Minecraft per TCP für deinedomain.example verbindet.
Können wir Netcup ein wenig mehr zutrauen, als was ich auf einem Handy aus diesem Jahrzehnt hosten könnte? Wozu benutzt man denn sonst einen Webhoster, wenn so eine Amateuranforderung nicht sicher zu erledigen wäre?
ein CDN, wie Cloudflare vor die Seite zu schalten
Wenn der Netcup-Webserver es nicht schafft, durchschnittlich 15Mbit/s (160GB/24h) mit statischen Dateien zu füllen, ist vielleicht Self-Hosting auf einem DSL-Anschluss eine Alternative?
dann geh doch
Die kritikunfähige Charakterlosigkeit erwarte ich von frank_m, aber das scheint hier doch verbreiteter zu sein.
ich korrigier das für Dich
Was soll das Shitposting? Wenn man nicht die drei Zeilen lesen kann, kann man auch einfach nicht antworten. Und dass ich geschrieben habe, dass ich mich nicht in der Pflicht sehe, eine andere als die von mir vorgeschlagene Lösung zu supporten, heißt nicht, dass ihr jetzt sinnlos "IPv6 toll, du blöd, RTFM" raushängen lassen sollt. Was ist das für eine besch... Community hier.
Kann bitte jemand anders die LLMs trainieren? Meine Bereitschaft, hier noch jemandem zu helfen, ist mittlerweile Null. Huldigt eurem schönen Protokoll. Den Palaver könnt ihr noch viele Jahre machen. Ihr schadet damit eher eurer Sache, aber wenn's Spaß macht...
Angenommen Kunde X hat bei Anbieter A ein /27 IPv4 Subnetz
Vielleicht verstehe ich völlig falsch, was ein Forum ist, aber ich hatte den Eindruck, dass es um eine konkrete Problemstellung geht und nicht um hypothetische Anbieter mit hypothetischen Kunden, die ohne rudimentäre IP-Kenntnisse Server mit 32 Adressen buchen.
Aber das von dir genannte Beispiel ist nur ein Einzelfall und kein Grund generell von IPv6 abzuraten.
Ich habe nicht generell von IPv6 abgeraten, sondern empfohlen, dass der konkrete Mensch mit dem Problem AAAA-Records rausnehmen soll, bis er genug von IPv6 versteht, dass er die IPv6-Adresse findet, die er da eintragen muss. Und ich habe (begründet!) erklärt, dass das keine nennenswerten Nachteile bringt, damit er sich nicht einreden lässt, etwas zu konfigurieren, was er nicht überschaut. Er konkret, mit seinem konkreten Problem, in einem Forum.
Du scheinst dich ja auch in der Materie auszukennen. Was hat dich daran gehindert ihm Hilfestellung anzubieten?
Ich habe die nach meiner Meinung sinnvolle Lösung gegeben, und sie hat funktioniert. Wer dagegen etwas hat, ist in der Bringschuld, nicht ich.
Möchtest du allen ernstes damit vermitteln dass das ein IPv6 Problem ist?
Der Grund für das Problem liegt in einem Unterschied zwischen IPv4 und IPv6. Für IPv4 ist die Adresse im ServerControlPanel angegeben. Aufgrund der Eigenheiten von IPv6 ist dafür nur das Präfix im ServerControlPanel zu finden. Für IPv4 muss er vor der DNS-Anpassung nur dort nachschauen. Für IPv6 reicht das nicht, und damit war er überfordert und hat mehrere Tage mit der Fehlersuche verbracht. Ich habe grundsätzlich angegeben, was zu tun wäre, und dann dazu geraten, die AAAA-Records zu entfernen, bis er diesen elementaren Schritt nachvollziehen kann. Ich halte das nach wie vor für die korrekte Empfehlung.
fange ich an, dir zu glauben.
Es gibt nichts, was mir mehr egal wäre.
"v4 tuts auch" ohne konkreten Grund
Keine Ahnung, wie man argumentieren muss, um rüberzubringen, dass "ich habe das Präfix in den AAAA Record geschrieben, weil ich nicht weiß, was das ist, und tagelang nach dem Fehler gesucht und nichts gefunden" ein konkreter Grund ist. Bist du sicher, dass sein Server das Spiel um IPv6 entscheiden wird? Und wenn er dann zurück kommt und sagt, er hat das Zertifikat, jetzt können wir es nochmal mit AAAA-Records versuchen, dann ist keiner da, der es erklärt. Am Ende schreibt ihm ein LLM den Netplan, er postet seine Adresse praktisch unzensiert, obwohl er das nicht wollte, kann nicht erkennen, ob sein Server funktioniert, bis Letsencrypt ihm Bescheid gibt, und das ist dann besser als "keine AAAA-Records, bis du weißt, wie IPv6 funktioniert"?
Mit solch einer würzigen Aussage (insbesondere die zwei letzten Sätze) sinkt die Antwortbereitschaft direkt.
Wenn ich tatsächlich die Antwortbereitschaft der Leute senken könnte, die über jede funktionierende Lösung hereinbrechen, die IPv6 in irgendeiner Weise nicht vollumfänglich gleichstellt, nur um irgendwelche Allgemeinplätze über IPv6-Notwendigkeit zu verbreiten und jeden praktischen Aspekt zu ignorieren, würde mich das sehr freuen. Leider ist Argumentation nur Perlen vor die Säue.
Schau dir mal diese Seite an: https://radar.cloudflare.com/de-de/reports/ipv6
Das ist Request-Traffic von Cloudflare. So sieht die Welt wirklich aus. Browser bevorzugen IPv6, wenn es funktioniert. Wenn da IPv4 verwendet wird, hat das also Gründe. Noch eine andere Karte, IPv6-capable laut APNIC: https://stats.labs.apnic.net/ipv6
Ein IPv4-only Client ist leicht eingeschränkt, wenn er keine IPv6 Hosts erreichen kann, was der Normalfall ist. Ein IPv6-only Client ohne die Möglichkeit, IPv4-Hosts zu erreichen, ist dagegen praktisch unbenutzbar, und ich betone nochmal, wer das nicht glaubt, hat es nicht probiert. Ich habe es probiert. Das wird entgegen anderslautenden Behauptungen auch nirgendwo kommerziell angeboten, für Clients (Eyeball-Netze) wohlgemerkt, schon gar nicht in Europa. Aber auch das japanische Hotel befindet sich in einem Land mit unter einem Drittel IPv6-Request-Traffic zu Cloudflare. Deutlich über ein Drittel dort ist nichtmal in der Lage, einen IPv6 Host zu erreichen (nicht IPv6-capable). Dreimal darfst du raten, ob Japaner IPv4-Hosts erreichen können oder nicht, und wie die korrekte Bezeichnung dafür ist, wenn jemand behauptet, sie könnten das nicht.
Weil der Betrieb eines IPv6-only Clients nicht praktikabel ist und das praktisch niemand macht, der nicht genau weiß, was er tut, ist es nicht notwendig, als Serverbetreiber Dienste über IPv6 anzubieten. Es ist nicht verboten und ich habe auch nicht geschrieben, dass man das auf gar keinen Fall tun soll. Aber die Liste der Domains, die in der einen oder anderen Weise IPv6 nicht unterstützen, ist lang und voll von Domains, die jeder kennt. Schonmal DuckDuckGo benutzt? IPv4-only. Selbst Google, einer der verbissensten IPv6-Befürworter, schreibt, "Für den nächsten Schritt der Umstellung auf IPv6 und die Bereitstellung von Nur-IPv6-Netzwerken müssen Netzwerkbetreiber weiterhin Zugriff auf Nur-IPv4-Netzwerke und -Dienste haben." Das bedeutet im Umkehrschluss, wenn alle Zugriff auf nur-IPv4-Netzwerke haben, dann kommt man als Serverbetreiber auch ohne IPv6 zurecht. Nochmal, dass heißt nicht, dass das die Idealsituation ist oder dass man IPv6 meiden sollte, aber unter Berücksichtigung der Umstände ist das eine Möglichkeit, die durchaus Probleme lösen kann.
Aber weil ein paar Leute nicht ertragen können, dass ein Server ohne IPv6 das tut, wofür er gebraucht wird, wird hier jemandem, der ein Präfix nicht von einer Adresse unterscheiden kann und sich die Konfiguration von einem LLM schreiben lässt, eingeredet, IPv6 wäre notwendig. Wenn es dann daran geht, das praktisch umzusetzen, ist Schweigen im Wald. Wie das bei Kulten so ist, wird aber jede Äußerung gegen "ohne IPv6 geht gar nicht" verspottet und jede noch so unsubstantiierte Äußerung in Richtung "Mach IPv6!" bejubelt. Das ist erbärmlich.
