# Too many DNS servers configured,

blub4747

Lieutenant
Registriert
Juli 2009
Beiträge
520
Hallo Forum,
Wie die Überschrift schon sagt, wird meine resolv.conf mit zu vielen DNS Servern überladen.
Das Scenenario ist folgendes, auf einen PC, welcher per Kabel angebunden ist, laufen Docker Virtmanager, Virtualbox ist ebenfalls installiert (läuft) aber nicht. Damit die Test VMs auch mit den richtigen LAN sprechen können, dafür gibt es auch ein virbr0 Interface an welches das eth0 eingehängt ist.
Wenn ich ein cut auf meine resolv.conf mache, dann bekomme ich Folgenden Inhalt
Code:
nameserver 192.168.178.22
nameserver fde6:3488:dd8c:0:6b4:feff:fec8:7b5a
nameserver 2001:9e8:3fa:1900:6b4:feff:fec8:7b5a
# Too many DNS servers configured, the following entries may be ignored.
nameserver 2001:9e8:3c9:3500:6b4:feff:fec8:7b5a
search fritz.box

Und der fde6 Server scheint von meinen Eth0 zu kommen.
Code:
: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 1c:69:7a:07:de:cf brd ff:ff:ff:ff:ff:ff
    altname eno1
    altname enp0s31f6
    altname enx1c697a07decf
    inet 192.168.178.80/24 brd 192.168.178.255 scope global dynamic noprefixroute eth0
       valid_lft 819214sec preferred_lft 819214sec
    inet6 fde6:3488:dd8c:0:6009:a001:43cc:6664/64 scope global dynamic noprefixroute
       valid_lft 7019sec preferred_lft 3419sec

Und genauso auch der 2001:9e8 Server, meine Frage ist jetzt wie kann ich dafür sorgen das die resolv conf nicht mit diesen 'anderen'
DNS Servern überladen wird, welche von eth0 kommen ?
Danke für eure Antworten,

blub4747
 
Also normalerweise editierst du (als admin) die resolv.conf. Hast du einen DHCP am laufen? Schau dir mal die https://linux.die.net/man/5/dhclient.conf an - es kann sein, dass der auch DNS-Server setzen darf.
 
DNS Abfragen laufen immer so ab, dass der erste Eintrag genommen und getestet wird. Der DNS TImeout kann z.b bei 2000 millisekunden liegen (2 Sekunden). Für den extrem unwahrscheinlichen Fall, dass ein DNS nicht antwortet, dauert er also bis zu 8 Sekunden bis der letzte DNS eine Antwort gibt. Das kann dein Netzwerk unnötig langsam machen. Desweiteren zeigen die ipv6 Adressen evtl. auf den gleichen Server wie die ipv4 Adressen.

Ich würde also maximal 2 ipv6, oder 2 ipv4 DNS Server hinterlegen.
 
Meine FritzBox ist mein DHCP Server.
Und Ich habe vielleicht einen Eintrag in der dhclient.conf, welcher vielleicht helfen könnte,
Nähmlich 'dhcp6.name-servers,' ich werde das mal ausprobieren und no setzten.

Heimnetz->Netzwerk-> IPv6
'Unique Local Addresses (ULAs) immer zuweisen'
Und herrausgefunden das die Addresse
'fde6:3488:dd8c::6b4:feff:fec8:7b5a' von der FritzBox kommt.
Also habe ich natülich, diesen Hacken entfernt.
Zusätzlich habe ich noch die Option
'DNSv6-Server im Heimnetz' gefunden und dort ebenfalls den Hacken entfernt.
Ergänzung ()

Leider hat sich das Problem immer noch nicht aufgelöst.
Ich habe mal auf einer anderen Kiste mit gleichen OS LinuxMint Debian Edition7 geschaut und dort funktioniert alles.
Das bedeutet das, wenn ich ein host auf meinen pi2 abfahre,
Code:
host pi2
pi2 has address 192.168.178.22
pi2 has IPv6 address fd79:1d1b:9205:0:7903:b018:2678:56b
blub@neo-atom-nuc~$^C
blub@neo-atom-nuc~$ping pi2
ping: pi2: Der Name oder der Dienst ist nicht bekannt
blub@neo-atom-nuc~$ssh pi2
ssh: Could not resolve hostname pi2: Name or service not known

