AdGuard mit Unbound

Bannister0946

Lt. Junior Grade
Registriert
Nov. 2021
Beiträge
325
Hallo zusammen,

ich habe seit kurzem Adguard bei mir im Einsatz.

IST Situation:
Fritzbox verteilt via DHCP die Adguard IP als DNS Server an die Clients.

Wenn ich es richtig verstanden habe, läuft es aktuell wie folgt ab:

Client > AdGuard > falls nichts im Cache von AdGuard vorhanden ist > Anfrage an Upstream Server (welche in Adguard hinterlegt sind)

Korrigiert mich bitte, falls ich bis hierhin schon etwas falsch verstanden habe.
Nun habe ich einiges über Unbound als Upstream Server gelesen.

Macht das Sinn?
Wie würde hier der Ablauf sein?
Welche Vorteile hätte ich durch Unbound?
Welche Nachteile?
 
Vorteil mit Unbound ist, dass du eben keinen externen Upstream-Server mehr brauchst. Du machst dann das, was die Upstream-Server auch machen. Du löst Anfragen rekursiv über die DNS-Root-Server auf und cached die Antworten.

Zusätzlich kannst du Unbound auch anweisen, die komplette Root-Zone lokal vorzuhalten, indem du eine entsprechende Konfiguration in /etc/unbound/unbound.conf.d/ erstellst. Das nennt sich Hyperlocal:

Code:
root@omnia:~# cat /etc/unbound/unbound.conf.d/root-zone.conf
# =========================================================
# Auth Zone for the Internet root zone "."
# See RFC 8806 - Running a Root Server Local to a Resolver
# https://www.rfc-editor.org/rfc/rfc8806.html
# =========================================================
auth-zone:
    name: "."
    master: "b.root-servers.net"
    master: "c.root-servers.net"
    master: "d.root-servers.net"
    master: "f.root-servers.net"
    master: "g.root-servers.net"
    master: "k.root-servers.net"
    url: https://www.internic.net/domain/root.zone
    fallback-enabled: yes
    for-downstream: no
    for-upstream: yes
    zonefile: "/var/etc/unbound/root.zone"
 
Zuletzt bearbeitet:
Natürlich ist das nicht notwendig. AdGuard funktioniert auch ohne Unbound. Den Vorteil mit Unbound habe ich oben erklärt.

Was er da schreibt, ist aber dennoch völlig falsch.

Die Root-Server werden genauso von Firmen betrieben wie die Resolver. Und natürlich könnten die die Daten genauso auswerten wie die Betreiber von Resolvern. Wenn du also die Root-Server statt irgendeines DNS-Resolvers von Google, Cloudflare oder deines Providers fragst, dann bekommen halt im Zweifelsfall einfach andere Leute deine Daten.

Die Root-Server sehen nicht, welche Domain du aufrufst. Die fragst du nur, wer für die entsprechende TLD zuständig ist, z.B. .de. Welche Domain du am Ende aufrufen willst, beantwortet dir der Nameserver, der für diese Domain zuständig ist. Somit kann niemand alle deine Anfragen loggen.

Das Stichwort hier lautet QNAME minimization.
 
  • Gefällt mir
Reaktionen: DFFVB und Bannister0946
Viel musst du da gar nicht konfigurieren. Das Hyperlocal habe ich wie oben beschrieben konfiguriert.

qname-minimisation: yes muss eben auch eingeschaltet sein. Kann sein, dass das schon per default konfiguriert ist.
 
Habe im Netz eine .conf Datei gefunden, welche diesen Inhalt aktuell nutzt.
Siehst du hier etwas, was man "verbessern" kann?

server:
###########################################################################
# BASIC SETTINGS
###########################################################################
# Time to live maximum for RRsets and messages in the cache. If the maximum
# kicks in, responses to clients still get decrementing TTLs based on the
# original (larger) values. When the internal TTL expires, the cache item
# has expired. Can be set lower to force the resolver to query for data
# often, and not trust (very large) TTL values.
cache-max-ttl: 86400
do-ip6: no
local-zone: ip6.arpa. refuse
prefer-ip6: no

# Time to live minimum for RRsets and messages in the cache. If the minimum
# kicks in, the data is cached for longer than the domain owner intended,
# and thus less queries are made to look up the data. Zero makes sure the
# data in the cache is as the domain owner intended, higher values,
# especially more than an hour or so, can lead to trouble as the data in
# the cache does not match up with the actual data any more.
cache-min-ttl: 300

