Adguard setzt sporadisch aus

[plang.pl]

Das ist tatsächlich komisch. Läuft der AdGuard bei dir im Host-Netz der DS oder in einer bridge?
Eigentlich kommt ja kein Timeout, wenn die Fritte das Netz / Gerät nicht kennt, sondern die antwortet einfach mit "kenn ich nicht"

 

[Ghost108]

im Host Netz

 

[plang.pl]

Das ist schonmal gut. Welcher Container hat die 172.20.0.9?

 

[Ghost108]

das ist nicht nur die .9
es gibt auch die .2, die .4, ...

.9 ist z.b. mein watchtower container

 

[plang.pl]

Du meinst, dass die alle angefragt wurden laut Protokoll?

 

[Ghost108]

korrekt.
ist aber auch logisch, wenn ich mal darüber nachdenke:

Die DNS-Server, die AdGuard Home für lokale PTR-Abfragen verwendet. Diese Server werden verwendet, um die Hostnamen von Clients mit privaten IP-Adressen, z. B. „192.168.12.34“, per inverse DNS-Anfragen aufzulösen. Wenn nicht festgelegt, verwendet AdGuard Home die Adressen der Standard-DNS-Auflöser Ihres Betriebssystems mit Ausnahme der Adressen von AdGuard Home selbst.
AdGuard Home konnte keine geeigneten privaten Invers-DNS-Resolver für dieses System ermitteln.

die 172.x.x.x. ist ja auch eine private Adresse

 

[plang.pl]

Hattest du schon mal getestet, ob das Problem weg ist, wenn du die PTR Abfragen an die Fritte ausschaltest?

 

[Ghost108]

die error Meldungen verschwinden dann, ja
aber ob das mit dem Ausfall zusammenhängt müsste ich beobachten. werde die fritte doch mal rausnehmen.

 

[plang.pl]

Es wäre halt interessant zu wissen, ob die Kombination bei dir mit allen PTR-Anfragen ein Problem hat, oder nur manchmal. Dazu könnte man einfach mal ein paar PTR-Anfragen testweise per cmd / nslookup an den AdGuard stellen und schauen, ob ein Server Fail zurückkommt, oder nicht.

 

[Ghost108]

wenn man sich das iphone als Beispiel nimmt, muss die PTR Anfrage schon mal geklappt haben.
Denn statt der IP sehe ich den DNS Namen des iphones in adguard (iphone.fritz.box).

Somit kann man nicht pauschal sagen, das ALLE Anfragen auf error laufen

 

[plang.pl]

in adguard

Ja, aber an der Stelle stellt ja nur der AdGuard eine PTR-Anfrage an die Fritte. Und nicht ein Gerät eine PTR-Anfrage an den AdGuard und der wiederum an die Fritte. Ich denke, dass dein Problem irgendwas mit letzterer Konstellation zu tun hat

 

[Ghost108]

also ich verstehe die Error Meldung so, das Adguard (.250) die Anfrage an die Fritte (.1) via UDP stellt, um den DNS Namen für mein iPhone herauszufinden. Das wäre ja korrekt, aber dürfte nicht in einen Timeout laufen.

Was haltet ihr denn hier von:
https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration#upstreams-for-rdns


Finde den Artikel allerdings sehr verwirrend (habe mal meinen Senf dazu gegeben):

1. Enter the following into the “Upstream DNS servers” field on the “Settings→ DNS settings” page:
   [/in-addr.arpa/]192.168.8.8
   Bei Upstream Server soll diese Syntax rein (die IP meiner Fritte)
   
   
   
   
2. Enter the following into the “Private reverse DNS servers” field on thesame page below the previous field:
   192.168.8.8
   und bei rDNS nur die IP der Fritte
   

JETZT KOMMT MEINE VERWIRRUNG
NOTE: All upstreams for private ranges must go to the “Private reverseDNS servers” field and not the main “Upstream DNS servers” field. Enteringsomething like [/192.in-addr.arpa/]192.168.8.8 into the main field will haveno effect.
Hier heißt es auf einmal, das alle upstreams in private rDNS müssen und nicht oben in upstreams (wie aber in Schritt 1 beschrieben wird)
Kann sich das jemand erlären?
Ich hätte jetzt gedacht ich lasse bei den upstreams unbound drin und unter rDNS packe ich diese Syntax:
[/192.in-addr.arpa/]192.168.108.1

Das müsste doch dann bewirken, das Anfragen nur dann an die fritte gehen, wenn es eine IP aus dem 192er Netz ist.
Somit keine Container IPs, oder seh ich das falsch?

 

[plang.pl]

Genau das Gleiche wollte ich in dem Moment auch schreiben. Einfach mal den privaten IP-Range in der AdGuard Config anpassen, sodass tatsächlich nur noch dein Heimnetz bei der Fritte angefragt wird: https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration#rdns-private
Als ich die Hostnamauflösung noch drinne hatte, sah es bei mir so aus (keine Probleme):
Upstream DNS-Server:

# unbound
127.0.0.1:5355
# Fritz!Box
[/1.1.10.in-addr.arpa/]10.1.1.1
[/fritz.box/]10.1.1.1

Private Inverse DNS-Server

# unbound
127.0.0.1:5355

 

[Ghost108]

ja, aber du machst du genau das, was lt WIKI nicht gemacht werden soll:

NOTE: All upstreams for private ranges must go to the “Private reverseDNS servers” field and not the main “Upstream DNS servers” field.

 

[plang.pl]

Hä? Aber das eine Feld behandelt ja Reverse Lookups und das andere Forward Lookups. Dein Timeout-Problem hat damit aber denke ich nix zu tun. Denn die Fritte wird ja korrekterweise gefragt, nur hat dann eben einen Timeout.
Das betrifft bei dir aber ja sowohl Clients / Netze, die sie kennen müsste, als auch welche, die sie nicht kennen müsste.
Ich würd die Hostnameauflösung einfach mal ausmachen, um im ersten Schritt sicher zu sein, dass es überhaupt daran hängt.

 

[Ghost108]

verstehe ich zwar nicht, aber egal ...
habe jetzt weder bei den upstreams noch bei rDNS einen Verweis auf die Fritte.
Nur unbound beim upstream.

Seit dem sehe ich jetzt in Adguard auch nur noch die IP Adressen der Clients und nicht die Namen (logisch)
Bei einem nslookup iphone bekomme ich als Response jetzt: NXDOMAIN (auch logisch)

und bislang auch kein error im log

 

[Ghost108]

joa, stand jetzt keine error logs mehr.

 

[plang.pl]

Vielleicht liegt der Fehler auch an der Fritte?
Neuste FritzOS Version installiert?

 

[Ghost108]

ja 7.57

 

[plang.pl]

Das ist ja schon mal die Latest.
Ich hatte ja auch Timeouts, wenn Clients meinen Windows-Server als DNS hinterlegt hatten, der wiederum AdGuard fragt. Ich denke, dass seit dem ich die Fritte aus dem Konstrukt rausgeschmissen habe, ist das Problem weg. 100%ig kann ich es aber nicht sagen, weil ich es nicht mehr so genau geprüft habe.