auf den anderen PC funktioniert alles.
Und merkwürdiger unterschied ist noch.
Das auf den anderen PC die resolv.conf nicht von /run/systermd/resolv verlinkt nicht ist.
sondern anscheinend wirklich von NetworkManager generiert wird.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Simanova
Der lokale 'Naneserver' ist bei mir Pihole :)
foofoobar schrieb:
Wenn du mehr brauchst installiere dir einen lokalen Nameserver.
Okay, ich habe jetzt herausgefunden, das Packet
systemd-resolved

verantwortlich war, und nachdem ich es entfernt habe, läuft ENDLICH alles wie ich mir das vorgestellt habe :)
 
blub4747 schrieb:
Okay, ich habe jetzt herausgefunden, das Packet
systemd-resolved

verantwortlich war, und nachdem ich es entfernt habe, läuft ENDLICH alles wie ich mir das vorgestellt habe :)

Nein, das Paket war dafür nicht verantwortlich, sondern dein Router, der die GUA-IPv6 als DNS-Server sendet. Du hast jetzt das Symptom und nicht die Ursache beseitigt.

Also prüfe, ob was dein Router in den Router Advertisements für DNS-Server mitsendet. Die GUA hat da eigentlich nichts zu suchen. Das betrifft alle Geräte in deinem Netzwerk.

Zusätzlich lassen sich die DNS-Server in der resolved.conf auch überschreiben:

The following options are available in the [Resolve] section:

DNS=
A space-separated list of IPv4 and IPv6 addresses to use as
system DNS servers. Each address can optionally take a port
number separated with ":", a network interface name or index
separated with "%", and a Server Name Indication (SNI)
separated with "#". When IPv6 address is specified with a port
number, then the address must be in the square brackets. That
is, the acceptable full formats are
"111.222.333.444:9953%ifname#example.com" for IPv4 and
"[1111:2222::3333]:9953%ifname#example.com" for IPv6. DNS
requests are sent to one of the listed DNS servers in parallel
to suitable per-link DNS servers acquired from
systemd-networkd.service(8) or set at runtime by external
applications. For compatibility reasons, if this setting is
not specified, the DNS servers listed in /etc/resolv.conf are
used instead, if that file exists and any servers are
configured in it. This setting defaults to the empty list.
 
Laut der Info's meiner Fritzbox gekommen, mein PC zur Zeit eine

Tempotäre GUA IPv6

und eine IPv6 LLA

und in der resolv.conf

bekomme ich eine IPv4 und eine IPv6 Adresse welche mit fd79 anfängt.

Und in Heimnetz -> Netzwerk -> Erweiterte Netzwerkeinstellungen - IPv6
dort kann ich keine Einstellungen zu GUA IPs finden.

Folgende Haken sind dort gesetzt.
Router Advertisement im LAN aktiv
Diese FRITZ!Box stellt den Standard-Internetzugang zur Verfügung

DHCPv6-Server in der FRITZ!Box für das Heimnetz aktivieren
DNS-Server und IPv6-Präfix (IA_PD) zuweisen
 
Die fd79 ist eine ULA. Die ist nur in deinem lokalen Netz gültig und die ist völlig ok als DNS-Server.

Die GUA mit 2001 ist die globale IPv6-Adresse der Fritzbox.

Dein Problem liegt hier:
blub4747 schrieb:
DHCPv6-Server in der FRITZ!Box für das Heimnetz aktivieren
DNS-Server und IPv6-Präfix (IA_PD) zuweisen

Du benötigst in der Regel keinen DHCPv6-Server im Heimnetz. Deine Geräte können sich via SLAAC und mit Hilfe der Router Advertisements problemlos ihre globalen IPv6-Adressen generieren.

Hier scheint der DHCPv6-Server auch noch die GUA als DNS-Server im Netzwerk zu verteilen, was keinen Sinn macht.

Also den DHCPv6-Server in der Fritzbox deaktivieren und die erste Option Es sind keine anderen DHCPv6-Server im Heimnetz vorhanden. auswählen.