# Set the working directory for the program.
directory: "/opt/unbound/etc/unbound"

# RFC 6891. Number of bytes size to advertise as the EDNS reassembly buffer
# size. This is the value put into datagrams over UDP towards peers.
# The actual buffer size is determined by msg-buffer-size (both for TCP and
# UDP). Do not set higher than that value.
# Default is 1232 which is the DNS Flag Day 2020 recommendation.
# Setting to 512 bypasses even the most stringent path MTU problems, but
# is seen as extreme, since the amount of TCP fallback generated is
# excessive (probably also for this resolver, consider tuning the outgoing
# tcp number).
edns-buffer-size: 1232

# Listen to for queries from clients and answer from this network interface
# and port.
interface: 0.0.0.0@5355

# Rotates RRSet order in response (the pseudo-random number is taken from
# the query ID, for speed and thread safety).
rrset-roundrobin: yes

# Drop user privileges after binding the port.
username: "_unbound"

###########################################################################
# LOGGING
###########################################################################

# Do not print log lines to inform about local zone actions
log-local-actions: no

# Do not print one line per query to the log
log-queries: no

# Do not print one line per reply to the log
log-replies: no

# Do not print log lines that say why queries return SERVFAIL to clients
log-servfail: no

# Further limit logging
logfile: /dev/null

# Only log errors
verbosity: 0

###########################################################################
# PRIVACY SETTINGS
###########################################################################

# RFC 8198. Use the DNSSEC NSEC chain to synthesize NXDO-MAIN and other
# denials, using information from previous NXDO-MAINs answers. In other
# words, use cached NSEC records to generate negative answers within a
# range and positive answers from wildcards. This increases performance,
# decreases latency and resource utilization on both authoritative and
# recursive servers, and increases privacy. Also, it may help increase
# resilience to certain DoS attacks in some circumstances.
aggressive-nsec: yes

# Extra delay for timeouted UDP ports before they are closed, in msec.
# This prevents very delayed answer packets from the upstream (recursive)
# servers from bouncing against closed ports and setting off all sort of
# close-port counters, with eg. 1500 msec. When timeouts happen you need
# extra sockets, it checks the ID and remote IP of packets, and unwanted
# packets are added to the unwanted packet counter.
delay-close: 10000

# Prevent the unbound server from forking into the background as a daemon
do-daemonize: no

# Add localhost to the do-not-query-address list.
do-not-query-localhost: no

# Number of bytes size of the aggressive negative cache.
neg-cache-size: 4M

# Send minimum amount of information to upstream servers to enhance
# privacy (best privacy).
qname-minimisation: yes

###########################################################################
# SECURITY SETTINGS
###########################################################################
# Only give access to recursion clients from LAN IPs
access-control: 127.0.0.1/32 allow
access-control: 192.168.0.0/16 allow
access-control: 172.16.0.0/12 allow
access-control: 10.0.0.0/8 allow

# File with trust anchor for one zone, which is tracked with RFC5011
# probes.
auto-trust-anchor-file: "var/root.key"

# Enable chroot (i.e, change apparent root directory for the current
# running process and its children)
chroot: "/opt/unbound/etc/unbound"

# Deny queries of type ANY with an empty response.
deny-any: yes

# Harden against algorithm downgrade when multiple algorithms are
# advertised in the DS record.
harden-algo-downgrade: yes

# RFC 8020. returns nxdomain to queries for a name below another name that
# is already known to be nxdomain.
harden-below-nxdomain: yes

# Require DNSSEC data for trust-anchored zones, if such data is absent, the
# zone becomes bogus. If turned off you run the risk of a downgrade attack
# that disables security for a zone.
harden-dnssec-stripped: yes

# Only trust glue if it is within the servers authority.
harden-glue: yes

# Ignore very large queries.
harden-large-queries: yes

# Perform additional queries for infrastructure data to harden the referral
# path. Validates the replies if trust anchors are configured and the zones
# are signed. This enforces DNSSEC validation on nameserver NS sets and the
# nameserver addresses that are encountered on the referral path to the
# answer. Experimental option.
harden-referral-path: no

# Ignore very small EDNS buffer sizes from queries.
harden-short-bufsize: yes

# If enabled the HTTP header User-Agent is not set. Use with caution
# as some webserver configurations may reject HTTP requests lacking
# this header. If needed, it is better to explicitly set the
# the http-user-agent.
hide-http-user-agent: no

# Refuse id.server and hostname.bind queries
hide-identity: yes

