# Problem resolv.conf

## deranonyme

Nachdem ich in letzter Zeit immer mal Probleme hatte dass plötzlich, einige Zeit nach dem Start, meine Internetverbindung abbrach bin ich der Sache heute mal auf den Grund gegangen. Dabei habe ich festgestellt, dass der Nameservereintrag wohl plötzlich nicht mehr funktionierte. 

Bei mir wurde bis heute der Nameservereintrag durch systemd erstellt (systemd-resolved.service). 

```
# ls -l /etc/resolv.conf

lrwxrwxrwx 1 root root 32  2. Jun 2016  /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
```

Ein Neustart 

```
systemctl restart systemd-resolved.service
```

 hat den DNS nicht aufwecken können. 

Aus irgend einem Grund scheint er sich während der Laufzeit des Rechners geändert zu haben. Der aktuelle Eintrag nachdem die Verbindung abgebrochen war lautete 

```
nameserver fd00::5e49:79ff:fedd:5a4e
```

Mein Rechner hängt an einer Fritzbox, die ich eigentlich als nameserver nutzen wollte.

Ich habe jetzt den Link entfernt und eine statische IP in der resolv.conf festgelegt. Alles wieder paletti.

Allerdings frage ich mich was das für eine IP ist und wo die her kommt.

 *Quote:*   

> # whois fd00::5e49:79ff:fedd:5a4e
> 
> Unbekannte AS-Nummer oder unbekanntes IP-Netzwerk. Bitte führen Sie ein Upgrade dieses Programms durch.

 

Jemand eine Idee?

----------

## mike155

fd00::5e49:79ff:fedd:5a4e ist eine IPv6 Adresse aus dem "Unique Local Unicast" Bereich (siehe RFC 4193). Von daher ist nachvollziehbar, dass whois keine Antwort liefert.

Die Datei "/run/systemd/resolve/resolv.conf" wird von Systemd erstellt. Schau Dir "man systemd-resolved" an.

Hinter der IPv6-Adresse verbirgt sich vermutlich der Router. Möglicherweise auch der Host selbst.

Ich mag es nicht, wenn Systemd (oder DHCP-Clients) meine DNS Konfigurationsdateien verändern. Deshalb ist "/etc/resolv.conf" bei mir kein Link, sondern eine eigenständige Datei - in der ich (und nicht irgendwelche Programme) definiere, wie die DNS Namensauflösung erfolgen soll.

----------

## deranonyme

 *mike155 wrote:*   

> Ich mag es nicht, wenn Systemd (oder DHCP-Clients) meine DNS Konfigurationsdateien verändern. Deshalb ist "/etc/resolv.conf" bei mir kein Link, sondern eine eigenständige Datei - in der ich (und nicht irgendwelche Programme) definiere, wie die DNS Namensauflösung erfolgen soll.

 

Danke. Geht mir genauso. Ich hatte aber nicht auf dem Schirm das systemd die resolv.conf beeinflusst.   :Embarassed:  Hatte jetzt auch schon statisch meine Fritzbox als DNS-Server eingetragen. Was mich aber sehr stutzig gemacht hat war, dass die Namensauflösung erst funktioniert hat und nach einer gewissen Zeit, je nach Tagesform  :Question:  , ausgefallen ist. Das würde ja bedeuten das die resolv.conf während der Laufzeit des Rechners geändert wurde. Jetzt frage ich mich durch wen/was und warum?

----------

## ChrisJumper

Du kannst auch Systemd verwendeb oder wenn du weist was du tust die selbst angelegte resolve.conf.

Der Fehler ist einfach das aufgrund unzureichender Doku du Systemd nicht ordentlich konfiguriert hast. Das problem kommt daher das systemd sich immer mehr anmaßt übernehmen zu müssen. Netzwerk war damals keine Systemd Aufgabe und Gentoo Nutzer wurden die Grundlagen noch beigebracht.

Der Automatismus von IPv6 ist bald Standard und wirbelt das ordentlich auf.