Oben sollte noch Unique Local Addresses (ULAs) immer zuweisen aktiviert sein und unter DNSv6-Server im Heimnetz trägst du die ULA deines Pi-Hole ein.

systemd-resolved würde ich wieder installieren, das Problem sollte damit erledigt sein.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Samurai76
mein Pihole bekommt oder hat zwei verschiende ULA
IPv6 Addressen.
Welche wäre die Richtige für die FritBox ?
fd79:1d1b:9205::412/128
oder die
fd79:1d1b:9205:0:7903:b018:2678:56b/64
 
Die erste wird via DHCPv6 kommen und die zweite via Router Advertisements. Die erste wird vermutlich verschwinden, nachdem du den DHCPv6-Server in der Fritzbox deaktiviert und den Pi-Hole neu gestartet hast.
 
blub4747 schrieb:
Okay, ich habe jetzt herausgefunden, das Packet
systemd-resolved
verantwortlich war, und nachdem ich es entfernt habe, läuft ENDLICH alles wie ich mir das vorgestellt habe :)
Wieder mal ein gutes Beispiel weswegen ich das systemd-Krebsgeschwür meide, ich kann nur jeden raten auf systemd-freie Distros umzusteigen (z.B. Devuan statt Debian, oder Artix statt Arch).
 
Wieder mal ein gutes Beispiel, warum man manche User einfach gleich nach dem ersten Kommentar blockieren sollte. Ich kann nur jedem raten, keine Ratschläge anzunehmen von jemandem, der völlig unqualifizierten Unsinn in irgendwelche fremden Threads rotzt, ohne irgendwie zur Lösung beizutragen.
 
  • Gefällt mir
Reaktionen: Piktogramm, cbtaste420, frabron und 2 andere
Bin Linux User seit 1994, du magst nichts anderes als systemd-Distros kennen, deshalb bis du wohl voreingenommen, ich rate dir auch mal einen systemd-freie Distro auszuprobieren, schon der Bootvorgang ist meistens viel schneller.
Und das du mich gleich persönlich auf übelste Art angreifst sagt viel mehr über dich aus als über mich.
 
SirSinclair schrieb:
Wieder mal ein gutes Beispiel weswegen ich das systemd-Krebsgeschwür meide

Hat Dein Rant in irgendeiner Weise was mit dem Problem des Anfragenden zu tun? Natuerlich nein!
Abgesehen davon wuerde Dir unter entsprechenden Umstaenden Dir Dein DNS exakt selbiges liefern.

SirSinclair schrieb:
du magst nichts anderes als systemd-Distros kennen, deshalb bis du wohl voreingenommen, ich rate dir auch mal einen systemd-freie Distro auszuprobieren, schon der Bootvorgang ist meistens viel schneller.

Was hat das in irgendeiner Weise mit DNS zu tun?
Zweimal RANT?
 
Zuletzt bearbeitet: (Typo)
  • Gefällt mir
Reaktionen: sedot
BFF schrieb:
Hat Dein Rant in irgendeiner Weise was mit dem Problem des Anfragenden zu tun?
Ja natürlich, Ich hab ihm geraten mal eine systemd-freie Distro auszuprobieren, jetzt wo er selbst gemerkt hat das sein Problem durch eine der unzähligen systemd-Dienste (Metastasen wäre passender) verursacht wurde,
 
Zuletzt bearbeitet:
Bei mir ist es übrigens im NetworkManager konfiguriert und verwendet dafür den System-Dienst "systemd-resolved". In /etc/resolv.conf steht 127.0.0.53, das als lokaler DNS-Stub von systemd-resolved fungiert. DNS-Anfragen werden darüber an systemd-resolved weitergeleitet, welcher anschließend die im NetworkManager-Profil konfigurierten DNS-Server verwendet.

Code:
❯ sudo cat /etc/resolv.conf

nameserver 127.0.0.53
options edns0 trust-ad

❯ sudo cat "/etc/NetworkManager/system-connections/LAN.nmconnection"

[connection]
id=LAN
uuid=xxx
type=ethernet
autoconnect-priority=-100
dns-over-tls=2
timestamp=1778704609

[ethernet]

