AdGuard Home löst DNS auf einmal nicht mehr richtig auf

Hallo und guten Abend,

das hat zwar nichts mit IPV64 zutun aber vielleicht könnt ihr mir hier helfen.

Ich verwende in meinem privaten Netzwerk AdGuard Home als lokalen DNS (also Docker) auf einem Linux-PC mit Open Media Vault hinter einer AVM FritzBox. Das funktionierte bis heute alles soweit problemlos. Heute fiel mir aber auf, dass AdGuard Home scheinbar eine Adresse nicht auflösen kann – selbst bei deaktivierten AdGuard Schutz:

api.met.no

C:\>nslookup api.met.no
Server:  UnKnown
Address:  fd00::4a5d:35ff:fe1e:60

Nicht autorisierende Antwort:
Name:    api.met.no.fritz.box
Addresses:  ::1
          127.0.0.1

Nach einigem Rumprobieren, woran das liegen kann, funktionierte auf einmal gar keine URL mehr, z.B. auch:

C:\>nslookup www.google.de
Server:  UnKnown
Address:  fd00::4a5d:35ff:fe1e:60

Nicht autorisierende Antwort:
Name:    www.google.de.fritz.box
Addresses:  ::1
          127.0.0.1

Im Browser lassen sich dennoch alle Webseiten öffnen und ich sehe in den Logs von AdGuard Home auch.

Stoppe ich den Docker mit AdGuard Home und starte meinen „Fallback“ Docker mit pihole, dann funktioniert alles problemlos.

Was ist hier passiert und wie kann ich das Problem beheben?

Vielen Dank für eure Ideen und Rückmeldungen im Voraus!

Grüße
Mic.

Was sind die übergeordneten DNS-Server von Adguard? Was bewirkt dort ggf eine Änderung auf einen anderen?

Hallo Markus,

vielen Dank für deine Rückmeldung. Ich habe die von AdGuard vorgegebenen Standard-DNS eingetragen:

https://dns10.quad9.net/dns-query
https://dns.adguard-dns.com/dns-query
tls://dns.adguard-dns.com
quic://dns.adguard-dns.com
94.140.14.14
2a10:50c0::ad1:ff

Ich habe aber auch testweise schon 8.8.8.8 oder 9.9.9.9 an erste Stelle der Liste ergänzt. Das half auch nichts.

Ich denke aber, das Problem ist, dass AdGuard Home aus irgendeinem unerfindlichen Grund bei Anfragen via nslookup den „Domain“ meiner FritzBox als Suffix .fritz.box an die URL anhängt und diese komplette URL www.google.de.fritz.box dann nicht auflösen kann. Dieses Problem hatte ich aber bis vorgestern nicht. Wieso passiert das auf einmal?

Ich habe heute einmal alle Einstellungen von AdGuard Home gelöscht (also sozusagen auf Werkseinstellungen) zurückgesetzt aber auch dies brachte keine Lösung.

Ich habe heute noch einmal ein paar Tests gemacht:

## Test mit mobilem Hotspot vom Handy:
C:\>nslookup www.google.de
Server:  UnKnown
Address:  fe80::8004:5fff:fe53:b264

Nicht autorisierende Antwort:
Name:    www.google.de
Addresses:  2a00:1450:4001:813::2003
          142.250.185.227

## Test mit pihole als DNS im Netzwerk:
C:\>nslookup www.google.de
Server:  pi.hole
Address:  fd00::4a5d:35ff:fe1e:60

Nicht autorisierende Antwort:
Name:    www.google.de
Addresses:  2a00:1450:4016:80b::2003
          142.251.37.3

## Test mit AdGuard Home als DNS im Netzwerk:
C:\>nslookup www.google.de
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  fd00::4a5d:35ff:fe1e:60

DNS request timed out.
    timeout was 2 seconds.
Name:    www.google.de.fritz.box
Address:  ::1

## Test mit AdGuard Home als DNS im Netzwerk, aber Punkt am Ende der Domain:
C:\>nslookup www.google.de.
Server:  UnKnown
Address:  fd00::4a5d:35ff:fe1e:60

Nicht autorisierende Antwort:
Name:    www.google.de
Addresses:  2a00:1450:4001:831::2003
          142.251.209.131

Dieses merkwürdige Verhalten tritt aber auch nicht an jedem Netzwerkgerät auf. Vereinzelt tritt es, wie gesagt im Docker für NextCloud mit api.met.no auf.

Dauerhaft tritt das Problem aber ver Nutzung von AdGuard Home auf meinem Laptop mit Windows 11 auf (egal, ob ich per LAN oder W-LAN verbunden bin). Aber wieso nur bei AdGuard Home als DNS?