# Refuse version.server and version.bind queries
hide-version: yes

# Set the HTTP User-Agent header for outgoing HTTP requests. If
# set to "", the default, then the package name and version are
# used.
http-user-agent: "DNS"

# Report this identity rather than the hostname of the server.
identity: "DNS"

# These private network addresses are not allowed to be returned for public
# internet names. Any occurrence of such addresses are removed from DNS
# answers. Additionally, the DNSSEC validator may mark the answers bogus.
# This protects against DNS Rebinding
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: fd00::/8
private-address: fe80::/10
private-address: ::ffff:0:0/96

# Enable ratelimiting of queries (per second) sent to nameserver for
# performing recursion. More queries are turned away with an error
# (servfail). This stops recursive floods (e.g., random query names), but
# not spoofed reflection floods. Cached responses are not rate limited by
# this setting. Experimental option.
ratelimit: 1000

# Use this certificate bundle for authenticating connections made to
# outside peers (e.g., auth-zone urls, DNS over TLS connections).
tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

# Set the total number of unwanted replies to eep track of in every thread.
# When it reaches the threshold, a defensive action of clearing the rrset
# and message caches is taken, hopefully flushing away any poison.
# Unbound suggests a value of 10 million.
unwanted-reply-threshold: 10000

# Use 0x20-encoded random bits in the query to foil spoof attempts. This
# perturbs the lowercase and uppercase of query names sent to authority
# servers and checks if the reply still has the correct casing.
# This feature is an experimental implementation of draft dns-0x20.
# Experimental option.
use-caps-for-id: yes

# Help protect users that rely on this validator for authentication from
# potentially bad data in the additional section. Instruct the validator to
# remove data from the additional section of secure messages that are not
# signed properly. Messages that are insecure, bogus, indeterminate or
# unchecked are not affected.
val-clean-additional: yes

###########################################################################
# PERFORMANCE SETTINGS
###########################################################################
# https://nlnetlabs.nl/documentation/unbound/howto-optimise/
# https://nlnetlabs.nl/news/2019/Feb/05/unbound-1.9.0-released/

# Number of slabs in the infrastructure cache. Slabs reduce lock contention
# by threads. Must be set to a power of 2.
infra-cache-slabs: 2

# Number of incoming TCP buffers to allocate per thread. Default
# is 10. If set to 0, or if do-tcp is "no", no TCP queries from
# clients are accepted. For larger installations increasing this
# value is a good idea.
incoming-num-tcp: 10

# Number of slabs in the key cache. Slabs reduce lock contention by
# threads. Must be set to a power of 2. Setting (close) to the number
# of cpus is a reasonable guess.
key-cache-slabs: 2

# Number of bytes size of the message cache.
# Unbound recommendation is to Use roughly twice as much rrset cache memory
# as you use msg cache memory.
msg-cache-size: 812444330

# Number of slabs in the message cache. Slabs reduce lock contention by
# threads. Must be set to a power of 2. Setting (close) to the number of
# cpus is a reasonable guess.
msg-cache-slabs: 2

# The number of queries that every thread will service simultaneously. If
# more queries arrive that need servicing, and no queries can be jostled
# out (see jostle-timeout), then the queries are dropped.
# This is best set at half the number of the outgoing-range.
# This Unbound instance was compiled with libevent so it can efficiently
# use more than 1024 file descriptors.
num-queries-per-thread: 4096

# The number of threads to create to serve clients.
# This is set dynamically at run time to effectively use available CPUs
# resources
num-threads: 2

# Number of ports to open. This number of file descriptors can be opened
# per thread.
# This Unbound instance was compiled with libevent so it can efficiently
# use more than 1024 file descriptors.
outgoing-range: 8192

# Number of bytes size of the RRset cache.
# Use roughly twice as much rrset cache memory as msg cache memory
rrset-cache-size: 1624888661

# Number of slabs in the RRset cache. Slabs reduce lock contention by
# threads. Must be set to a power of 2.
rrset-cache-slabs: 2

# Do no insert authority/additional sections into response messages when
# those sections are not required. This reduces response size
# significantly, and may avoid TCP fallback for some responses. This may
# cause a slight speedup.
minimal-responses: yes

# # Fetch the DNSKEYs earlier in the validation process, when a DS record
# is encountered. This lowers the latency of requests at the expense of
# little more CPU usage.
prefetch: yes

