Beiträge von cyp2k

    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.

    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.

    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.

    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

    Das heißt die Lösung funktioniert?

    Ja, das funktioniert.


    Du meinst vermutlich das CloudInit da gerne mal sich einmischt. Sofern man eigene Konfigurationen hat, kann man das CloudInit abgewöhnen: https://cloudinit.readthedocs.…ing-network-configuration

    Ja genau, CloudInit war der Übeltäter. Danke für den Link. Ich war so auf einen Workaround fixiert, dass ich die eigentliche Problemlösung (Deaktivierung von CloudInit Konfigurationen) gar nicht weiter verfolgt hatte.

    Das Thema statische Routen hat mich auch schon einige Nerven gekostet, gerade bei Cloud Servern (trifft hier nicht zu) werden die Interfaces gerne mal überschrieben. Ich löse das mittlerweile mit unabhängigen Scripts. Als Beispiel der Adressierung übernehme ich mal die Annahme von michaeleifel:


    1. nano /pfad/addroute.sh

    2. Inhalt der addroute.sh => ip route add default via 172.16.0.1

    3. chmod +x addroute.sh

    4. crontab -e

    5. Am Ende der Zeile folgenden Eintrag hinzufügen => @reboot /pfad/addroute.sh

    6. Reboot und happy sein :)