AdguardHome und DNS Eintrag

Danke für den Hinweis.

Müsste ich Adguard noch einmal installieren, nachdem ich das Problem mit "systemd-resolved" gelöst habe?
 
Ok. Habt ihr eine Erklärung warum mir Adguard dennoch DNS-Anfragen in der Übersicht anzeigt?
 
fantozzi schrieb:
Habt ihr eine Erklärung warum mir Adguard dennoch DNS-Anfragen in der Übersicht anzeigt?
Ich verstehe nicht ganz, was Du meinst. Es ist doch der Sinn vom Adguard-DNS-Server Anfragen zu beantworten. Sonst bräuchtest Du das ja nicht. Dementsprechend schlagen da natürlich auch Anfragen auf. Es wäre ein Hinweis auf Fehlkonfiguration, wenns anders wäre.
 
Hmm...vielleicht stehe ich auf dem Schlauch. Der Port 53, der für DNS Anfragen zuständig ist, scheint derzeit doch belegt zu sein? Somit kann Adguard darauf nicht "lauschen"?
 
fantozzi schrieb:
Der Port 53, der für DNS Anfragen zuständig ist, scheint derzeit doch belegt zu sein? Somit kann Adguard darauf nicht "lauschen"?
Wenn der Port "belegt" ist, dann kann er das nicht. Allerdings sollte Adguard das auch mitteilen.
Außerdem kannst Du ja nachschauen, ob er belegt ist. Die Befehle hatten wir hier doch schon durchgekaut.

Vielleicht solltest Du mal genauer beschreiben, was Du meinst. Wir sehen nicht, was Du siehst. Es ist daher schlecht, wenn Du von Dir ausgehend eine Beschreibung machst.
 
  • Gefällt mir
Reaktionen: CoMo
Wie aus deiner Netstat-Ausgabe ersichtlich ist, bindet der systemd-resolved an das Loopback-Interface (127.0.0.54) auf Port 53. Der AdGuard lauscht bereits auf der 192.168.178.15. Also kann er auf der Adresse auch DNS-Anfragen beantworten.
 
Loopback-Interface (127.0.0.54) sagt mir als Laie natürlich nichts :-(

Wie kann aber AdGuard auf der 192.168.178.15 lauschen, wenn der Port 53 doch offensichtlich belegt ist?
Ergänzung ()

Ich habe in der Shell mal den Befehl "resolvectl status" eingegeben.

Ergebnis:

DNS Server: IP der Fritz Box
DNS local domain

Müsste ich nicht eigentlich die IP 192.168.178.15 richtigerweise erhalten?
 
Zuletzt bearbeitet:
fantozzi schrieb:
Wie kann aber AdGuard auf der 192.168.178.15 lauschen, wenn der Port 53 doch offensichtlich belegt ist?

Weil auf der 192.168.178.15 der Port 53 eben nicht belegt ist. Du solltest dir die Netstat Ausgabe mal genau anschauen und versuchen zu verstehen.

fantozzi schrieb:
Ich habe in der Shell mal den Befehl "resolvectl status" eingegeben.
[...]
fantozzi schrieb:
Müsste ich nicht eigentlich die IP 192.168.178.15 richtigerweise erhalten?

Der DNS-Server kommt per DHCP und vermutlich wird der alte Lease immer noch gültig sein. Warum läuft da überhaupt ein resolved?
 
Es ist eben für einen Laien, der gestern noch nicht einmal wusste was ein DNS-Server ist, nicht leicht zu verstehen :-)

Noch einmal zur Ursprungsfrage...während der Installation von Adguard erhielt ich ja diese Meldung "validating ports listen tcp 0.0.0.0:53 etc..."

Darauf hattest du mir netterweise geantwortet...

"Na irgendein Dienst lauscht da bereits auf Port 53. Zeigt dir der Diese Anleitung Link nicht, wie du vorgehen musst? Ansonsten schau halt mal nach:"