Teste ich mit meinem Laptop mit Linux Mint, sehe ich dies hier mit AdGuard Home:

mic@MicLinux:~$ nslookup www.google.de 192.168.178.60
Server:		192.168.178.60
Address:	192.168.178.60#53

Non-authoritative answer:
Name:	www.google.de
Address: 142.251.209.131
Name:	www.google.de
Address: 2a00:1450:4005:801::2003

Wobei… fragt er da wirklich den AdGuard Home als DNS an?

Ich verstehe es nicht… Habt ihr da eine Idee?

Viele Grüße
Mic.

Hallo nochmal,

ich habe heute Abend noch ein wenig rumgetüftelt und bin nun der Meinung, dass dieses Phänomen irgendwie im Zusammenspiel zwischen AdGuard Home als DNS und Windows 11 aufgetreten ist. Windows hat eine DNS-Anfrage gestellt, die AdGuard Home irgendwie falsch beantwortet hat, indem es den Domain mit .fritz.box ergänzt hat. Das hat wohl Windows “gelernt” und danach immer so weiter gemacht. Leider kann man Windows das scheinbar nicht abtrainieren. DNS-Cache leeren usw. hat nicht geholfen. Jetzt habe ich aber eine Lösung gefunden. Es ist evtl. ein Workaround aber mein lokales System funktioniert erst einmal wieder halbwegs.

Was mache ich gemacht. In AdGuard Home habe ich unter EinstellungenDNS-Einstellungen im Abschnitt Sperrmodus auf NXDomain umgestellt.

Weiterhin habe ich den falschen Domain-Suffix .fritz.box auf die benutzerdefinierte Blockliste gesetzt. Dazu unter FilterBenutzerdefinierte Filterregeln im oberen Feld folgende Blockier-Regel ergänzen:

||fritz.box^

Damit kann Windows Anfragen von nslookup über den AdGuard DNS wieder korrekt auflösen und die API api.met.no wird von NexCloud auch wieder erreicht.

C:\>nslookup www.google.de
Server:  UnKnown
Address:  fd00::4a5d:35ff:fe1e:60

Nicht autorisierende Antwort:
Name:    www.google.de
Addresses:  2a00:1450:4001:811::2003
          142.250.185.163

Was damit weiterhin nicht funktioniert, ist eine Anfrage nslookup gegenüber einem externen DNS, wie z.B. 8.8.8.8:

C:\>nslookup www.google.de 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Nicht autorisierende Antwort:
Name:    www.google.de.fritz.box
Addresses:  ::1
          127.0.0.1

Da müsste man aber wohl eher nach einer Lösung in Windows suchen. Wenn da einer eine gute Idee hat, sehr gern her damit.

Alles sehr komisch… damit erst einmal einen schönen Abend.

Grüße
Mic.

Ggf passend FRITZ!Box 7490 und OS 7.61; Und *.fritz.box liefert plötzlich 127.0.0.1 statt NXDOMAINBorns IT- und Windows-Blog

EDIT: Idee, lass mal Adguard DHCP machen ob sich das Verhalten ändert.

Hallo,

danke für den Link. Sehr interessant, dass viele Leute dieses Problem mit dem Suffix *.fritz.box bekommen haben. Eine echte Lösung finde ich aber auf der Seite nicht. Das klingt alles auch nach Workarounds.

Wer ist denn nun am Ende wirklich der Schuldige, der die Domain-Anfragen so „verunstaltet“, dass sie nicht mehr sauber beantwortet werden können? Und wieso tritt der Fehler nicht konsistent über alle Geräte hinweg auf? Wenn ich den Artikel in deinem Link so lese, dann scheint wohl doch Windows 11 nicht „der Schuldige“ zu sein.

Grüße
Mic.

PS.: Umstellung DHCP von FritzBox auf EdGuard ist nicht so ganz trivial und muss ich aus zeitlichen Gründen erst mal hintenanstellen.

Interessant finde ich bei solchen Artikeln immer die Kommentare wer abschließend schuld hat, bekommt man wohl nur mit Trial and Error raus.

Ich persönlich bin aus solchen Gründen lange weg von Avm und auch win… aber das ist eine andere Geschichte…

Hi,

das Problem könnte sein, dass dein Windows das DNS Suffix an den Request hängt, weil es das vom DHCP Server (Fritzbox) erhält. Stell das mal testweise in den erweiterten TCP/IP Einstellungen aus. Vielleicht war es das schon.

Gruß

Hallo zusammen,