# Fetch the DNSKEYs earlier in the validation process, when a DS record is
# encountered. This lowers the latency of requests at the expense of little
# more CPU usage.
prefetch-key: yes

# Have unbound attempt to serve old responses from cache with a TTL of 0 in
# the response without waiting for the actual resolution to finish. The
# actual resolution answer ends up in the cache later on.
serve-expired: yes

# Open dedicated listening sockets for incoming queries for each thread and
# try to set the SO_REUSEPORT socket option on each socket. May distribute
# incoming queries to threads more evenly.
so-reuseport: yes

# file to read root hints from.
root-hints: "/opt/unbound/etc/unbound/root.hints"

###########################################################################
# LOCAL ZONE
###########################################################################

# Include file for local-data and local-data-ptr
include: /opt/unbound/etc/unbound/a-records.conf
include: /opt/unbound/etc/unbound/srv-records.conf

###########################################################################
# FORWARD ZONE
###########################################################################

include: /opt/unbound/etc/unbound/forward-records.conf


forward-zone:
name: "."
forward-tls-upstream: yes


# Quad9
forward-addr: 9.9.9.9@853#dns.quad9.net
forward-addr: 149.112.112.112@853#dns.quad9.net


remote-control:
control-enable: no
 
Wenn du Quad9 als Upstream nutzen möchtest, brauchst du kein Unbound. Dann kannst du den auch einfach gleich in AdGuard konfigurieren.

Aber du willst doch sowieso selbst rekursiv auflösen. Warum willst du da irgendwas verschlüsseln?

Mir scheint, also solltest du dich erst noch mal genauer in das Thema einarbeiten, bevor du da irgendwas aufsetzt.
 
naja, deswegen frage ich hier ja nach um mir unterstützung zu holen. wenn ich es wüsste, bräuchte ich ja nicht fragen ;)

Aber du willst doch sowieso selbst rekursiv auflösen. Warum willst du da irgendwas verschlüsseln?

Also ist eine Verschlüsselung nicht notwendig?
 
Naja, was hast du denn vor? Möchtest du verhindern, dass dein ISP deinen DNS-Traffic per Deep Packet Inspection mitlesen kann? Dann musst du ihn verschlüsseln. Das Szenario ist aber wohl eher unwahrscheinlich.

Oder möchtest du verhindern, dass dein DNS-Traffic an zentraler Stelle mitgeloggt werden kann? Dann musst du selbst rekursiv mit qname-minimisation auflösen. Dann brauchst du auch nix verschlüsseln.
 
Na dann fang doch einfach mal mit der Default Config an, konfiguriere Hyperlocal und stelle sicher, dass qname-minimisation aktiv ist. Die Default Config ist die, die nach der Installation auf der Platte liegt.
 
habe oben die die default config gepostet, welche mit dem docker image zusammen kommt.

qname-minimisation: yes (erledigt)

hat hyperlocal Nachteile?
 
Kurzer Zwischenstand:
Habe jetzt Adguard mit Unbound laufen (ohne upstream Server).

Bildschirmfoto 2023-10-06 um 08.34.52.png

Diese Dateien stehen mir aktuell zur Verfügung, welche von Unbound genutzt werden (könnten).
Alle sind bislang leer, bis auf unbound.conf und root.hints (habe ich beide mal .txt angehangen)

Nun zwei Fragen:

in der .conf habe ich folgenden Absatz:

# Listen to for queries from clients and answer from this network interface
# and port.
interface: 0.0.0.0@5355
port: 5355

Muss bei interface überhaupt @5355 stehen ,wenn es dort extra den Parameter "Port" gibt?


# Only give access to recursion clients from LAN IPs
access-control: 127.0.0.1/32 allow
access-control: 192.168.0.0/16 allow
access-control: 172.16.0.0/12 allow
access-control: 10.0.0.0/8 allow
access-control: fc00::/7 allow
access-control: ::1/128 allow

Könnte ich hier nicht auch nur den folgenden Eintrag nutzen (IP von Adguard)
access-control: 192.168.178.250/32 allow

Damit würde ich doch realisieren, das NUR Adguard Anfragen in Richtung unbound stellen darf und nicht ein Client direkt an unbound geht (ohne Adguard), oder?

###

Dann würde ich gerne auch auf hyperlocal "umstellen".
Habe leider immer noch nicht verstanden, wie ich das realisieren muss, bei meiner jetzigen Strukur.
Kann mir da jemand unter die Arme greifen? Hatte auch schon beim Docker Image "Ersteller" angefragt.
Dieser sagt aber auch nur: Ich stelle unbound als Image zur Verfügung. Konfigurationen o.ä. soll ich der unbound docu / Foren / ... entnehmen.
 