Ich habe es dann so verstanden, ok der Port 53 scheint belegt zu sein...Im Netz gefunden...On Ubuntu this is systemd-resolved.

Ergo kann Adguard auf Port 53 nicht lauschen
 
fantozzi schrieb:
Noch einmal zur Ursprungsfrage...während der Installation von Adguard erhielt ich ja diese Meldung "validating ports listen tcp 0.0.0.0:53 etc..."

0.0.0.0 steht für alle IP-Adressen auf deinem System. Dazu gehören auch die Loopback-Adressen. Und dahin kann AdGuard nicht binden, weil auf 127.0.0.54:453 schon der systemd-resolved läuft. Das hat AdGuard aber offenbar nicht daran gehindert, an die 192.168.178.15:53 zu binden. Da läuft er jetzt und wartet darauf, DNS-Anfragen zu beantworten.
 
Ok verstehe. Systemd-resolved sollte ich aber stoppen, wenn darum geht Unbound zu installieren, richtig?

Über Ipconfig /all kann ich mir die DHCP Lease time anschauen, korrekt?
 
fantozzi schrieb:
Es ist eben für einen Laien, der gestern noch nicht einmal wusste was ein DNS-Server ist, nicht leicht zu verstehen :-)
Das sind natürlich denkbar schlechte Voraussetzungen für sowas. DNS ist essentieller Bestandteil des Netzwerks und des Internets. Wenn du nicht weißt was du da tust, handelst du dir womöglich mehr Probleme ein als dass du welche damit löst. DNS-Fehler sind für einen Großteil der "Mein Internet geht nicht" Threads verantwortlich, weil sie sich u.a. in "Webseite nicht erreichbar" Fehlern im Browser zeigen.
 
  • Gefällt mir
Reaktionen: riversource, andy_m4 und CoMo
Nun ja...mein Satz war jetzt auch vielleicht etwas überspitzt formuliert. Ich habe in den letzten Wochen versucht mich in die Thematik einzuarbeiten. Ich wollte schon immer mehr über den Aufbau eines Netzwerkes etc. in Erfahrung bringen und wissen wie dies und jenes funktioniert. Daher bin ich um jede Hilfe sehr dankbar.
 
Frage:

Muss ich in /etc/systemd/resolved.conf DNS in 127.0.0.1:53 ändern oder reicht es systemd-resolved einfach zu stoppen?
 
Hm...ok, konnte mir noch selbst weiterhelfen.

Jetzt habe ich Unbound installiert und müsste die Datei /etc/unbound/unbound.conf konfigurieren, soweit ich verstanden habe.

Könntet ihr vielleicht mal darüber schauen?

server:
interface: 127.0.0.1
port: 5335

# IPv4 / IPv6-settings
do-ip6: no
do-ip4: yes
do-udp: yes
do-tcp: yes

# Set number of threads to use
num-threads: 4

# Hide DNS Server info
hide-identity: yes
hide-version: yes

# Limit DNS Fraud and use DNSSEC
harden-glue: yes
harden-dnssec-stripped: yes
harden-referral-path: yes
use-caps-for-id: yes
harden-algo-downgrade: yes
qname-minimisation: yes

# Add an unwanted reply threshold to clean the cache and avoid when possible a DNS Poisoning
unwanted-reply-threshold: 10000000

# Minimum lifetime of cache entries in seconds
cache-min-ttl: 300

# Maximum lifetime of cached entries
cache-max-ttl: 14400

# Prefetch
prefetch: yes
prefetch-key: yes

# Optimisations
msg-cache-slabs: 8
rrset-cache-slabs: 8
infra-cache-slabs: 8
key-cache-slabs: 8

# Serve old responses from cache with a TTL of 0 in the response without waiting for the actual resolution to finish | Default: no, 0
serve-expired: yes
serve-expired-ttl: 86400

# Increase memory size of the cache
rrset-cache-size: 256m
msg-cache-size: 128m

# Increase buffer size so that no messages are lost in traffic spikes
so-rcvbuf: 1m

# Private addresses
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10
 
Zurück
Oben