it-swarm.com.de

Wie vermeide ich Konflikte zwischen dnsmasq und systemd-Lösung?

Ich habe kürzlich dnsmasq installiert, um als DNS-Server für mein lokales Netzwerk zu fungieren. dnsmasq überwacht Port 53, der bereits vom lokalen DNS-Stub-Listener verwendet wird, von systemd aufgelöst .

Das Stoppen von systemd-Resolution und das Neustarten nach dem Ausführen von dnsmasq lösen dieses Problem. Aber es kehrt nach einem Neustart zurück: systemd-Resolution wird mit Präferenz gestartet und dnsmasq wird nicht gestartet, da Port 53 bereits verwendet wird.

Die erste offensichtliche Frage, denke ich, ist, wie ich systemd-Resolution am besten verständlich machen kann, dass es den lokalen DNS-Stub-Listener nicht starten und somit Port 53 für die Verwendung durch dnsmasq behalten sollte.

Eine interessantere Frage ist jedoch, wie die beiden Dienste im Allgemeinen zusammenarbeiten sollen. Sollen sie überhaupt nebeneinander arbeiten oder ist das System nur so aufgelöst, wenn man dnsmasq verwendet?

66
vic

Ab systemd 232 (veröffentlicht im Jahr 2017) können Sie /etc/systemd/resolved.conf Bearbeiten und diese Zeile hinzufügen:

DNSStubListener=no

Dadurch wird die Bindung an Port 53 deaktiviert.

Die Option wird ausführlicher in der Manpage olved.conf beschrieben.

Sie finden die systemd-Version, mit der Ihr System ausgeführt wird:

systemctl --version
52
Malvineous

Sie können das Laden von systemd-resolved Beim Booten mit Sudo systemctl disable systemd-resolved Deaktivieren.

Wenn Sie beide zusammen ausführen möchten, können Sie den systemd-resolved Umleiten, um den lokalen Host als primären Nameserver zu verwenden. Dadurch wird sichergestellt, dass alle Abfragen zur Lösung an dnsmasq weitergeleitet werden, bevor der externe DNS-Server aufgerufen wird. Dies kann durch Hinzufügen der Zeile nameserver 127.0.0.1 Oben in Ihrer /etc/resolv.conf - Datei erfolgen. Dadurch wird auch das lokale Caching von systemd deaktiviert.

Sie können mehr im Arch Linux Wiki lesen. Ich habe das von dort kopiert und es deckt es ziemlich gut ab.

Dies vermeidet jedoch nicht zuverlässig den Fehler beim Booten, d. H. Dnsmasq schlägt immer noch fehl, wenn systemd-Resolution zuerst gestartet wird. Wenn Ihre Version von systemd neu genug ist, verwenden Sie die Antwort von Malvineous . Wenn Ihre Version von systemd zu alt ist, können Sie dieses Problem umgehen, indem Sie die dnsmasq-Einheit ändern: Fügen Sie im Abschnitt [Unit]Before=systemd-resolved Hinzu.

Wenn Sie möchten, können Sie anschließend eine separate /etc/dnsmasq-resolv.conf - Datei für die Upstream-Nameserver erstellen und diese mit der Option -r Oder --resolv-file Übergeben oder die Upstream-Nameserver zur hinzufügen dnsmasq-Konfigurationsdatei und verwenden Sie die Option -R oder --no-resolv. Auf diese Weise haben Sie nur den localhost in Ihrem /etc/resolv.conf Und alles geht durch dnsmasq.

19
Munir

Nach den Manpages des Systems zu urteilen, ist es nicht beabsichtigt, den Stub-DNS-Server manuell zu deaktivieren. Interessanterweise bemerkte ich das beschriebene Problem erst nach dem Upgrade von systemd von 230 auf 231.

Das Deaktivieren von systemd-Resolution war für mich keine Option, da ich es benötige, um empfangene Upstream-DNS-Server über DHCP zu verarbeiten.

Meine Lösung bestand darin, dnsmasq stop systemd aufzulösen, bevor es gestartet und danach erneut gestartet wurde.

