Hallo,
ich habe mir einen eigenen DNS Server mit unbound als CT in Proxmox aufgesetzt. Leider schaffe ich es nicht, Anfragen zu all-inkl.com aufzulösen. Dass beinhaltet nicht nur all-inkl.com selbst, sondern auch alle meine Domains, welche dort liegen.
Also Status wird SERVFAIL ausgegeben.
Ich kann mir den Fehler nicht erklären. Über DNSforge lässt sich alles wunderbar auflösen. Daheim möchte ich aber selbst meine Listen in AdGuard verwalten 
Gibt es einen Tipp, wie ich den Fehler beheben kann?
dig all-inkl.com @192.168.37.97 -p 5335
; <<>> DiG 9.10.6 <<>> all-inkl.com @192.168.37.97 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47056
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;all-inkl.com. IN A
;; Query time: 406 msec
;; SERVER: 192.168.37.97#5335(192.168.37.97)
;; WHEN: Tue Jan 14 15:05:08 CET 2025
;; MSG SIZE rcvd: 41
Andere Auflösungen funktionieren jedoch
dig adminforge.de @192.168.37.97 -p 5335
; <<>> DiG 9.10.6 <<>> adminforge.de @192.168.37.97 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53216
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;adminforge.de. IN A
;; ANSWER SECTION:
adminforge.de. 60 IN A 176.9.8.206
;; Query time: 156 msec
;; SERVER: 192.168.37.97#5335(192.168.37.97)
;; WHEN: Tue Jan 14 15:07:52 CET 2025
;; MSG SIZE rcvd: 58
Meine Konfiguration in unbound sieht wie folgt aus:
server:
# Wenn keine Logdatei angegeben wird, wird syslog verwendet.
logfile: "/var/log/unbound.log"
verbosity: 0
log-time-ascii: yes
log-queries: no
# Versions-Informationen von Unbound nicht anzeigen - Sicherheitsaspekt
hide-identity: yes
hide-version: yes
interface: 192.168.37.97 #IP Adresse
port: 5335
do-ip4: yes
do-udp: yes
do-tcp: yes
# May be set to yes if you have IPv6 connectivity
do-ip6: yes
# Verwende dies nur, wenn du die Liste der primären Root-Server heruntergeladen hast!
root-hints: "/var/lib/unbound/root.hints"
tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"
# You want to leave this to no unless you have *native* IPv6. With 6to4 and
# Terredo tunnels your web browser should favor IPv4 for the same reasons
prefer-ip6: no
# Trust glue only if it is within the server's authority
harden-glue: yes
# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes
# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no
# Reduce EDNS reassembly buffer size.
# IP fragmentation is unreliable on the Internet today, and can cause
# transmission failures when large DNS messages are sent via UDP. Even
# when fragmentation does work, it may not be secure; it is theoretically
# possible to spoof parts of a fragmented DNS message, without easy
# detection at the receiving end. Recently, there was an excellent study
# >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
# by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
# in collaboration with NLnet Labs explored DNS using real world data from the
# the RIPE Atlas probes and the researchers suggested different values for
# IPv4 and IPv6 and in different scenarios. They advise that servers should
# be configured to limit DNS messages sent over UDP to a size that will not
# trigger fragmentation on typical network links. DNS servers can switch
# from UDP to TCP when a DNS response is too big to fit in this limited
# buffer size. This value has also been suggested in DNS Flag Day 2020.
edns-buffer-size: 1232
# TTL-Grenzen fuer den Cache
#Mindestens 10 Sekunden, laengsten 1 Minuten, der Rest macht Cache von Adguard
cache-min-ttl: 10
cache-max-ttl: 60
# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
prefetch-key: yes
# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
so-rcvbuf: 4m
# Anzahl der Slabs im RRset-Cache. Slabs reduzieren die Sperrkonflikte zwischen den
# Threads. Muss auf eine Potenz von 2 in der Nähe von num-threads gesetzt werden.
msg-cache-slabs: 2
rrset-cache-slabs: 2
infra-cache-slabs: 2
key-cache-slabs: 2
# Cache-Speicher rrset sollte doppelt so groß sein wie msg
msg-cache-size: 50m
rrset-cache-size: 100m
# mehr ausgehende Verbindungen
# hängt von der Anzahl der Kerne ab: 1024/Kerne - 50
#Set the outgoing-range: to as large a value as possible,
#see the sections below on how to overcome the limit of 1024 in total.
#This services more clients at a time.
#With 1 core, try 950. With 2 cores, try 450. With 4 cores try 200.
outgoing-range: 950
# UDP mit Multithreading beschleunigen
so-reuseport: yes
# Ensure privacy of local IP ranges
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
access-control: 192.168.0.0/16 allow
module-config: "iterator"