danke für eure Rückmeldungen. Ja, so langsam macht mir es mir Windows auch schwer, es zu mögen. In den letzten Jahren hat sich Windows in eine Richtung entwickelt, die ich, als jemand, der den PC nicht nur als Schreibmaschine verwendet, nicht wirklich mag. Auf der anderen Seite ist Windows mit all den Softwarepaketen, die es dafür gibt, für die Tägliche „Arbeit“ einfach sehr bequem und schon gut. Anyhow… das ist echt eine andere Geschichte.

Ebenso ist es mit AVM. An sich war (und bin) ich Fan der Fritz-Produkte, vor allem, weil die einen echt spitzen Support haben und ich für die auch immer mal wieder neue Labor-Versionen testen darf, die auf der Webseite noch gar nicht angeboten werden. Aber auch hier: Cooles Produkt für den „fortgeschrittenen Otto-Normal-User“ aber ich befürchte, dass mein Setup so langsam die Möglichkeiten des FritzOS an seine Grenzen bringt. Ich habe z.B. auch das schwerwiegende Problem, dass die FritzBox virtuelle Geräte aus meinem Docker MacVLAN beim PC-Neustart als inaktiv erkennt und dann die Portweiterleitung für IPv4 nicht (oder zumindest nicht richtig) aktiviert wird. Das führt dann dazu, dass mein Stalwart Mail-Server via TSL nicht erreichbar ist und ich muss die Kiste x-mal neustarten und z.B. mit wget usw. künstlich Traffic aus dem Docker Container heraus generieren, bis es auf wundersame Weise funktioniert. Aber auch hier… andere Geschichte.

Hallo @b_s101 ,

das ist sicher eine gute Idee und genau so eine konkrete Einstellung habe ich gesucht aber nicht gefunden (evtl. auch übersehen). Kannst du mir genau sagen, wo ich das in Windows einstellen kann?

Was ich so herausgefunden habe, ist, dass Windows scheinbar sowas lernt. Möglicherweise war der Pfad ins Verderben, dass ich eine URL per nslookup anfragen wollte, die kein DNS auflösen konnte (evtl. nur temporär). Dann hat sich das dieses Suffix .fritz.box dazu gemogelt und AdGuard hat zwar mit einer (bewusst) falschen aber validen IP geantwortet und Windows hat das aus Erfolg „gelernt“ und hängt nun, wenn es in meinem Heimnetz unterwegs ist diesen Suffix immer an.

Danke und Grüße
Mic.

https://praxistipps.chip.de/dns-suffix-aendern-so-gehts_3217

Das was @markusonwheels da verlinkt hat, ändert das Suffix grundsätzlich. Man kann das auch verbindungsspezifisch machen. Systemsteuerung → Netzwerk- und Freigabecenter → links auf Adaptereinstellungen → Rechtsklick auf die Eigenschaften der aktiven LAN Verbindung → Internetprotokoll IPv4 → Eigenschaften → erweitert… → DNS → „Diese DNS Suffixe anhängen (Reihenfolge)“ auswählen und nichts eintragen.
Dann mit fertig, speichern, usw. übernehmen und den Rechner einmal durchstarten. Dann sollte kein DNS Suffix mehr angehängt werden.

1 Like

Hallo,

danke für eure Tipps. Als ich meinen PC heute Nachmittag hochfuhr, habe ich testweise AdGuard Home wieder zurück gestellt und für ein paar kurze Versuche mit nslookup funktionierte tatsächlich alles wieder. Dann war der Fehler aber wieder da…

Was die Einstellungen angeht, ich sagte doch, ich habe die Einstellung echt übersehen. Sie ist wirklich gut versteckt. Entspechend der Anleitung von @b_s101 kam ich zu folgendem Fenster und habe dort den Haken bei Übergeordneten Suffix des primären DNS-Suffix anhängen entfernt. Seit dem scheint es zu funktionieren und ich bekomme mit nslookup wieder plausinle Antworten (bei internem DNS und bei externem DNS).

Diese Einstellung scheint dann für alle Ethernet-Adapter und sowohl für IPv4 als auch für IPv6 zu wirken.

Ob dieser Haken die ganzen Jahre immer gesetzt oder nicht gesetzt war, kann ich leider nicht sagen. Was für einen praktischen Nutzen (Sinn) hat dieses Anhängen eines Suffix eigentlich?

Die Einstellung in der Anleitung von @markusonwheels war bei mir schon leer:

Was sagt ihr, meinen Workaround in AdGuard Home werde ich aber trotzdem drin lassen… falls sich Windows mal wieder “verschluckt”.

Danke und Grüße
Mic.

1 Like