Ich habe eine Drop-In-Konfiguration in /etc/systemd/system/dnsmasq.service.d/resolved-fix.conf Erstellt:

[Unit]
After=systemd-resolved.service

[Service]
ExecStartPre=/usr/bin/systemctl stop systemd-resolved.service
ExecStartPost=/usr/bin/systemctl start systemd-resolved.service

Dies scheint eine ziemlich hackige Lösung zu sein, aber es funktioniert.

7
freaker

Ich habe gerade die Option "Bindeschnittstellen" aktiviert, indem ich '#' am Anfang der Zeile in /etc/dnsmasq.conf entfernt habe.

Ich konnte dnsmasq erneut starten:

  • dnsmasq bind DNS-Port auf allen Schnittstellen (einschließlich 127.0.0.1) Port 53,
  • systemd-resolv hört weiter auf 127.0.0. 53 : 53

Ich wurde durch diese Diskussion auf diese Lösung hingewiesen behoben: Fügen Sie eine Option zum Deaktivieren des Stub-Resolvers hinz

5
tomtom

In der Version systemd232 Gibt es eine Option zum Deaktivieren des Stub-Listeners. Siehe https://github.com/systemd/systemd/pull/4061 .

4
Christoph

Wenn Sie ein Standard-Ubuntu 18.04-Setup verwenden, kann dies durch einen Konflikt zwischen systemd-resolved (Dem Standard-DNS-Server) und verursacht werden dnsmasq. Wenn Sie dnsmasq absichtlich selbst installiert haben, weil Sie es ausdrücklich wollten, ist eine der anderen Antworten auf diese Frage, in der erklärt wird, wie Sie systemd-resolved Deaktivieren, wahrscheinlich gut für Sie. Wenn Sie dnsmasq nicht explizit installiert haben, ist dies wahrscheinlich der Fall, weil Sie lxd verwenden. Dies kann daran liegen, dass Sie tatsächlich lxd zum Verwalten von Containern verwenden, aber höchstwahrscheinlich daran, dass Snaps lxd verwenden, um Sie bei der Installation von Apps zu schützen. Aus meiner Sicht möchte ich dnsmasq behalten (weil lxd es will), aber ich möchte auch systemd-resolved Als DNS-Server behalten (weil es das ist, was das Ubuntu-Team gewählt hat und Ich vertraue ihnen mehr als mir selbst.

Dies scheint also im Kern ein lxd Problem zu sein. Wenn ja, ist die Art und Weise, wie ich es gemäß einem Mailinglistenbeitrag von lxd-Benutzern behoben habe, folgende:

$ lxc network edit lxdbr0

Dadurch wird Ihre Konfiguration in einem Terminal-Editor bearbeitet. Es wird ungefähr so ​​aussehen:

config:
  ipv4.address: 10.216.134.1/24
  ipv4.nat: "true"
  ipv6.address: none
  ipv6.nat: "true"
name: lxdbr0
type: bridge

Fügen Sie drei Zeilen hinzu:

config:
  ipv4.address: 10.216.134.1/24
  ipv4.nat: "true"
  ipv6.address: none
  ipv6.nat: "true"
  raw.dnsmasq: |
    auth-zone=lxd
    dns-loop-detect
name: lxdbr0
type: bridge

und dies sollte dazu führen, dass dnsmasq, das von lxd ausgeführt wird, DNS-Schleifen erkennt. Zumindest für mich löste dies das Problem und stoppte systemd-resolved Und dnsmasq mit 100% CPU.

3
sil

Hier ist die Lösung für (X) Ubuntu 18.04 Bionic.

Installieren Sie dnsmasq

Sudo apt install dnsmasq

Deaktivieren Sie den vom System aufgelösten Listener an Port 53 (berühren Sie nicht /etc/systemd/resolved.conf, da er beim Upgrade möglicherweise überschrieben wird):

$ cat /etc/systemd/resolved.conf.d/noresolved.conf 
[Resolve]
DNSStubListener=no

und starten Sie es neu

$ Sudo systemctl restart systemd-resolved

(Alternativ deaktivieren Sie es vollständig mit $ Sudo systemctl disable systemd-resolved.service)

Löschen Sie /etc/resolv.conf und erstellen Sie es erneut. Dies ist wichtig, da resolv.conf standardmäßig eine symbolische Verknüpfung zu /run/systemd/resolve/stub-resolv.conf ist. Wenn Sie den symbolischen Link nicht löschen, wird die Datei beim Neustart von systemd überschrieben (obwohl wir systemd-Resolution deaktiviert haben!). Außerdem prüft NetworkManager (NM), ob es sich um eine symbolische Verbindung handelt, um eine vom System aufgelöste Konfiguration zu erkennen.

$ Sudo rm /etc/resolv.conf
$ Sudo touch /etc/resolv.conf

Deaktivieren Sie das Überschreiben von /etc/resolv.conf durch NM (es gibt auch eine Option rc-manager, die jedoch nicht funktioniert, obwohl sie im Handbuch NM beschrieben ist):

$ cat /etc/NetworkManager/conf.d/disableresolv.conf 
[main]
dns=none

und starten Sie es neu:

$ Sudo systemctl restart NetworkManager

Sagen Sie dnsmasq, dass es resolv.conf von NM verwenden soll:

$ cat /etc/dnsmasq.d/nmresolv.conf 
resolv-file=/var/run/NetworkManager/resolv.conf

und starten Sie es neu:

$ Sudo systemctl restart dnsmasq

Verwenden Sie dnsmasq zum Auflösen von:

$ cat /etc/resolv.conf 
# Use local dnsmasq for resolving
nameserver 127.0.0.1
3
sena

Ich bin nicht sicher, warum beide Dienste versuchen, dieselbe Adresse zu verwenden. Vielleicht können Sie sie wie in meinem Fall auf Xubuntu 18.04.1 anordnen, wo ihre Konfiguration wie folgt ist:

[email protected]:~$ Sudo netstat -tulpn | grep 53
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      13549/systemd-resol 
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      9632/dnsmasq 

Um systemd mit meinem dnsmasq aufzulösen, habe ich gerade Folgendes festgelegt:

#/etc/systemd/resolved.conf 
[Resolve]
DNS=127.0.0.1

In meiner dnsmasq-Konfiguration habe ich meine externen Nameserver festgelegt:

#/etc/dnsmasq.conf
nameserver x.x.x.x
nameserver y.y.y.y

Nach dem Neustart alles:

# Sudo systemctl restart systemd-resolved.service
# Sudo systemctl restart dnsmasq.service

systemd-Resolution setzt den Standard-DNS-Server auf dnsmasq in:

#/etc/resolv.conf
nameserver 127.0.0.1
1
JonnyTischbein

Ich habe es so gelöst:

Fügen Sie die folgende Zeile in /etc/default/dnsmasq hinzu oder kommentieren Sie sie aus:

IGNORE_RESOLVCONF=yes

Erstellen Sie Ihre eigene Resolv-Datei (/etc/resolv.personal), um Nameserver zu definieren. Sie können hier einen beliebigen Nameserver verwenden. Ich habe zwei von https://www.opennic.org genommen

nameserver 5.132.191.104
nameserver 103.236.162.119

Fügen Sie in /etc/dnsmasq.conf die folgende Zeile hinzu oder kommentieren Sie sie aus:

resolv-file=/etc/resolv.personal

Starten Sie dann dnsmasq neu und deaktivieren Sie den Standard-Resolver: systemd-Auflösung.

Sudo service dnsmasq restart

Sudo systemctl stop systemd-resolved
Sudo systemctl disable systemd-resolved
1
Daniel Pernold

Ich war nicht in der Lage, dnsmasq dazu zu bringen, die online gefundenen Lösungen zu verwenden, d. H. Systemd-aufgelöst zu deaktivieren und dnsmasq.conf so zu ändern, dass "Bind Dynamic" anstelle von "Bind Interfaces" ausgeführt wird. Ich konnte es beim Booten starten, indem ich dnsmasq nach network-online.service anstelle von network.service starten ließ:

[Unit]
Description=dnsmasq - A lightweight DHCP and caching DNS server
Requires=network.target
Wants=nss-lookup.target
Before=nss-lookup.target
After=network-online.target #This line changed
0
omegahelix

Hier ist, was für mich (nach stundenlangen Schmerzen) in Ubuntu 18.10 Cosmic Cuttlefish funktioniert hat. Ich habe dies getan, um den vergleichsweise robusteren Caching-Mechanismus von dnsmasq auszunutzen und NGINX Resolver-Schwachstellen zu vermeiden. Beachten Sie, dass ich die Ubuntu Server-Edition verwende (kein NetworkManager/nmcli, nur systemd-networkd) Und diese auf AWS EC2 ausgeführt wird, sodass ich auch DNS und beibehalten musste DHCP arbeitet mit der Standard-EC2-Suchdomäne. Ich wollte systemd-resolved Nicht vollständig deaktivieren, da ich keine Ahnung habe, wie sich dies auf zukünftige Updates auswirken könnte. Alles hier wird als root/Sudo ausgeführt, sofern nicht anders angegeben (dies geschieht standardmäßig, wenn es als EC2-Benutzerdaten übergeben wird).

## Configure dnsmasq to work with systemd-resolved
# Set static hostname with hostnamectl
hostnamectl set-hostname mydomainname
# Add an entry for the hostname to /etc/hosts
tee --append /etc/hosts <<EOF
127.0.0.1 mydomainname
EOF
# Disable stub listener for resolvconf and set DNS to loopback
tee --append /etc/systemd/resolved.conf <<EOF
DNSStubListener=no
DNS=127.0.0.1
EOF
# Tell dnsmasq to ignore resolvconf
tee --append /etc/default/dnsmasq <<EOF
IGNORE_RESOLVCONF=yes
EOF
# Create dropin directory
mkdir -p /etc/systemd/system/dnsmasq.service.d
# Create systemd dropin to make sure systemd-resolved stops before dnsmasq starts
tee /etc/systemd/system/dnsmasq.service.d/resolved-fix.conf <<EOF
[Unit]
After=systemd-resolved.service
[Service]
ExecStartPre=bin/systemctl stop systemd-resolved.service
ExecStartPost=bin/systemctl start systemd-resolved.service
EOF
# Create custom resolvconf with name servers (I usec cloudflare)
tee /etc/resolv.mydomainname <<EOF
nameserver 1.1.1.1
nameserver 1.0.0.1 
nameserver [2606:4700:4700::1111] 
nameserver [2606:4700:4700::1001] 
EOF
# Configure dnsmasq
tee /etc/dnsmasq.d/mydomainname.conf <<EOF
# Region comes from:
# EC2_AVAIL_ZONE=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
# EC2_REGION=${EC2_AVAIL_ZONE%?}
domain=$EC2_REGION.compute.internal
resolv-file=/etc/resolv.mydomainname
listen-address=127.0.0.1
port=53
interface=lo
bind-dynamic
domain-needed
bogus-priv
dnssec
dns-forward-max=300
cache-size=1000
neg-ttl=3600
EOF
# Reload to pick up dropin
systemctl daemon-reload
# Stop systemd-resolved
systemctl stop systemd-resolved
# Start dnsmasq
systemctl restart dnsmasq

Stellen Sie sicher, dass 127.0.0.1#53 Für die Auflösung verwendet wird und DNSSEC mit etwas wie Dig +trace facebook.com Arbeitet.

0
Justin Garrick

In meinem Fall (ich musste einen DNS-Dienst für andere Computer bereitstellen) konnte ich das Problem lösen, indem ich dnsmasq anwies, nur an die Ethernet-Schnittstelle zu binden (systemd-resolvd bindet an Loopback), indem ich ....

...
interface=eth0
...
bind-interfaces

in dnsmasq.conf

0
symcbean