Frage zu Subdomains im CCP

    Hi,

    ich habe eine .de Domain so gekauft und nutze die bis lang für Dyndns - also zeigt de * und der @ A Record auf meine heimische IP.

    Habe dann nun einen vps piko ergattern können und wollte eine "vps" subdomain anlegen - dort einen A Record mit der IP des vps gemacht, aber selbst nach ein paar Stunden zeigt die Domain weiterhin auf die heimische.

    Hab ich da einen Denkfehler oder muss ich einfach noch länger warten bis die Umstellung durch ist?


    Edit: Hab mal einen Screenshot angehangen - bewusst bei den IPs abgeschnitten

    Das sollte normalerweise recht flott gehen. Was hast du denn eingetragen? A-Record mit Host vps und der IP des vps piko, ggf das selbe mit AAAA. Sonst könnte es passieren, dass ein eventueller Wildcard AAAA-Record dazu führt, dass eben auf dessen IP zugegriffen wird, wenn für vps kein AAAA eingetragen ist. Normalerweise wird ja IPv6 bevorzugt verwendet bzw zuerst versucht.

    Edit: Nein, wüde nicht passieren, da durch den A-Record für den Host vps en Wildcard-Eintrag für diesen Host nicht mehr berücksichtigt würde.

    Einmal editiert, zuletzt von tab (12. Oktober 2025 um 20:20)

    Der Screenshot zeigt leider nicht, ob die Einträge gültig sind und welche TTL (Zeit bis zum nächsten Refresh/Neuabfrage der DNS-Server) dort eingetragen ist. Der wahrscheinlichste Grund, warum lokal keine Änderung sichtbar ist, ist ein existierender Cache-Eintrag. Also entweder lokale Caches löschen, für Experimente die TTL reduzieren (1h ist immer problemlos möglich), und/oder sicherstellen, dass für Tests keine Caches im Wege stehen wie hier: https://dnschecker.org/

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    2 Mal editiert, zuletzt von m_ueberall (12. Oktober 2025 um 20:18)

    Zitat von sirana

    TTL Also auf 1h runter - vermutlich in Sekunden also 3600?

    Ja; die TTL kann kurzfristig auch auf 300s (Minimum liegt je nach Anbieter bei 30s/60s) gesetzt werden – da dies aber eine erhöhte Last für die DNS-Server bedeutet, macht man das (fairerweise für die Allgemeinheit) wirklich nur für Testzwecke. Im ungünstigsten Fall kann eine "zu niedrige" TTL von einem "dazwischenliegenden" DNS-Server, etwa bei einem Provider, auch ignoriert/übersteuert werden. Logischerweise greift die Änderung erst beim nächsten Refresh (weswegen man sie insbesondere beim Umzug/anstehenden IP-Wechsel 24–48h vorher reduziert und nach dem Umzug wieder hochsetzt).

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE

    2 Mal editiert, zuletzt von m_ueberall (12. Oktober 2025 um 20:31)

    Die Einträge sind korrekt.

    Was sagen denn die Nameserver von netcup?
    (Beispiel für Linux)

    Code
    host vps.example.com netcupnameserver.example.com

    Oder ein anderer Nameserver (z.B.: 1.1.1.1, 8.8.8.8, 9.9.9.9)

    Wenn die alle eine falsche IP ausgeben, liegt das Problem bei Netcup.

    (Eintrag löschen und nach 1h Wartezeit neu anlegen sollte dann helfen)

    Bekommst Du eine richtige IP, dann liegt das Problem bei deinen Systemen, die noch die veralteten Informationen im cache haben.

    (FritzBox, Router, Firewall, lokaler DNS-Cache, ... )

    Super Tipp mit den Nameserverv, das kannte ich noch gar nicht...

    Einer der beiden netcup sagt die richtige, der andere die falsche - google und cloudflare sagen die richtige IP.


    Edit: Hat jetzt funktioniert - warten hats wohl dann doch getan am ende :)

    Bei DNS hilft immer ein bisschen Geduld.

    Es ist ein träges System (by Design)

    Deswegen sollte man auch vor wichtigen Unstellungen und Umzügen die TTL vorher reduzieren. Siehe Pots von m_ueberall

    Was ich auch gerne nutze ist mxtoolbox.

    Gibt in dem Supertool einfach folgendes ein:

    Code
    a:sub.domain.tld:all

    a: für A Record

    deine Domain

    :all für frage alle Nameserver der Ressource.

    Das zeigt ob eine Änderung auch bereits über alle deine Nameserver propagiert ist.