Ach, Blödsinn. Es hat doch jeder Supermarkt jetzt so hochauflösende HD-Kameras in kassennähe, da braucht der Filialleiter Björn Harste nur mal schnell am Handy die Überwachungsvideos ansehen und die Diskussion ist nach 30 Sekunden beendet!!!!1111elf
Hat der von Dir bevorzugte Schuhversandhändler, der als einziger die olympische Schuhgröße führt, die Du brauchst, Dich wieder mit speziellen Werbeangeboten zugemüllt, oder bist Du aus einem anderen Grund so mies drauf?! 
....und nicht nur die!
Wenn Du uns verraten hättest, um welche TLD es gegangen ist, hätten wir präzisere Infos beschaffen können.
Ich zum Beispiel ziehe gerade eine .org von einem Anbieter zum anderen um. (Beide Anbieter sind nicht netcup). Da der abgebende Provider kein Approve sendet, sondern nur ein Deny zulässt, muss ich gerade den 5. Tag warten. Dann irgendwann, wenn diese 5 Tage in ein paar Minuten um sein werden, wird der Umzug innerhalb von 48 Stunden passieren. Eine Neuregistrierung, das ist klar, startet ab dem Bezahlvorgang und ist beim nächsten Nameserver-Reload schon aktiv.
Ein „Umzug“ (Transfer), ist es immer dann, wenn ich die Domain, um die es geht, schon habe, aber den Registrar wechseln möchte. Also etwa, weil der andere billiger ist, oder andere Features oder ein besseres selfcare tool hat, oder ich eine Domain von jemandem erworben habe, der einen anderen Provider hat, mit dem ich nicht kontrahieren möchte, etwa wegen seiner AGB - oder wie in Deinem Fall, wo der Registrar allem Anschein nach den Laden dicht macht.
Ein Transfer ist je nach dem Umfang der Dienste, die schon unter der Domain erreichbar sind, auch als Migration zu sehen und ist auch als solche zu planen.
Ich verstehe ja, dass beim „Abtauchen“ Deines bisherigen Providers Not am Mann war - aber irgendwoher musst Du ja auch den Authcode bekommen haben, ohne dabei die Registry einzuschalten, oder? Also so dringend kann es nicht gewesen sein, und die paar Stunden Wartezeit zur weiteren Informationsbeschaffung hätten Dir einen Großteil dieser Aufregung und die Kosten der neuen Domain vermutlich erspart, wenn ich das noch anmerken darf.
BTW: ein Freund hat kürzlich auch eine (.org) Domain transferiert u.z. zu einem nicht ICANN-akkredierten Provider außerhalb der EU. Herausgekommen ist ein Schlichtungsverfahren, denn der angebliche Provider hat sich die Domain gekrallt und weiterverkauft... Seid wachsam!
Keine Ahnung warum es bei einer neuen Domain so viel schneller geht.
Weil die vorher noch nicht existiert hat, wird sie nach Bezahlung automatisiert in den Root-Nameservern eingetragen. Und, weil sie vorher noch nicht existiert hat, können auch keine veralteten Zonendaten im Internet herumlungern. Und das ist bei jeder TLD im Grunde so. Darum.
Beim Transfer wird teils automatisiert, teils manuell u.z. je nach TLD zunächst ein Prozedere abgespult - Anforderung-Bestätigung durch Authcode; Anforderung mit Authcode-Widerspruchs-Wartezeit, etc, etc. Dann werden die Zonen bei Annehmenden erstellt, sind aber bis zum Ablauf der etwaigen Wartezeit und bis Root-NS-Reload nicht autoritativ. Und wenn sie dann autoritativ sind, geistern eben noch die alten DNS-Datensätze herum, je nachdem, was in der Zone eingestellt war und je nachdem, ob der Caching-DNS-Resolver die Standards respektiert oder nicht.
ich hätt eher Sorgen, daß meine Geldbörse zu sehr kupferhaltig würde;
Die Methode bewirkt weniger, dass das Wechselgeld auf den nächsthöheren Betrag nicht stimmt, als vielmehr, dass es zu Irrtümern bei den Scheinchen kommen kann. Bsp: Rechnungsbetrag 14,99 - das Display sagt vorsorglich 0,01, aber der Kunde zahlt mit einem 20er und nicht mit 15 Euro in Scheinen. Fünfer und 20er sind beide etwas bläulich, und der Irrtum ist schon passiert. Auf der Rechnung steht es nicht, denn eingegeben wurde es ja nicht - jetzt beginnt das Diskutieren an der Kassa. Aus 15 Sekunden Bezahlvorgang an der Kassa werden nun 15 Minuten mit dem Filial-/Teamleiter. Sehr effizient!
Mal blind geraten: Es funktioniert jetzt? Jaja, die Caches, immer wieder die Caches...
Die Ungeduld ist echt ein Hund.
FORTRAN bekommste noch weniger tot
Ah, Du hast ihn gelesen 
Der Geschwindigkeitsboost ist mal sowas von derb, also das hätte ich nicht erwartet.
Echt nicht?
H6G : Der Artikel ist was für Dich, oder? https://www.heise.de/developer/meld…st-4518334.html
Irgendwie ist der Adventkalender nach dem Site-Relaunch noch nicht fit: https://www.netcup.de/adventskalender/index.php und https://www.netcup.de/adventskalender/ue18.php sind noch ... kaputt.
Wieso? Wurdest du verhaftet wegen deiner API?
Vielleicht ist's ja eine Zeitreise-API?
Weil ich gerade einen Kommentar auf meinem Blog sehe - Fritzbox... vermutlich wird das Folgende nicht mehr funktionieren, oder?
Da einige Fragen zum Transfer ein Dauerbrenner sind, habe ich ein paar dieser Sachen zusammengefasst. Verbesserungsvorschläge sind willkommen:
Nur zur Info: Es ist nicht meine erste Domain, die ich anmelde (seit 2001). Das lief ansonsten sehr flott innert 1-4 Stunden. An gleichem Standort, wie jetzt auch.
Es ist allerdings mein erster Umzug und ich bin überrascht über den Umstand, daß da andere 'Naturgewalten' im Weg stehen.
Was der „gleiche Standort“ mit der Domain zu tun haben soll, musst Du mir Unwissendem, der ich ab 1998 im ISP-Business tätig war und DNS-Admin gemacht habe, bitte noch erklären - und seit 2001 gibt hat sich auch in der Domainwelt so Einiges organisatorisch und technisch getan - auch hängt es von der Registry und vom abgebenden Provider und den Caches der Provider Deiner Besucher ab, wie aktuell die ausgelieferte Domaindaten sind. Hinzu kommt, dass heute auch die Webbrowser und nicht nur das Betriebssystem einen eigenen DNS Cache vorhalten - auch den kann man löschen: https://techwiser.com/clear-dns-cache-on-browser/
Wenn Dein Domainregristrar zugleich Dein Provider ist, und/oder die Domaindaten nicht gecacht sind, sind die 1-4 Stunden realistisch - je nach Reload-Times der Registry. Wenn Du eine .org-Domain transferierst, dauert allein der Transfer zumeist 7 Tage, weil eine fünf-tägige Widerspruchsfrist für den abgebenden Provider besteht, während der Du beim alten Registrar klebst.
Soweit es die Google DNS Server betrifft, kann man deren Cache zentral für alle Nutzer leeren:
https://developers.google.com/speed/public-dns/cache
Bei Cloudflare geht das so:
https://cloudflare-dns.com/purge-cache/?_…2401.1554331447
Und bei OpenDNS ist das:
https://cachecheck.opendns.com/
OpenDNS beschreibt noch, wie man auf Endgeräten den lokalen Cache löschen kann:
https://support.opendns.com/hc/en-us/artic…-the-DNS-Cache-
Bei einzelnen Providern kann man versuchen, das Cache Flushing als Ticket einzureichen. Das dauert wohl aber länger als die (je nach Domain eingestellten) 48 Stunden (TTL), nach denen das automatisch passiert.
Es besteht wirklich keinerlei Veranlassung eine neue Domain zu registrieren, nur, weil man sich nicht vorher über die -für alle Provider im Grunde gleiche- Funktionsweise des Domain Name Service informiert hat. Vor allem würde es auch eine gewisse (meist sehr viel längere) Zeit als die 48 Stunden dauern, bis die neue Domain dann auch in Suchmaschinen zu finden wäre.
Ein Domaintransfer nur wegen eines vorübergehenden Problems bei einem Hoster zu machen, ist -Pardon, wenn das hart klingen mag- fast immer eine völlig sinnlose Kurzschlusshandlung. Und, wenn man es dann -im Einzelfall- sinnvollerweise doch macht, sollte man ein paar Dinge beachten.
Hier werden die Basics zu dem Problematik erklärt:
https://www.customercontrolpanel.de/partnerprogramm.php
„Sollten Sie mehr Einnahmen an Provisionen gemacht haben als Sie uns an Rechnungen zahlen müssen, wird Ihre Rechnungn einen negativen Endbetrag haben.“
Machste michn Rechtschreibprüfung?!
Mein Therapeut bringt es, ich konnte dem Angebot gestern widerstehen.
Es ist keine Kaufsucht, wenn man es wirklich und nutzbringend brauchen kann *duckundwegrenn*
Hi, das habe ich vermutet dass das bei mir etwas anders läuft. Welche Informationen würden denn noch helfen? DNS Eintrag?
Vermutlich ist einfach nur die E-Mailadresse des Empfängers falsch?
Schon über das Webform versucht? https://www.asus.com/support/Produc…orm/?lang=de-de
Ansonsten mach bitte ein Ticket beim Support auf oder erstell einen neuen Thread für Dein Problem. Mit dem DNS Deines Webhostings hat die Sache wohl nichts zu tun.
BTW: ref-Link scheint wieder zu funktionieren.
Hi eripek,
danke für dein Feedback, soweit ich verstanden habe sind aber Routing etc. nicht das Thema sondern die Tatsache das wohl per NDP alle IPs announced werden müssen. Es sind immer wieder die kleinen Unterschiede die bei IPv6 zum stolpern bringen, das ARP hinfällig ist war mir gar nicht bewusst...
Voraussetzung, dass IPv6 im linklokalen Kontext seine IPs und Nachbarn richtig detektiert, ist, dass ICMPv6 durchgelassen wird - das ist nach Deiner Aussage ja der Fall.
https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol
Router Solicitation (Type 133)
Router Advertisement (Type 134)
Neighbor Solicitation (Type 135)
Neighbor Advertisement (Type 136)
Redirect (Type 137)
(alles ICMPv6)
Dass Du gepostet hast, während ich geantwortet habe, habe ich erst jetzt gesehen.
Dass NDP Proxy aktiv sein müsste, halte ich erst einmal für ein Gerücht. Das Routing vom Gateway zum VPS betrifft ja den gesamten Prefix /64, aus dem auch Dein Wireguard schöpft. Die Clients hinter Wireguard haben eine linklokale Adresse und kommunzieren linklokal mit dem Server. Dass hier nur ein „host part“ des Prefix (<=64) zur Verfügung steht, sollte dem keinen Abbruch tun. Sofern Du den Clients eine öffentliche IP und die passende Route einträgst, kann ich keinen Use Case für einen NDP-Proxy erkennen. NDP-Proxying kann man übrigens auch schlicht im Kernel aktivieren: https://sysctl-explorer.net/net/ipv6/proxy_ndp/
Einfaches NDP debuggen geht mit "ip -6 neigh show"
Im Grunde hätte es wohl genügt, entweder manuell Einstellungen zu machen (client: route via lla des VPS/wg0 setzen und öff. IP aus /72 setzen, server: Route zur öff. IP des Clients via dessen lla) oder automatisiert über wg0 mittels radvd und/oder dhcpv6 Routen anzukündigen.
Worin der Unterschied zum /48 bei he.net liegen sollte, ist mir nicht klar, außer, dass dort ein Linknet /64 und ein geroutetes Netz /48 existiert und der Tunnel über SIT realisiert wird, während hier ein natives v6-Netz vorliegt.
Ich habe auch erst überlegt. Aber irgendeinen Einsatzzweck findet sich schon. Bestellung ist raus
Serverhorder aller Nationen, vereinigt Euch!
Also bezüglich Wireguard bin ich noch unerfahren. Zum IPv6-Problem kann ich nur allgemeine Ratschläge geben.
Zunächst sollte über sysctl der Empfang von RA - router advertisements via eth0 unterbunden werden. In der Folge ist die Defaultroute fe80::1 statisch auf eth0 zu setzen. Damit wäre einmal gewährleistet, dass von dieser Seite nichts dazwischenfunkt. Ein Reboot könnte hilfreich sein, wenn das erledigt ist. Ausgehend davon würde ich dann debuggen wie folgt:
Exkurs:
Für den Wireguard-Prefix von /72 gilt im Grunde dass selbe wie für Subnetting bei IPv4. /72 ist spezifischer als /64, daher müsste der VPS als „Inhaber“ des /64 jedenfalls wissen, wie zu routen ist, auch, wenn man keine zusätzlichen Routen setzt.
Voraussetzung, dass IPv6 im linklokalen Kontext seine IPs und Nachbarn richtig detektiert, ist, dass ICMPv6 durchgelassen wird - das ist nach Deiner Aussage ja der Fall.
Debugging:
Meine Vermutung wäre, dass beim Setup des wg0-Interfaces falsche Routen oder eine zweite Default-Route oder dergleichen injiziert werden - oder eben aufgrund von RA schon vorhanden waren.
Ich würde daher an diesem Punkt daher erst einmal die Ausgaben von ip -6 r s vor und nach dem Tunnelaufbau vergleichen.
In weiterer Folge wäre die Erreichbarkeit der lokal anliegenden IPs per Ping zu prüfen. Weiters reduziert sich durch Wg die MTU. Auch hier würde ich erst einmal von außen testen, ob die Reduktion entweder durch Path MTU oder durch PMTUd erkennbar ist. (ping -6 -Mdo -s 1472 [wg-if-ip]). Es müsste der reduzierte Wert von 1420 rückgemeldet werden, respektive bei -s-Parameter 1392 der Traffic unbeanstandet durchgehen.
Für die Clients müsste wg dann, wenn der Tunnel up ist, eine spezifische Route setzen. Die Clients wiederum müssten entweder die öffentliche IP des wg-Partners im /72 oder dessen linklokale Adresse auf wg0 als (default-, wenn aller v6-Traffic darüber laufen soll) Route gesetzt haben.
Wieso das Problem mit einem He-Tunnel nicht auftreten soll, kann ich mir nicht erklären. Ich vermute aber, dass die Route über den He-Tunnel nachrangig (höhere Metrik) behandelt wird, hier also Ursache und Wirkung verwechselt werden.
Vielen Dank für die Hilfe!
You're welcome
