Es funktioniert!
Ich habe mich an den Support gewandt. Der hat sich schnell gemeldet und den VPS mit mit dem Rettungssystem getestet, indem er dort meine IPv6 -Adresse dort konfiguriert hatte. Alles war OK. Der Fehler muss bei mir liegen.
Aber nachdem mein System wieder gestartet war, funktionierte dies auch, ohne dass ich etwas geändert hatte.
Die Frage ist ja, warum funktionieren einige Seiten und andere nicht? Wie weit kommen denn die Traceroutes auf z.B. Heise oder Google?
root@vps:~# traceroute6 google.de
traceroute to google.de (2a00:1450:4001:813::2003), 30 hops max, 80 byte packets
1 2a03:4000:37::2 (2a03:4000:37::2) 0.494 ms 0.475 ms 0.458 ms
2 2a00:11c0:47:3::32 (2a00:11c0:47:3::32) 0.543 ms 0.531 ms 0.527 ms
3 * * *
4 * * *root@vps:~# traceroute6 heise.de
traceroute to heise.de (2a02:2e0:3fe:1001:302::), 30 hops max, 80 byte packets
1 2a03:4000:37::2 (2a03:4000:37::2) 0.406 ms 0.376 ms 0.356 ms
2 2a00:11c0:47:3::32 (2a00:11c0:47:3::32) 0.553 ms 0.562 ms 0.591 ms
3 * * *
4 * * *
5 * * *
6 * * *root@vps:~# traceroute6 he.net
traceroute to he.net (2001:470:0:503::2), 30 hops max, 80 byte packets
1 2a03:4000:37::2 (2a03:4000:37::2) 0.271 ms 0.257 ms 0.243 ms
2 2a00:11c0:47:3::32 (2a00:11c0:47:3::32) 0.454 ms 0.444 ms 0.815 ms
3 2a00:11c0:47:1:47::212 (2a00:11c0:47:1:47::212) 21.732 ms * *
4 amsix-200gbps.core1.ams1.he.net (2001:7f8:1::a500:6939:1) 22.278 ms * *
5 * * *
6 * e0-33.core2.dub1.he.net (2001:470:0:410::2) 129.181 ms *
7 * * *
8 100ge4-2.core1.nyc4.he.net (2001:470:0:20a::1) 94.295 ms 94.319 ms *
9 e0-33.core2.dub1.he.net (2001:470:0:410::2) 30.167 ms 100ge8-1.core1.sjc2.he.net (2001:470:0:296::2) 155.831 ms 155.874 ms
10 100ge5-2.core1.nyc5.he.net (2001:470:0:440::1) 89.763 ms 100ge8-2.core3.fmt1.he.net (2001:470:0:1a7::1) 156.099 ms 100ge5-2.core1.nyc5.he.net (2001:470:0:440::1) 89.774 ms
11 100ge8-1.core1.sjc2.he.net (2001:470:0:296::2) 167.303 ms * *
12 100ge8-1.core1.sjc2.he.net (2001:470:0:296::2) 149.663 ms 150.428 ms *
13 * 100ge8-2.core3.fmt1.he.net (2001:470:0:1a7::1) 151.064 ms *
14 * * *
15 * * *
16 * * *
17 * * *Einen Konfigurationsfehler können wir alle nicht finden. Alle sieht auf meiner Seite bisher OK aus und sollte eigentlich funktionieren.
Womit wir wieder bei meiner ursprünglichen Frage sind:
kann es sein, dass es im Netcup-Netz ein Routing-Problem bei IPv6 gibt?
Ein Fall für den Support?
Hast du danach den Server neu gestartet?
Kein reboot. Heruntergefahren und dann über SCP wieder eingeschaltet. So irgendwo in der Anleitung oder Wiki gelesen.
Das meiste was ich da sehe ist völlig normal, auch das FAILED bei ip -6 neigh. Das einzige, was auf einem Fehler hindeutet, ist, dass du schreibst, du kannst gewisse Seiten nicht erreichen.
Danke.
Im Prinzip kann ich keine Seite außerhalb erreichen. Die he Adresse war die einzige, die ich per Zufall gefunden hatte, die klappt.
Ich sehe he.net in deinen Angaben. Nutzt du den Tunnel von denen? Geht da beim Routing was schief?
Das hat mich in der Tat auch verwirrt. Der VPS ist nur an das von Netcup zugewiesene IPv4 und IPv6 Netzwerk angeschlossen. Es ist handelt sich nicht um eine vorkonfigurierte Netcup ISO. Es ist die 3CX PBX ISO mit Debian als Grundsystem. IPv4 funktionierte auf Anhieb über DHCP. IPv6 habe ich wie oben beschrieben manuell konfiguriert.
Verwirrt war ich, weil ich in meinem Netzwerk tatsächlich einen HE-Tunnel habe. Die Tests oben wurden aber direkt auf einer ssh Konsole (putty) am VPS durchgeführt. Der dazu verwendete Rechner hat nur IPv4. Kann also keinen Einfluss auf die Konfiguration am VPS haben.
Dein Interface heißt ens3 und nicht eth0, richtig?
Richtig.
Korrigiert. Da bringt aber nicht den erhofften Erfolg.
net.ipv6.conf.ens3.accept_ra=0
net.ipv6.conf.ens3.autoconf=0Hallo,
kann es sein, dass es im Netcup-Netz ein Routing-Problem bei IPv6 gibt?
Jedenfalls kann ich mir das Verhalten bei meinem VPS 200 G8 mit Debian 10 nicht anders erklären. Es ist nicht so, dass gar nichts geht. Einige IPv6-Verbindungen gehen. IPv4 funktioniert ohne Probleme.
root@vps:~# ip -6 neigh
2a03:4000:37::2 dev ens3 FAILED
fe80::22d8:b00:99fa:424c dev ens3 lladdr 10:0e:7e:26:f1:c0 router STALE
fe80::1 dev ens3 lladdr 00:00:5e:00:02:02 router STALEroot@vps:~# traceroute6 mx.xyz.de
traceroute to mx.xyz.de (2001:470:xxx:xxxx::yyyy), 30 hops max, 80 byte packets
1 2a03:4000:37::2 (2a03:4000:37::2) 0.282 ms 0.269 ms 0.258 ms
2 2a00:11c0:47:3::32 (2a00:11c0:47:3::32) 0.402 ms 0.388 ms 0.475 ms
3 * * 2a00:11c0:47:1:47::212 (2a00:11c0:47:1:47::212) 75.856 ms
4 * * *
5 * * *
6 e0-33.core2.dub1.he.net (2001:470:0:410::2) 36.483 ms * *
7 * * 100ge5-2.core1.nyc5.he.net (2001:470:0:440::1) 95.798 ms
8 100ge4-2.core1.nyc4.he.net (2001:470:0:20a::1) 95.817 ms * 94.177 ms
9 100ge2-1.core2.chi1.he.net (2001:470:0:4b8::1) 111.803 ms 110.718 ms 100ge9-1.core2.chi1.he.net (2001:470:0:298::1) 110.736 ms
10 100ge14-2.core1.msp1.he.net (2001:470:0:18e::2) 120.162 ms 120.053 ms *
11 * 100ge11-2.core1.sea1.he.net (2001:470:0:22a::1) 151.213 ms *
12 * * *
13 * * *
14 * * *
15 * * *Meine Konfiguration:
/etc/network/interfaces
# The primary network interface
allow-hotplug ens3
iface ens3 inet dhcp
iface ens3 inet6 static
address 2a03:4000:xxxx:xxxx::yyyy:yyyy:yyyy/64
gateway fe80::1/etc/sysctl.d/50-IPv6.conf
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.eth0.accept_ra=0
net.ipv6.conf.eth0.autoconf=0wäre es möglich, einen zentralen DDNS Dienst zur Verfügung zu stellen, damit sich nicht jeder Kunde selbst etwas basteln muss?
Eine API für DDNS gibt es. Und einige Clients für diese API gibt es auch.
Wenn es kompatibel für gängigen Anwendungen out-of-the-box und ohne Notwendigkeit an technischem Wissen sein soll, dann einfach einen Externen DNS verwenden.
Hier für alle einmal die Antwort vom Support: „Wir haben einen Fehler identifiziert, der vereinzelt und unter bestimmten Bedingungen bei DNSSEC signierten Zonen mit SMIMEA-Records dazu führt, dass diese nicht mehr korrekt auflösen.[...]“
Da ich meinen DNS bereits auf einen externen Server umgezogen habe, war eine Analyse bei mir nicht mehr möglich. Aber ich habe aber vom Support heute die gleiche Bestätigung erhalten.
ZitatUnter bestimmten Umständen kann es bei Zonen, die einen SMIMEA Record beinhalten und mit DNSSEC signiert sind, derzeit vorkommen, dass eine Vielzahl an Records als ungültig markiert wird. Der SMIMEA selbst ist dabei im Regelfall nicht als ungültig markiert und muss dafür auch nicht verändert werden (das Verhalten tritt aber nur unter bestimmten Konditionen auf). Ich gehe davon aus, dass dies in Kürze gelöst sein wird.
Jetzt ist nur noch offen, wann "in Kürze" sein wird?
Fordert ein Beschwerdestellenticket an, wenn Ihr denkt, dass Euer Anliegen nicht hinreichend beachtet wird.
Um keine Missverständnisse in dem vom mir eröffneten Thema zu erzeugen, hier eine Antwort zum Kommentar oben.
Ich kann mich nicht über den Support von Netcup beschweren. In der Vergangenheit hatte ich bei anderen Problemen schnelle Hilfe erhalten. Auch jetzt hat sich der Support bei mir nach zwei Tagen gemeldet. Da ich aber zu diesem Zeitpunkt bereits auf einen externen DNS als Notlösung umgestellt hatte, konnte das Problem bei mir nicht mehr analysiert werden.
Bemängle tue ich das Produkt „Netcup-DNS“. Hier scheint der Wurm drin zu sein. Davon sind laut Meldungen im Forum einige aktuell und auch in der Vergangenheit betroffen.
Mein akutes Problem ist erstmal gelöst. Aber schön ist das sicher nicht.
Problem wieder da! Zu früh gefreut.
Nachdem ich, wie oben beschrieben habe, DNSSEC deaktiviert hatte lief alles wieder nach ein paar Stunden. Gestern, einen Tag später habe ich im CCP nachgesehen und es war noch alles OK. Heute, zwei Tage später wieder Status wie am Angang gepostet: "ungültig". Domain nicht auflösbar, trotz DNSSEC deaktiviert.
Der Support hatte sich bisher nach meiner ersten Meldung noch nicht gemeldet. Aber OK, es lief ja wieder.
Ich habe nun das Backup aktiviert und auf externe DNS umgestellt. Erstmal abwarten, bis Netcup sein System wieder im Griff hat.
Och nöö, ist anscheinend ein bekanntes Problem von Netcup, es hängt mit dem DNSSEC Key zusammen, der plötzlich nicht mehr übereinstimmt.
Siehe Thread
Melde einfach den Fehler bei Support und die korrigieren den DNSSEC Key wieder.
Danke,
Nach Suche im Forum bin ich auch auf den Hinweis mit DNSSEC gestoßen. Bei einem DNS-Test mit mehreren DNS-Server weltweit konnte ich auch feststellen, dass einige die Domain auflösen konnten. Ich habe dann DNSSEC im CCP deaktiviert und ein paar Stunden später wurden die Einträge als gültig angezeigt und die Domain ist wieder auflösbar.
Mein akutes Problem ist erstmal gelöst. Aber schön ist das sicher nicht.
Ganz wichtig!
Die Domain muss vor der Zuordnung ein Netcup DNS zugeordnet sein, also kein externer DNS für diese Domain. Ansonsten hängt das Netcup-System in einer Sachgasse fest und es gibt kein Weg mehr zurück ohne Support. Nachdem die Domainzuordnung abgeschlossen ist, kann auch ein externer DNS-Zugeordnet und verwendet werden.
Ich bin bereits zweimal in diese Falle ohne Ausweg getreten.
Allerdings funktioniert bei mir per se die gesamte DNS-Auflösung nicht richtig.
Bei mir liegt das Problem (vermutlich) an DNSSEC, da wenn ich bei mir lokal zuhause DNSSEC ausschalte, ich die Server wieder erreiche
Problem schon gelöst?
Ich habe bei mir seit gestern ein DNS-Problem mit dem Netcup DNS-Server. Gut zu wissen, dass DNSSEC eine Ursache sein könnte.
Hallo,
seit gestern sind alle meine DNS-Einträge beim Netcup-DNS im CCP als "ungültig" markiert und die Domain ist von außerhalb nicht mehr erreichbar.
Die Domain ist bei Netcup als "zusätzliche Domain" gehostet und einem Webhosting-Paket zugeordnet. DNSEC ist aktiviert. Das Ganze läuft so einiger Zeit ohne Probleme. Gestern habe ich zwei Einträge (OPENDNSKEY, TXT) über das CCP aktualisiert. Die Änderung wurde im CCP als OK bestätigt. Ein Tag später fällt mir auf, dass Mails mich nicht mehr erreichen, weil die Domain nicht mehr auflösbar ist. Alle Änderungen und Aktualisierungsversuche im CCP werden mit OK bestätigt, aber nach einer gewissen Zeit wechselt der Status dann von "unbekannt" zu "ungültig". Auch das Löschen und neu anlegen der Einträge führt zum gleichen Ergebnis.
Hat jemand ähnliche Erfahrung gemacht?
Hier muss wohl der Support ran. Aber wegen Wochenende werde ich erstmal auf einen externen DNS umstellen.
Weise auf gar keinen Fall ein Hosting zu, solange noch die Cloudflare-Nameserver eingestellt sind. Beim Zuweisen stellt netcup nämlich nicht automatisch die Nameserver um, sondern will nur die Records ändern. Das Hosting wartet dann auf die richtigen DNS-Einstellungen, die wegen Cloudflare nicht öffentlich werden können und solange die Zuweisung nicht abgeschlossen ist, können die Nameserver nicht geändert werden, was in einem klassischen Deadlock endet. Ist mir mal passiert und es endete damit, dass der Support manuell die Zuweisung zurücknehmen musste, damit ich wieder die Nameserver ändern konnte.
Vielen Dank für den Tip. Leider zu spät. Ich warte nun auf den Support.
Ich kann also bestätigen, dass es auch heute noch, fast drei Jahre später, keinen Schutz gibt, in diese Falle ohne Ausgang zu laufen.
Microsoft blockt einfach (fast) alles und jeden, je nachdem welches IPv4 Netz der Zufallsgenerator halt gerade mal ausgespuckt hat.
Dieses Gefühl hatte ich auch.
Ich vermute es wurden immer ganze Netzte bei MS gesperrt und nicht einzelne IP. Mein Mailserver is eine privater Mailserver. Da ging sonst nix raus. Und trotzdem landete meine vserver IP (oder das ganze Netz) immer wieder nach Freischaltung auf der Sperrliste.
Mein Konzept sieht ein wenig anders aus.
Mailserver zuhause hinter dynamischer IP empfängt direkt. Der Host-Name wird über den Router im DNS aktualisiert und ist im DNS als mx eingetragen. Die paar Minuten Ausfall während der Aktualisierung stören nicht.
Nur zum Senden verwende ich einen Smarthost. Aktuell über den einen externen Dienst mailjet, früher aber auch über postfix über einen vserver.
Der Vorteil:
- Beim Empfang ein Glied weniger in der Kette, das Fehler verursachen kann
- Die VPN-Verbindung bei dir ist noch ein Glied extra, das Fehler verursachen kann.
Eine Frage.
Ist der Versand über den Netcup vserver stabil? Ich hatte das Problem, dass Microsoft (Outlook, Hotmail) öfters Mails von meiner vserver IP nicht akzeptiert hat.
Vielleicht war meine Frage unklar formuliert.
Ja, die Domain muss von Netcup als registrar verwaltet werden (Das macht das Ganze mittelfristig für mich unattraktiv).
Das war aber nicht der Kern meine Frage. Der Nameserver für die Domain kann auch sonstwo liegen und dann muss der mx Eintrag für den Mailserver händich vorgenommen werden. Hier fehlte mir der korrekte Eintrag.
Mittlerweile bin ich weiter. Ich habe einfach ausprobiert und den angegebenen IMAP und SMTP server als mx eingetragen. Funktioniert!
mx für SOGo ist somit: [ihre domain.tld].netcup-mail.de.
Hallo,
welchen mx Record muss ich bei SOGo Groupware im DNS zu meiner Domain einstellen?
DNS ist nicht von Netcup verwaltet, deshalb muss ich es manuell in meinem DNS-Server einstellen.
Ich den Anleitungen und hier im Forum bin ich noch nicht fündig geworden.
Danke.