[ipv4]
dns=1.1.1.1#cloudflare-dns.com;1.0.0.1#cloudflare-dns.com;
dns-priority=-1
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns=2606:4700:4700::1111#cloudflare-dns.com;2606:4700:4700::1001#cloudflare-dns.com;
dns-priority=-1
method=auto

[proxy]

❯ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-08-21 20:30:46 CEST; 1h 8min ago
 Invocation: fba1b576a24e4c14a375964bd0915c2c
TriggeredBy: ● systemd-resolved-monitor.socket
             ● systemd-resolved-varlink.socket
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://systemd.io/WRITING_NETWORK_CONFIGURATION_MANAGERS
             https://systemd.io/WRITING_RESOLVER_CLIENTS
   Main PID: 457 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 38243)
     Memory: 7.6M (peak: 9.9M)
        CPU: 653ms
     CGroup: /system.slice/systemd-resolved.service
             └─457 /usr/lib/systemd/systemd-resolved

Aug 21 20:30:46 1up systemd-resolved[457]: Using system hostname '1up'.
Aug 21 20:30:46 1up systemd[1]: Started Network Name Resolution.
Aug 21 20:30:46 1up systemd-resolved[457]: Switching to fallback DNS server 9.9.9.9#dns.quad9.net.
Aug 21 20:30:51 1up systemd-resolved[457]: enp7s0: Bus client set search domain list to: ~., ~.
Aug 21 20:30:51 1up systemd-resolved[457]: enp7s0: Bus client set default route setting: yes
Aug 21 20:30:51 1up systemd-resolved[457]: enp7s0: Bus client set DNS server list to: 1.1.1.1#cloudflare-dns.com, 1.0.0.1#cloudflare-dns.com, 2606:4700:4700::1111#cloudfl>
Aug 21 20:30:51 1up systemd-resolved[457]: enp7s0: Bus client set DNSOverTLS setting: yes
Aug 21 20:30:51 1up systemd-resolved[457]: enp7s0: Bus client set DNS server list to: 1.1.1.1#cloudflare-dns.com, 1.0.0.1#cloudflare-dns.com, 192.168.0.1
Aug 21 20:30:53 1up systemd-resolved[457]: mDNS-IPv6: There appears to be another mDNS responder running, or previously systemd-resolved crashed with some outstanding tra>
Aug 21 20:30:53 1up systemd-resolved[457]: enp7s0: Bus client set DNS server list to: 1.1.1.1#cloudflare-dns.com, 1.0.0.1#cloudflare-dns.com, 192.168.0.1, 2606:4700:4700:>

Also an deiner Stelle würde ich ebenfalls "127.0.0.53" und "options edns0 trust-ad"
in /etc/resolve.conf eintragen.
Und den Rest im den NetworkManager konfugurieren.

Code:
nmcli connection show

nmcli connection modify "NameDeinerVerbindung" ipv4.dns "192.168.178.22"

nmcli connection down "NameDeinerVerbindung"

nmcli connection up "NameDeinerVerbindung"

Gut das du den Thread eröffnet hast,
dadurch ist mir aufgefallen das ich gar kein DNSSEC aktiviert hatte.
Dann passt es auch zu "options edns0 trust-ad" in der resolve.conf.
EDNS(0) = Extension Mechanisms for DNS
TRUST-AD = AD-Bit (Authenticated Data) Das betrifft DNSSEC: Wenn ein vorgeschalteter Resolver eine Antwort als DNSSEC-validiert, darf der lokale Resolver diese Information an die Anwendung weitergeben.

Also habe ich noch gemacht:

Code:
nmcli connection modify "NameDeinerVerbindung" connection.dnssec yes
nmcli connection down "NameDeinerVerbindung"
nmcli connection up "NameDeinerVerbindung"


Code:
❯ resolvectl status
Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: foreign
Fallback DNS Servers: 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google
                      2001:4860:4860::8888#dns.google

Link 2 (enp7s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS +DNSOverTLS DNSSEC=yes/supported
Current DNS Server: 1.1.1.1#cloudflare-dns.com
       DNS Servers: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
        DNS Domain: ~.
     Default Route: yes

Protocols: +DefaultRoute +LLMNR +mDNS +DNSOverTLS DNSSEC=yes/supported
 
Zuletzt bearbeitet:
Zurück
Oben