Du kannst in systemd mit dem integrierten network manager statische, dynamische (dhcp) netzwerk Config machen. Mit eigenen unitfiles und ip oder route befehlen. Oder systemd Networkmanager.

Das blöde ist langfristig bist du nicht standard konform bei ipv6 wenn du das manuell machst und das da die blöde ipv6 adresse als nameserver gesetzt wird ist ein fallback oder wenn der geht kommt das von der fritzbox.

----------

## musv

Bevor wir wieder zum Systemd-Bashing kommen, räumen wir mal mit ein paar Halbwahrheiten auf. Vorerst noch: IPv6 hab ich mit Systemd bisher noch nicht konfiguriert. 

Zur Netzwerkkonfiguration mit Systemd:

resolv.conf

```
lrwxrwxrwx 1 root root 32  6. Nov 2016  /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
```

Das ist vollkommen korrekt so. System erzeugt dynamisch eine resolv.conf im Zielordner. 

Die Configdatei für systemd-resolved ist in /etc/systemd/resolved.conf. Hier können Defaultwerte für die resolved.conf festgelegt werden. Im Normalfall wird hier aber nichts eingestellt. 

networkd

```

[Match]

Name=eth0

[Network]

#Address=192.168.109.20/24

#Gateway=192.168.109.1

#DNS=127.0.0.1

#DNS=8.8.8.8

DHCP=ipv4

[DHCP]

UseDomains=true
```

Wie man hier schön rauslesen kann, wird dabei die Konfiguration per DHCP ermittelt. Man kann aber auch die einzelnen Werte manuell überschreiben. Das Ganze funktioniert bei mir tadellos. Die DNS-Einträge werden von Systemd-Resolved ausgelesen. Daraus wird dann die /run/systemd/resolve/resolve.conf erstellt, auf die die /etc/resolve.conf gelinkt ist. Entsprechend müssen beide Services (systemd-networkd und systemd-resolved) aktiviert und gestartet sein. 

Natürlich kann man den Systemd-Resolved auch runterschmeißen und die /etc/resolve.conf manuell bestücken. Funktioniert ebenfalls problemlos. Dann werden die DNS-Einträge in /etc/systemd/networkd/xxx.conf eben ignoriert.

Networkmanager

Diese Katastrophe hab ich schon vor langer Zeit von meinem Desktoprechner verbannt. Und mit der Kombination aus Networkd und WPA_GUI konnte ich den Networkmanager auch endlich von meinem Notebook entfernen. Der Networkmanager hatte einen grundlegenden Bug, dass er NFS-Laufwerke beim Runterfahren nicht sauber ausgehängt hat. Bei mir hat das blöde Teil erst den NFS beendet und dann versucht, das Laufwerk auszuhängen. Dabei hing dann der Rechner beim Runterfahren immer. Neben der Bequemlichkeit hat der Networkmanager den einzigen Vorteil, dass man damit LTE-Sticks leichter benutzen kann. Mit vwdial bin ich da leider fast immer gescheitert.

Doku

```
man 5 resolved.conf

man 5 networkd.conf

man 5 systemd.network
```

----------

## schmidicom

Man sollte sich eben immer überlegen was das eigentliche Ziel ist.

1) net-misc/networkmanager

Hat die aktuell wohl beste Integration in die gängigsten Desktopumgebungen. Bringt dafür aber auch jede menge Abhängigkeiten mit und ist aufgrund seiner Komplexität entsprechend anfällig für eventuelles Fehlverhalten, besonders in "Spezialfällen".

2) net-misc/netifrc

Ist klein (Code/Abhängigkeiten) und leicht zu verstehen. Hat aber so weit ich weiß keine Desktopintegration und kennt auch keine auf Event basierte Aktionen (z.B. Eine Verbindung erst aktivieren/konfigurieren wenn das Kabel eingesteckt wird).

3) sys-apps/systemd (systemd-networkd und systemd-resolved)

