149680
04.01.2024
1970
7
0
Aufklärung internes DNS
Hallo Community,
ich habe mal eine Frage zur Funktionsweise meines DNS Setups.
Folgendes Scenario ist bei mir eingerichtet:
In den DNS settings von AdGuard ist eingetragen:
https://dns.quad9.net/dns-query
https://cloudflare-dns.com/dns-query
[/int.lan/]192.168.200.101
Zeile drei entsprechend für alle internen Anfragen. Des Weiteren ist für die Abfrageart: Load-balancing aktiviert.
Was ist von meiner Logik verstehe und in den Logs sehe ist, dass alle Anfragen mit *.int.lan intern direkt auf dem AdGuard (192.168.200.101) aufgelöst werden. Heißt externe DNS Server werden nicht angefragt. Im Umkehrschluss bedeutet dies doch auch: Fällt meine Internetverbindung aus, Provider Probleme, HomeBox kaputt, Kabelabgerissen etc. sollten alle meine internen Services per DNS erreichbar sein, da dies rein gar nichts mit dem "Internet" zu tun haben. Ist das soweit richtig?
Vor einigen Tagen habe ich beobachtet, dass alle meine Services per DNS nicht erreichbar waren shh per IP aber ohne Probleme lief. Es stellte sich heraus, dass tatsächlich mein "Internet Kabel" defekt war, somit war natürlich auch keine Verbindung nach Außen möglich was ja aber eignetlich für meine internen DNS Anfragen völlig egal sein sollte. Am Ende habe ich meine HomeBox komplett vom Strom getrennt und den AdGuard restartet. Dann lief auch intern alles wie erwartet und ohne Probleme.
Ich erkläre mit das Verhalten so, dass die beiden Einträge:
https://dns.quad9.net/dns-query
https://cloudflare-dns.com/dns-query
auch für interne Anfragen auf Grund der Einstellung: Load-balancing angefragt wurden und dadurch ein relativ langer time-out entstand der dafür sorgte das auch interne Anfragen nicht mehr ausgeführt wurden. Was ich mich Frage?
a) ist die Erklörung richtig?
b) Warum ist das so? Dachte eigentlich mit dem obigen setup wird eben nichts nach außen gesendet wenn *.int.lan auftaucht - gehen jetzt doch interne Anfragen nach extern?
c) was müsste ich in meinem Setup ändern damit auch bei einem Ausfall des "internets" alles ohne die restart und Strom aus Prozedur funktioniert?
Danke euch für Ideen.
ich habe mal eine Frage zur Funktionsweise meines DNS Setups.
Folgendes Scenario ist bei mir eingerichtet:
- AdGuardHome als interner DNS auf einem LXC in Proxmox
- Clients sind ebenfalls in AdGuard eingetragen
- Rewrites werden ebenfalls per AdGuard gesteuert
- Nginx als reverse Proxy für die internen Services
In den DNS settings von AdGuard ist eingetragen:
https://dns.quad9.net/dns-query
https://cloudflare-dns.com/dns-query
[/int.lan/]192.168.200.101
Zeile drei entsprechend für alle internen Anfragen. Des Weiteren ist für die Abfrageart: Load-balancing aktiviert.
Was ist von meiner Logik verstehe und in den Logs sehe ist, dass alle Anfragen mit *.int.lan intern direkt auf dem AdGuard (192.168.200.101) aufgelöst werden. Heißt externe DNS Server werden nicht angefragt. Im Umkehrschluss bedeutet dies doch auch: Fällt meine Internetverbindung aus, Provider Probleme, HomeBox kaputt, Kabelabgerissen etc. sollten alle meine internen Services per DNS erreichbar sein, da dies rein gar nichts mit dem "Internet" zu tun haben. Ist das soweit richtig?
Vor einigen Tagen habe ich beobachtet, dass alle meine Services per DNS nicht erreichbar waren shh per IP aber ohne Probleme lief. Es stellte sich heraus, dass tatsächlich mein "Internet Kabel" defekt war, somit war natürlich auch keine Verbindung nach Außen möglich was ja aber eignetlich für meine internen DNS Anfragen völlig egal sein sollte. Am Ende habe ich meine HomeBox komplett vom Strom getrennt und den AdGuard restartet. Dann lief auch intern alles wie erwartet und ohne Probleme.
Ich erkläre mit das Verhalten so, dass die beiden Einträge:
https://dns.quad9.net/dns-query
https://cloudflare-dns.com/dns-query
auch für interne Anfragen auf Grund der Einstellung: Load-balancing angefragt wurden und dadurch ein relativ langer time-out entstand der dafür sorgte das auch interne Anfragen nicht mehr ausgeführt wurden. Was ich mich Frage?
a) ist die Erklörung richtig?
b) Warum ist das so? Dachte eigentlich mit dem obigen setup wird eben nichts nach außen gesendet wenn *.int.lan auftaucht - gehen jetzt doch interne Anfragen nach extern?
c) was müsste ich in meinem Setup ändern damit auch bei einem Ausfall des "internets" alles ohne die restart und Strom aus Prozedur funktioniert?
Danke euch für Ideen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 72479945441
Url: https://administrator.de/forum/aufklaerung-internes-dns-72479945441.html
Ausgedruckt am: 05.02.2025 um 04:02 Uhr
7 Kommentare
Neuester Kommentar
Nabend.
Du musst deinem internen DNS feste Einträge spendieren, welche den FQDN und die IP Adresse enthalten.
DNS Host Overrides nennen das Manche, statische DNS Einträge Andere.
Dann klappt die interne Auflösung immer, auch wenn das Internet nicht verfügbar ist.
Es macht ja auch wenig Sinn einen internen Host von intern über das Internet erreichen zu wollen (außer zu Testzwecken vielleicht).
Edit:
https://medium.com/@life-is-short-so-enjoy-it/homelab-adguard-adding-loc ...
Gruß
Marc
Du musst deinem internen DNS feste Einträge spendieren, welche den FQDN und die IP Adresse enthalten.
DNS Host Overrides nennen das Manche, statische DNS Einträge Andere.
Dann klappt die interne Auflösung immer, auch wenn das Internet nicht verfügbar ist.
Es macht ja auch wenig Sinn einen internen Host von intern über das Internet erreichen zu wollen (außer zu Testzwecken vielleicht).
Edit:
https://medium.com/@life-is-short-so-enjoy-it/homelab-adguard-adding-loc ...
Gruß
Marc
ok, danke dir.
so wie ich den Artikel verstehe ist das Vorgehen genau dass was ich auch gemacht habe. Jedenfalls für service namen wie nextcloud.int.lan die dann auf die IP des reverse proxy zeigen.
Müssen dort dann auch alle anderen Namen, also reine hostnames rein die ich aktuell unter Client names Pflege rein?
Und was ist mit dem Eintrag: [/int.lan/]192.168.200.101 wird der überhaupt benötigt oder ggf. nur wenn ein anderer DNS wie zb Bind oder so genutzt wird?
Was ich nicht verstanden habe ist warum nach eine restart und ausschalten der homebox eben alles intern funktioniert aber nicht vorher
so wie ich den Artikel verstehe ist das Vorgehen genau dass was ich auch gemacht habe. Jedenfalls für service namen wie nextcloud.int.lan die dann auf die IP des reverse proxy zeigen.
Müssen dort dann auch alle anderen Namen, also reine hostnames rein die ich aktuell unter Client names Pflege rein?
Und was ist mit dem Eintrag: [/int.lan/]192.168.200.101 wird der überhaupt benötigt oder ggf. nur wenn ein anderer DNS wie zb Bind oder so genutzt wird?
Was ich nicht verstanden habe ist warum nach eine restart und ausschalten der homebox eben alles intern funktioniert aber nicht vorher
Moin,
Gruß,
Dani
[/int.lan/]192.168.200.101
handelt es sich bei 192.168.200.101 um deinen DNS-Server, welche die Zone int.lan. verwaltet? Wenn dem so ist, sollte eigentlich der Parameter "Private reverse DNS servers" für dich das Richtige sein.Gruß,
Dani
Hi,
exakt so ist es. Entsprechend ist auch der "Private reverse..." mit 192.168.200.101 ausgefüllt oder muss hier der komplette Eintrag [/int.lan/]192.168.200.101 rein? Wenn ich die Doku von AdGuard da richtig lese soll dies aber in die public upstream server und die IP entsprechend in den private reverse.
Mir scheint so weit eigentlich alles korrekt.
handelt es sich bei 192.168.200.101 um deinen DNS-Server, welche die Zone int.lan. verwaltet? Wenn dem so ist, sollte eigentlich der Parameter "Private reverse DNS servers" für dich das Richtige sein.
exakt so ist es. Entsprechend ist auch der "Private reverse..." mit 192.168.200.101 ausgefüllt oder muss hier der komplette Eintrag [/int.lan/]192.168.200.101 rein? Wenn ich die Doku von AdGuard da richtig lese soll dies aber in die public upstream server und die IP entsprechend in den private reverse.
Mir scheint so weit eigentlich alles korrekt.
Moin,
ich kann deiner Beschreibung - wieder einmal - nicht folgen. Poste am Besten Screenshots, damit wir visuell sehen können, wo du was eingetragen hast.
Gruß,
Dani
ich kann deiner Beschreibung - wieder einmal - nicht folgen. Poste am Besten Screenshots, damit wir visuell sehen können, wo du was eingetragen hast.
Wenn ich die Doku von AdGuard da richtig lese soll dies aber in die public upstream server und die IP entsprechend in den private reverse.
Link?Gruß,
Dani
die DOku and er ich mich orientiere ist diese hier: AdGuard Github
Ich würde dieses Thema erstmal parken wollen - villeicht hängt es aber auch mit dem folgenden Beobachtungen zusammen.
Vor kurzem habe ich mir eine Nexctcloud VM erstellt. Aktuell habe ich einige Fehler im Log wie zb:
oder
Diese Fehler treten meist direkt nach einem Login auf. GLeichzeitig sehe ich im AdGuard Log meist 30,40 oder mehrere Einträge die versuchen auf z.B.: www.startpage.com.int.lan oder www.nextcloud.com.int.lan zuzugreifen. Ich vermute hier einen Zusammenhang. Da die DNS queries von der NExtcloud Instanz produziert werden, aber manchmal auch direkt von dem AdGuard lxc selber.
Die /etc/systemd/resolved.conf sieht auf beiden Mashinen so aus:
Dabei spielt es gefühlt keine Rolle ob die beiden nicht kommentierten Zeilen mit # oder # nutze. DIe EInträge bleiben im AdGuardlog und darauß folgen wohl die Fehler in Nextcloud.
Wie oben beschrieben sehen die AdGuard Einträge wie folgt aus:
Ich habe aktuell leider überhaupt keine Idee woher das kommt und wo ich da ansetzten kann. Hat jemand eine Richtung für mich?
Ich würde dieses Thema erstmal parken wollen - villeicht hängt es aber auch mit dem folgenden Beobachtungen zusammen.
Vor kurzem habe ich mir eine Nexctcloud VM erstellt. Aktuell habe ich einige Fehler im Log wie zb:
dns_get_record(): A temporary server error occurred. at /var/www/nextcloud/lib/private/Http/Client/DnsPinMiddleware.php#111 oder
LocalServerException No DNS record found for www.startpage.com
Cannot connect to: www.startpage.com Diese Fehler treten meist direkt nach einem Login auf. GLeichzeitig sehe ich im AdGuard Log meist 30,40 oder mehrere Einträge die versuchen auf z.B.: www.startpage.com.int.lan oder www.nextcloud.com.int.lan zuzugreifen. Ich vermute hier einen Zusammenhang. Da die DNS queries von der NExtcloud Instanz produziert werden, aber manchmal auch direkt von dem AdGuard lxc selber.
Die /etc/systemd/resolved.conf sieht auf beiden Mashinen so aus:
DNS=192.168.200.101
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
DNSStubListener=no
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=noDabei spielt es gefühlt keine Rolle ob die beiden nicht kommentierten Zeilen mit # oder # nutze. DIe EInträge bleiben im AdGuardlog und darauß folgen wohl die Fehler in Nextcloud.
Wie oben beschrieben sehen die AdGuard Einträge wie folgt aus:
# Upstream DNS
https://dns.quad9.net/dns-query
https://cloudflare-dns.com/dns-query
[/int.lan/]192.168.200.101
# Private reverse DNS servers
192.168.200.101Ich habe aktuell leider überhaupt keine Idee woher das kommt und wo ich da ansetzten kann. Hat jemand eine Richtung für mich?
So, hat sich alles gelöst:
so scheint alles zu laufen. Ich denke darin lag auch der Fehler im Anfangspost.
# Upstream DNS
https://dns.quad9.net/dns-query
https://cloudflare-dns.com/dns-query
[/in-addr.arpa/]192.168.200.101
# Private reverse DNS servers
192.168.200.101so scheint alles zu laufen. Ich denke darin lag auch der Fehler im Anfangspost.
