Eigener bind9 Resolver wird standardgemäß nicht verwendet

    Hallo,

    ich habe auf meinem VPS bind9 installiert und er läuft auch soweit. Wenn ich zum Beispiel per dig eine Abfrage starte und @127.0.0.1 hinzufüge, wird der lokale bind Server benutzt. Lasse ich das @127.0.0.1 weg, dann wird der Resolver von Netcup benutzt.

    Wieso das so ist, kann ich nicht nachvollziehen.

    Abfrage mit der locahost Angabe:

    dig A heise.de @127.0.0.1

    ; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> A heise.de @127.0.0.1

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55694

    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:

    ; EDNS: version: 0, flags:; udp: 1232

    ; COOKIE: d11b139ac1138bc80100000067655df8ce2f5699f51eeaf2 (good)

    ;; QUESTION SECTION:

    ;heise.de. IN A

    ;; ANSWER SECTION:

    heise.de. 86149 IN A 193.99.144.80

    ;; Query time: 1 msec

    ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)

    ;; WHEN: Fri Dec 20 13:07:20 CET 2024

    ;; MSG SIZE rcvd: 81

    Abfrage ohne locahost Angabe:

    dig A heise.de

    ; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> A heise.de

    ;; global options: +cmd

    ;; Got answer:

    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44451

    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:

    ; EDNS: version: 0, flags:; udp: 1232

    ;; QUESTION SECTION:

    ;heise.de. IN A

    ;; ANSWER SECTION:

    heise.de. 76779 IN A 193.99.144.80

    ;; Query time: 0 msec

    ;; SERVER: 46.38.225.230#53(46.38.225.230) (UDP)

    ;; WHEN: Fri Dec 20 13:10:42 CET 2024

    ;; MSG SIZE rcvd: 53

    Meine 50-cloud-init.yaml:

    50-cloud-init.PNG

    Meine /etc/bind/named.conf.options:

    nameserver1.PNG

    DIe Ausgabe von 'resolvectl status':

    resolvectl.PNG

    In '/etc/systemd/resolved.conf' habe ich den folgenden Eintrag gemacht:

    resolved.PNG


    Dieses Tutorial verwendete ich: Anleitung, die ich benutzte. Auf einem VPS bei einem anderen Provider funktioniert das einwandfrei. Warum nicht bei Netcup? Kann das jemand erklären?

  • Zur hilfreichsten Antwort springen

    systemd-resolved und unbound kommen sich u.U. in die Quere.

    Und daran denken, dass /etc/resolv.conf bei Ubuntu nur ein link ist, auf /run/systemd/resolve/stub-resolv.conf. Wenn dort was neues (z.B. von systemd-resolved) eingtragen wird, wird somit auch etc/resolv.conf wieder geändert.

    Zitat von aRaphael

    systemd-resolved und unbound kommen sich u.U. in die Quere.

    Und daran denken, dass /etc/resolv.conf bei Ubuntu nur ein link ist, auf /run/systemd/resolve/stub-resolv.conf. Wenn dort was neues (z.B. von systemd-resolved) eingtragen wird, wird somit auch etc/resolv.conf wieder geändert.

    Wenn ich also Änderungen an /etc/resolv.conf vornehme, können sie wieder von systemd-resolved überschrieben werden. Das führt bei mir zu den folgenden Fragen:

    1. Ist es denn schlimm wenn man systemd-resolved vollkommen stilllegt?
    2. Geht das überhaupt?
    3. Was könnte systemd-resolved dazu veranlassen, die /etc/resolv.conf zu überschreiben?

    Wird bei einem Neustart des VPS durch die /etc/cloud/cloud.cfg systemd-resolved dazu verlanlasst wieder die Netcup Resolver in die /etc/resolv.conf einzutragen?

    • Hilfreichste Antwort
    Zitat von klicker4748
    1. Ist es denn schlimm wenn man systemd-resolved vollkommen stilllegt?
    2. Geht das überhaupt?
    3. Was könnte systemd-resolved dazu veranlassen, die /etc/resolv.conf zu überschreiben?

    1) Nein. Denn du hast ja dafür nun unbound

    2) Leicht:

    service systemd-resolved stop

    systemctl disable systemd-resolved.service (Damit er auch nach reboot nicht wieder startet)

    Danach kannst du (wie ich das z.B. immer mache) den Link /etc/resolv.conf löschen und als echte Datei anlegen und dort den NS (127.0.0.1) eintragen. (Dann unbound neu starten) Ich gebe zu, für diesen letzten Schritt gibt es elegantere Wege, aber bei mir hat das bisher immer gut funktioniert.

    Vielen Dank! Ich werde das nachher mal probieren und mich dann wieder mit Feedback melden. :thumbup:

    Zitat von aRaphael

    Danach kannst du (wie ich das z.B. immer mache) den Link /etc/resolv.conf löschen und als echte Datei anlegen und dort den NS (127.0.0.1) eintragen. (Dann unbound neu starten) Ich gebe zu, für diesen letzten Schritt gibt es elegantere Wege, aber bei mir hat das bisher immer gut funktioniert.

    Danach kann man zur Sicherheit - so wie netcup, dhcp, cloud-init oder was auch immer es neuerdings auch macht in den netcup images, die Datei noch "immutable" machen (mit Root-Rechten oder sudo)

    Code
    chattr +i /etc/resolv.conf
    Zitat von H6G

    OT: Hat die stub resolvconf Datei nicht ein paar Kommentare, dass man diese nicht ändern soll?

    Ggf. ist die Datei bei OP gar kein symlink...

    Das kann durchaus sein. Bei Ubuntu hatte ich zwar noch nie Probleme, aber das muss nix heißen. (Aber die stub ändert man ja auch nicht, man killt nur den Link dorthin. Falls es einer ist. ;) )

    Am besten behält man die Inhalte und ändert nur die Nameserver auf local

    Allerdings glaube ich nicht, dass noch viel passieren kann, wenn man systemd-resolved deaktiviert hat.

    Aber klaro: Auf jeden Fall immer Backups dieser Dateien machen. Kein Backup, kein Mitleid. ;)

    Zitat von aRaphael

    1) Nein. Denn du hast ja dafür nun unbound

    2) Leicht:

    service systemd-resolved stop

    systemctl disable systemd-resolved.service (Damit er auch nach reboot nicht wieder startet)

    Danach kannst du (wie ich das z.B. immer mache) den Link /etc/resolv.conf löschen und als echte Datei anlegen und dort den NS (127.0.0.1) eintragen. (Dann unbound neu starten) Ich gebe zu, für diesen letzten Schritt gibt es elegantere Wege, aber bei mir hat das bisher immer gut funktioniert.

    Bevor ich mich an eine Änderung mache, fiel mir gerade auf, dass die Datei /etc/resolv.conf bei mir als normale Datei existiert, aber ein Symlink auf eine andere Datei zeigt. Siehe Bild:

    symlinkresolv.conf.PNG

    Soll ich den löschen?

    Zitat von aRaphael

    1) Nein. Denn du hast ja dafür nun unbound

    2) Leicht:

    service systemd-resolved stop

    systemctl disable systemd-resolved.service (Damit er auch nach reboot nicht wieder startet)

    Danach kannst du (wie ich das z.B. immer mache) den Link /etc/resolv.conf löschen und als echte Datei anlegen und dort den NS (127.0.0.1) eintragen. (Dann unbound neu starten) Ich gebe zu, für diesen letzten Schritt gibt es elegantere Wege, aber bei mir hat das bisher immer gut funktioniert.

    Ich habe nun den systemd-resolved Dienst stillgelegt und die /etc/resolv.conf angepasst. Also nameserver 127.0.0.1 eingetragen und die Netcup Einträge herausgenommen. Den Symlink resolv.conf.default -> ../run/systemd/resolve/stub-resolv.conf habe ich bestehen lassen. Die Datei /etc/resolv.conf war immutable, d. h. mit chattr -i /etc/resolv.conf habe ich sie erst editierbar machen müssen, nachdem Bearbeiten wieder mit chattr +i /etc/resolv.conf wieder auf immutable gesetzt. Dann habe ich vorsichtshalber den VPS neugestartet. Nun werden die DNS Auflösungen über den lokalen Resolver gemacht. Alles gut!

    Nochmals vielen Dank für die Hilfe!

  • klicker4748 20. Dezember 2024 um 20:32

    Hat einen Beitrag als hilfreichste Antwort ausgewählt.