Anhänge

Das @5355 sollte nicht nötig sein.

Bannister0946 schrieb:
Könnte ich hier nicht auch nur den folgenden Eintrag nutzen (IP von Adguard)

Vermutlich. Probier es halt aus.

Bannister0946 schrieb:
Dann würde ich gerne auch auf hyperlocal "umstellen".
Habe leider immer noch nicht verstanden, wie ich das realisieren muss, bei meiner jetzigen Strukur.

Habe ich doch oben beschrieben. Du legst eine neue Datei unter /etc/unbound/unbound.conf.d/ an.

In der unbound.conf sollte es eine Zeile include: "/etc/unbound/unbound.conf.d/*.conf" geben, die alle .conf Dateien in dem Verzeichnis inkludiert. Du kannst es natürlich auch direkt in die unbound.conf schreiben. So ist es aber sauberer.

Ausprobieren, Logs lesen ;)
 
so, die ersten Punkte habe ich nun probiert und es klappt.
Nun noch mal zu meinem Endgegner "hyperlocal":

wenn ich mir deine Antwort ansehe, verstehe ich einigermaßen was dort passiert, allerdings muss ich es auf meine Struktur (welche auf Grund des Docker Images eine andere ist) "umwandeln".

Habe eben gesehen, das mein unbound folgendes loggt:
no config, using builtin root hints.

Dazu habe ich dann folgenden Artikel gefunden:
https://wiki.archlinux.org/title/unbound#Root_hints

Heißt doch: Ich habe eine roots.hints Datei, welcher aber lt. Config nicht genutzt wird.
Somit müsste ich doch meine unbound.conf nur um diesen Eintrag ersetzen:

root-hints: root.hints

Wäre damit das Thema "Hyperlocal" nicht gelöst?
Ergänzung ()

Habe es gerade mal umgesetzt.
Sieht doch lt. logs nicht verkehrt aus, oder?

[1696581566] unbound[1:2] debug: Reading root hints from root.hints
[1696581566] unbound[1:2] info: DelegationPoint<.>: 13 names (0 missing), 26 addrs (0 result, 26 avail) parentNS
[1696581566] unbound[1:2] info: M.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:2] info: L.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:2] info: K.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:2] info: J.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:2] info: I.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:2] info: H.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:2] info: G.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:2] info: F.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:2] info: E.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:2] info: D.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:2] info: C.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:2] info: B.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:2] info: A.ROOT-SERVERS.NET. * A AAAA
[1696581566] unbound[1:1] debug: ip6 2001:dc3::35 port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 202.12.27.33 port 53 (len 16)
[1696581566] unbound[1:1] debug: ip6 2001:500:9f::42 port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 199.7.83.42 port 53 (len 16)
[1696581566] unbound[1:1] debug: ip6 2001:7fd::1 port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 193.0.14.129 port 53 (len 16)
[1696581566] unbound[1:1] debug: ip6 2001:503:c27::2:30 port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 192.58.128.30 port 53 (len 16)
[1696581566] unbound[1:1] debug: ip6 2001:7fe::53 port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 192.36.148.17 port 53 (len 16)
[1696581566] unbound[1:1] debug: ip6 2001:500:1::53 port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 198.97.190.53 port 53 (len 16)
[1696581566] unbound[1:1] debug: ip6 2001:500:12::d0d port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 192.112.36.4 port 53 (len 16)
[1696581566] unbound[1:1] debug: ip6 2001:500:2f::f port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 192.5.5.241 port 53 (len 16)
[1696581566] unbound[1:1] debug: ip6 2001:500:a8::e port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 192.203.230.10 port 53 (len 16)
[1696581566] unbound[1:1] debug: ip6 2001:500:2d::d port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 199.7.91.13 port 53 (len 16)
[1696581566] unbound[1:1] debug: ip6 2001:500:2::c port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 192.33.4.12 port 53 (len 16)
[1696581566] unbound[1:1] debug: ip6 2001:500:200::b port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 199.9.14.201 port 53 (len 16)
[1696581566] unbound[1:1] debug: ip6 2001:503:ba3e::2:30 port 53 (len 28)
[1696581566] unbound[1:1] debug: ip4 198.41.0.4 port 53 (len 16)
 
Zuletzt bearbeitet:
Zurück
Oben