DNS Änderungen ohne Wartezeit

  • Hallo zusammen,


    ich würde gerne die Wartezeiten bei DNS Änderungen abstellen. Wenn sich also z.B. das Ziel eines A Records ändert, dann soll das sofort verfübar sein.


    Aktuell vorhanden:


    Domain "meinedomain.de" bei Netcup (Netcup DNS Server werden genutzt)

    A Record sub1.meinedomain.de => 111.111.111.111

    A Record sub2.meinedomain.de => 222.222.222.222

    usw.


    vServer bei Netcup IP 1.2.3.4


    Meine Idee wäre es nun alle A Records meiner Subdomains auf 1.2.3.4 zeigen zu lassen und von dort dann eine Umleitung auf die eigentlichen Ziele einzurichten.


    Beispiel:


    Ankommend sub1.meinedomain.de auf 1.2.3.4 wird umgeleitet auf 111.111.111.111. Wenn Änderung von 111.111.111.111 nach 123.123.123.123 dann geschieht das auf 1.2.3.4 in nicht im DNS bei Netcup und sollte sofort verfügbar sein.


    Wichtig wäre vielleicht noch, dass es tatsächlich nur eine Umleitung sein soll, also der Traffic soll nicht über 1.2.3.4 laufen.


    Hat jemand von euch eine Idee wie man das realisieren könnte?



    Vielen Dank und Grüße

    Andreas

  • Für „sofort“ wurde DNS nicht designt. Du könntest die TTL sehr niedrig setzen. DynDNS-Anbieter verwenden meistens 60 (eine Minute).

    Die Nameserver von netcup aktualisieren ihr Einträge aber nur alle 10 Minuten.

    Cloudflare hat als Mindest-TTL 120 (2 Minuten) und deSEC 3600 (eine Stunde).

    Eventuell findest du ja noch einen Nameserver-Anbieter, der eine geringere TTL unterstützt. Oder du betreibst selber einen Nameserver und lässt die gewünschten Records per NS-Eintrag auf deinen Nameserver zeigen (so brauchst du nur einen Server und keine zwei), bei dem du dann z.B. 1 als TTL nehmen könntest (0 solltest du nicht nehmen, da 0 nicht im Standard definiert ist und das zu Problemen führen kann).


    Oder du versuchst es mit einem Reverse-Proxy und passt da immer die Zieladresse an.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Like 2 Thanks 1
  • Was ist denn das eigentliche Ziel der Aktion - vielleicht fällt uns eine aber Lösung ein.


    z. B. der von Virinum angesprochene Reverse Proxy - würde der dein Problem beheben?

    [RS] 2000 G9 | 1000 G8 | Cyber Quack

    [VPS] 2x 1000 G9 | 2x 200 G8 | 2x Secret | A | mikro G11s | 4x nano G11s
    [WH] 2x 8000 SE | 4000 SE | 2000 SE

    Like 1
  • Für „sofort“ wurde DNS nicht designt. Du könntest die TTL sehr niedrig setzen. DynDNS-Anbieter verwenden meistens 60 (eine Minute).


    Oder du versuchst es mit einem Reverse-Proxy und passt da immer die Zieladresse an.

    Genau darum geht es, um das "sofort" :)


    Ich würde gerne alle A Records 1 x im Netcup DNS fest einstellen, mit dem Ziel vServer Netcup 1.2.3.4. Auf dem vServer 1.2.3.4 kommt dann z.B. eine Anfrage auf sub1.meinedomain.de an, die dann an das tatsächliche Zielsystem 4.3.2.1 umgeleitet wird. Dabei soll es keine Rolle spielen was an sub1.meinedomain.de erreicht werden soll (HTTP, HTTPS, SSH, RDP....), der vServer soll einfach alle ankommenden Anfragen an sub1.meinedomain.de auf das Zielsystem umleiten.


    Wenn ich nun mal einen Server umziehe, muss ich keine TTL, keine Caches (Pi-Hole, Adguard....) aussitzen, sondern ändere auf dem 1.2.3.4 einfach das Ziel und alle Services sind sofort wieder erreichbar.

  • Ich würde gerne alle A Records 1 x im Netcup DNS fest einstellen, mit dem Ziel vServer Netcup 1.2.3.4. Auf dem vServer 1.2.3.4 kommt dann z.B. eine Anfrage auf sub1.meinedomain.de an, die dann an das tatsächliche Zielsystem 4.3.2.1 umgeleitet wird. Dabei soll es keine Rolle spielen was an sub1.meinedomain.de erreicht werden soll (HTTP, HTTPS, SSH, RDP....), der vServer soll einfach alle ankommenden Anfragen an sub1.meinedomain.de auf das Zielsystem umleiten.

    Das ist AFAIK gar nicht ohne weiteres möglich. Beim Lesen deiner Nachricht dachte ich zuerst an eine Art Portweiterleitung (kann man sich jetzt drüber streiten ob das eine sinnvolle Idee wäre ...) aber diese berücksichtigt ja nicht verschiedene Adressen bei z. B. HTTP/HTTPS.


    Ich würde vorschlagen, dass du entweder einen Reverse Proxy wie oben angesprochen für HTTP/HTTPS verwendest und oder dir einen DNS-Anbieter suchst, der eine geringe TTL von z. B. 60s anbietet. (Das wurde beides ja oben schon erwähnt :-).) Für andere Dienste wie SSH sehe ich das ansonsten nicht als sinnvoll an.


    Und bitte verwende keinen öffentlich erreichbaren RDP-Server, das gibt oft nur Ärger.

  • Ohne jetzt auf Kleinigkeiten rumzureiten, aber Cf kann auch 1 Min.

    Oh, vielen Dank für den Hinweis. :)
    Bin schon länger nicht mehr bei CF und damals war die kleinste TTL ziemlich sicher 120.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Like 1
  • Das geht so wie verlangt nicht. Wenn der DNS-Eintrag auf den VPS zeigt, läuft der Traffic dort auf. Für bestimmte Protokolle gibt es die Möglichkeit, Umleitungen zu realisieren, z.B. HTTP-Redirects. Dann muss der VPS jeweils nur eine kurze Antwort schicken und kann die eigentliche Arbeit und den Datenverkehr einem anderen Server überlassen. Für andere Protokolle, z.B. SSH, gibt es solche Möglichkeiten nicht. Mit einer "Umleitung" durch einen Reverse Proxy laufen die Daten dann komplett durch den VPS.


    Du könntest selbst einen DNS-Server betreiben. Das wäre eine Möglichkeit, die Verzögerung durch die nicht in Echtzeit stattfindenden Updates der DNS-Einträge zu umgehen. Auf einem eigenen Server könntest du auch eine extrem kurze DNS-TTL verwenden. Allerdings gibt es etliche Resolver, die für das Caching Mindestwerte ansetzen und noch kürzere TTLs ignorieren. Eine "sofort"-Lösung ist das also nicht. Wenn du Kontrolle über die Clients hast, kannst du Caching dort unterbinden.

  • Das ist AFAIK gar nicht ohne weiteres möglich. Beim Lesen deiner Nachricht dachte ich zuerst an eine Art Portweiterleitung (kann man sich jetzt drüber streiten ob das eine sinnvolle Idee wäre ...) aber diese berücksichtigt ja nicht verschiedene Adressen bei z. B. HTTP/HTTPS.


    Ich würde vorschlagen, dass du entweder einen Reverse Proxy wie oben angesprochen für HTTP/HTTPS verwendest und oder dir einen DNS-Anbieter suchst, der eine geringe TTL von z. B. 60s anbietet. (Das wurde beides ja oben schon erwähnt :-).) Für andere Dienste wie SSH sehe ich das ansonsten nicht als sinnvoll an.


    Je öfter ich über die Problemstellung schreibe desto mehr dämmert es mir, dass du absolut Recht hast und es nicht ohne weiteres möglich ist.


    HTTP/HTTPS ist klar, dort verwende ich bereits einen Reverse-Proxy. Am Besipiel SSH kann das ja gar nicht funktionieren. Sobald die DNS Anfrage bei NC eingeht, wird die IP nach 1.2.3.4 aufgelöst. Ab dann wird der SSH Client sich ja auf 1.2.3.4:22 verbinden und nicht nach sub1.meinedomain.de:22. Der vServer kann also gar keine Unterscheidung mehr Anhand des Hostnamen treffen, wohin ich meine Umleitung wünsche.


    Grandiose Idee aber mit Denkfehler. Vielen lieben Dank für eure Zeit und Lösungsansätze.

  • Wie schon erwähnt: DNS kennt kein Konzept einer "Weiterleitung". Das ist nur auf Anwendungsebene (z.B. HTTP Proxies) möglich. Eine möglichst kurze TTL ist hier sicher die besser Lösung. Diese sollte übrigens bei allen DNS Anbietern einstellbar sein, nicht nur bei CF.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

  • [...] Oder du betreibst selber einen Nameserver und lässt die gewünschten Records per NS-Eintrag auf deinen Nameserver zeigen (so brauchst du nur einen Server und keine zwei), bei dem du dann z.B. 1 als TTL nehmen könntest (0 solltest du nicht nehmen, da 0 nicht im Standard definiert ist und das zu Problemen führen kann).
    [...]

    Das Stichwort „Subdomain“ im ursprünglichen Sinn und Kontext von DNS ist hier möglicherweise ein Mittelweg:

    Ein NS- Record oder mehrere davon verweisen für eine Subdomain (3rd-level oder mehr) an fremde Nameserver, die in irgendeiner Form unter Eigenkontrolle stehen. Da gelten dann auch nicht die Vorgaben der TLD hinsichtlich der Redundanz und Netzsegmentierung der Nameserver und dort kann die SOA freilich geringere Intervalle für TTL und Refresh haben, ohne die gesamte Domain (2nd-level) diesen Werten zu unterwerfen.

  • Das Stichwort „Subdomain“ im ursprünglichen Sinn und Kontext von DNS ist hier möglicherweise ein Mittelweg:

    Ein NS- Record oder mehrere davon verweisen für eine Subdomain (3rd-level oder mehr) an fremde Nameserver, die in irgendeiner Form unter Eigenkontrolle stehen. Da gelten dann auch nicht die Vorgaben der TLD hinsichtlich der Redundanz und Netzsegmentierung der Nameserver und dort kann die SOA freilich geringere Intervalle für TTL und Refresh haben, ohne die gesamte Domain (2nd-level) diesen Werten zu unterwerfen.


    Virinum und eripek


    Vielen Dank euch beiden, genau das war die Lösung die ich gesucht habe (danke natürlich auch an alle Anderen für die möglichen Ansätze :) )


    Im NC DNS System habe ich nun für alle Subdomains einen NS Eintrag mit dem Ziel NC vServer angelegt. Dort läuft ein simpler DNS Server in einem Dockercontainer, der stupide eine Hostdatei ausliest. In der Host sind ebenfalls alle Subdomains mit dazugehöriger IP Adresse hinterlegt. Sollte sich nun eine Ziel IP ändern, muss ich lediglich die Hostdatei anpassen, neu einlesen und die Services sind sofort unter der neuen IP erreichbar.

  • Der Nachteil bei nur einem Server ist der Single Point of Failure - aber da kann man ja auch Secondary-Nameserver wie etwa die von HE.net nehmen.

    BTW: Gibt es dort das gratis IPv6-Examen samt gratis T-Shirt noch? ;)

  • Der Nachteil bei nur einem Server ist der Single Point of Failure - aber da kann man ja auch Secondary-Nameserver wie etwa die von HE.net nehmen.

    Oder man mietet sich für ein bisschen Kleingeld pro Monat noch einen vServer bei einem anderen Anbieter (alles für die Ausfallsicherheit) und betreibt mehrere DNS-Server :).

    BTW: Gibt es dort das gratis IPv6-Examen samt gratis T-Shirt noch? ;)

    Stand Juni 2023 konnte man sich zumindest noch dafür aussprechen, dass sie einem so ein T-Shirt schicken. Bisher ist aber noch nichts angekommen (zumindest bei mir^^)

  • Iptables Weiterleitung auf den neuen Server und fertig.

    Wenn noch jemand auf dem alten landet schickst du ihn einfach zum neuen.


    Zu einfach?


    Code
    sysctl -w net.ipv4.ip_forward=1
    iptables -t nat -A POSTROUTING -j MASQUERADE
    iptables -t nat -A PREROUTING -p tcp --dport 443:443 -j DNAT --to-destination 10.152.246.2
    iptables -t nat -A PREROUTING -p tcp --dport 80:80 -j DNAT --to-destination 10.152.246.2


    Kannst natürlich auch 22 als Port angeben oder was du sonst so brauchst.

  • Oder man mietet sich für ein bisschen Kleingeld pro Monat noch einen vServer bei einem anderen Anbieter (alles für die Ausfallsicherheit) und betreibt mehrere DNS-Server :).

    Das kann ich als netcup-Groupie und Entenschwarmmitglied nur wärmstens empfehlen - aber bei netcup an mehreren Serverstandorten. :)

    Weiter ginge das im Thread „Für was braucht man kleine Server“ oder so...