Ebenfalls leicht zu verstehen und gut Dokumentiert, ist jedoch fester Bestandteil von systemd kann aber problemlos deaktiviert werden/bleiben. Auch hier gibt es keine Desktopintegration welche mir bekannt wäre aber dafür Event basierte Aktionen.

Das erste finde ich bei Desktops und Laptops ganz angenehm, außer natürlich einem kommt so etwas wie bei "musv" in die Quere. Beim zweiten und dritten ist wohl der Einsatz auf dem Server das beste, je nach dem womit das dort installierte System eben gestartet wird.

----------

## musv

 *schmidicom wrote:*   

> Man sollte sich eben immer überlegen was das eigentliche Ziel ist.
> 
> 3) sys-apps/systemd (systemd-networkd und systemd-resolved)
> 
> Ebenfalls leicht zu verstehen und gut Dokumentiert, ist jedoch fester Bestandteil von systemd kann aber problemlos deaktiviert werden/bleiben. Auch hier gibt es keine Desktopintegration welche mir bekannt wäre aber dafür Event basierte Aktionen.
> ...

 

Hier wird's eigentlich ziemlich gut beschrieben: 

https://forum.manjaro.org/t/how-to-use-systemd-networkd-to-manage-your-wifi/1557

Im Grunde genommen läuft das mit Wifi dann so ab, dass du statt der Networkmanager-GUI die WPA_GUI verwendest. Dort wählst du das Netzwerk (ESSID) aus und gibst das Passwort ein. Das wird dann in /etc/wpa_supplicant/wpa_supplicant.conf abgelegt. Es sieht nicht so hübsch aus wie der Networkmanager, ist aber im Grunde genommen für die WIFI-Konfiguration nicht markant schlechter benutzbar. Und bedingt durch wpa_supplicant steht das Wifi-Passwort im Klartext in der wpa_supplicant.conf

Da mit der Networkmanager zu sehr gestört hatte, hatte ich lange nach einer Alternative gesucht. Wicd und Netctl waren die Sachen, die ich gefunden hatte. Wicd hatte ich früher schon mal kurz im Einsatz. Das wurde dann aber irgendwie nicht mehr aktiv gepflegt. Netctl klappte eigentlich ganz gut, brachte mir aber keine Vorteile zu Networkd+WPA_GUI. Und zweiteres ist im Systemd sowieso schon drin.

----------

## schmidicom

@musv

Eine interessante Kombi von systemd-networkd und "net-wireless/wpa_supplicant" und für die meisten dürfte das wohl auch auf dem Desktop ausreichend sein.

Mein Fall ist leider etwas spezieller, ich muss mit meinem Laptop immer wieder an verschiedene Netzwerkinfrastrukturen ran welche (zumindest am Backbone) oft auch noch eine VLAN-Konfiguration erfordern. Da jedesmal über die root-Konsole eine passende Schnittstellen Konfiguration zu schreiben ist mir irgendwann schlicht verleidet.  :Wink: 

Mit dem NetworkManager kann ich mir diese Verbindungen ziemlich einfach zusammenklicken und nach Gebrauch wieder löschen.

----------

## mike155

 *schmidicom wrote:*   

>  ich muss mit meinem Laptop immer wieder an verschiedene Netzwerkinfrastrukturen ran

 

Das ist bei mir ähnlich - ich habe ca. 6 verschiedene Umgebungen, in denen ich regelmäßig arbeite. Ich habe mir ein kleines Script geschrieben, dem ich als Parameter die Lokation mitgebe. Es führt alle für die gewählte Lokation notwendigen Konfigurationsarbeiten durch (über ifconfig, route, iptables, usw.). Es erstellt auch die notwendigen Konfigurationsdateien (/etc/resolv.conf, /etc/ntp.conf, /etc/openvpn/*, /etc/cups/client.conf, Proxy-Einstellung für Firefox, usw.) und startet die benötigten Dienste. 

Meiner Erfahrung nach ist dieses Vorgehen das einzige, das zuverlässig und auch langfristig funktioniert.

----------

