[Gelöst] Unbound vs. postfix reverse hostname lookup

wakko

Member
Hi,
ich habe ein kurioses Problem mit unbound als caching recursive DNS Resolver. Den hatte ich vor einer ganzen Weile installiert damit die DNSBL/WL Lookups vom postscreen/spamassassin nicht immer in die Query-Limits laufen. Das funktioniert auch ziemlich gut, aber heute habe ich ein interessantes Problem gefunden bei dem ich nicht weiter weiß:

Und zwar gibt es eine bestimmte IP für die der unbound kein Ergebnis findet. Da rennt unbound entweder in einen Timeout oder es fehlt die wichtige Zeile mit dem PTR im Ergebnis woraufhin die Mail abgewiesen wird. Das ganze hat nicht mal mit DNSBL/WL zu tun, sondern einfach nur mit dem Reverse Lookup für die sendende IP. Ohne den "Umweg" über unbound wird der Reverse Hostname nämlich ohne Probleme gefunden. Und so wie ich das sehe ist das auch bisher die einzige IP bei der das jemals passiert ist:
So ist die Ausgabe von dig -x ohne unbound (habe als Kommentar die Zeile markiert die bei Verwendung von unbound fehlt)
Code:
$ dig -x 209.51.188.41

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> -x 209.51.188.41
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5731
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;41.188.51.209.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
41.188.51.209.in-addr.arpa. 43112 IN    CNAME   41.0-24.188.51.209.in-addr.arpa.
#
# Mit unbound fehlt diese Zeile:
#
41.0-24.188.51.209.in-addr.arpa. 1713 IN PTR    bluemchen.kde.org.

;; Query time: 3 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)
;; WHEN: Wed Oct 01 19:50:53 CEST 2025
;; MSG SIZE  rcvd: 108

Ich bin absolut planlos warum das (vermutlich) nur bei dieser IP passiert, denn wenn das Problem öfter bestünde, müssten ja jede Menge Mails wegen fehlendem Reverse Hostname abgewiesen werden. Ich vermute eine Fehlkonfiguration von unbound, finde aber nicht welche das sein könnte. Hat jemand eine Idee?

unbound config:
Code:
$ cat /etc/unbound/unbound.conf
# Unbound configuration file for Debian.
#
# See the unbound.conf(5) man page.
#
# See /usr/share/doc/unbound/examples/unbound.conf for a commented
# reference config file.
#
# The following line includes additional configuration files from the
# /etc/unbound/unbound.conf.d directory.
include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"

#Adding DNS-Over-TLS support
server:
  use-syslog: no
  logfile: "/var/log/unbound/unbound.log"
  username: "unbound"
  directory: "/etc/unbound"
  tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
 
  do-ip6: yes
  do-ip4: yes
  interface: 127.0.0.1
  interface: ::1
  port: 53
  prefetch: yes

  cache-max-ttl: 14400
  cache-min-ttl: 1200

  aggressive-nsec: yes
  hide-identity: yes
  hide-version: yes
  use-caps-for-id: yes

  private-address: 127.0.0.1/32
  private-address: ::1

  #control which clients are allowed to make (recursive) queries
  access-control: 127.0.0.1/32 allow
  access-control: ::1/128 allow

  num-threads: 4
  msg-cache-slabs: 8
  rrset-cache-slabs: 8
  infra-cache-slabs: 8
  key-cache-slabs: 8
  rrset-cache-size: 256m
  msg-cache-size: 128m
  so-rcvbuf: 8m

  root-hints: "/etc/unbound/root.hints"

#  forward-zone:
#    name: "."
#    forward-addr: 1.1.1.1
#    forward-addr: 9.9.9.9

/etc/resolv.conf:
Code:
$ cat /etc/resolv.conf
#nameserver 9.9.9.9
#nameserver 213.136.95.10
#nameserver 79.143.183.251
# wenn nur die hier aktiv sind wird nur unbound verwendet
nameserver 127.0.0.1
nameserver ::1
 
Last edited:
Ok... mal wieder ne Stunde zu früh gefragt und dann selbst gelöst. (Naja... das Symptom behoben, aber die Ursache warum die unbound Anfrage nur bei dieser IP ins Timeout läuft bisher nicht gefunden).
Offenbar spielt die Reihenfolge der Einträge in der resolv.conf eine wichtige Rolle.
Wenn die nämlich so aussieht werden (die meisten) Queries vom unbound beantwortet, nur wenn der oft genug ins Timeout rennt wird der letzte Eintrag verwendet der dann auch bei unbound Timeouts antwortet. Ich beobachte das mal weiter...
Code:
$ cat /etc/resolv.conf
#nameserver 213.136.95.10
#nameserver 79.143.183.251
# wenn nur die hier aktiv sind wird nur unbound verwendet
nameserver 127.0.0.1
nameserver ::1
# Fallback
nameserver 9.9.9.9

Die chronischen Timeouts des unbound die irgendwie nur für diese oben genannte IP auftreten sind mir trotzdem nicht klar. Hab mal die verbosity fürs unbound Logging hochgestellt und sehe nun das hier. Kann das was mit dieser dnssec Meldung im Log zu tun haben? Nee... hat es nicht, die Zeile taucht auch bei Queries auf die vom unbound problemlos beantwortet werden.

Code:
1759345091] unbound[9433:0] info: sending query: 41.0-24.188.51.209.in-addr.arpa. PTR IN
[1759345091] unbound[9433:0] debug: sending to target: <0-24.188.51.209.in-addr.arpa.> 2607:5300:60:4a62::1#53
[1759345091] unbound[9433:0] debug: dnssec status: not expected
[1759345091] unbound[9433:0] debug: mesh_run: iterator module exit state is module_wait_reply
[1759345091] unbound[9433:0] info: mesh_run: end 2 recursion states (2 with reply, 0 detached), 3 waiting replies, 3 recursion replies sent, 1 replies dropped, 0 states jostled out
[1759345091] unbound[9433:0] info: average recursion processing time 0.216680 sec
[1759345091] unbound[9433:0] info: histogram of recursion processing times
[1759345091] unbound[9433:0] info: [25%]=0 median[50%]=0 [75%]=0
[1759345091] unbound[9433:0] info: lower(secs) upper(secs) recursions
[1759345091] unbound[9433:0] info:    0.004096    0.008192 2
[1759345091] unbound[9433:0] info:    0.524288    1.000000 1
[1759345091] unbound[9433:0] info: 0RDd mod2 rep 41.188.51.209.in-addr.arpa. PTR IN
[1759345091] unbound[9433:0] info: 1RDd mod2 rep 41.188.51.209.in-addr.arpa. PTR IN
[1759345091] unbound[9433:0] debug: cache memory msg=163438 rrset=253380 infra=63492 val=147326 subnet=140552
[1759345091] unbound[9433:0] debug: svcd callbacks end
[1759345091] unbound[9433:0] debug: serviced_delete
[1759345091] unbound[9433:0] debug: close of port 25498
[1759345091] unbound[9433:0] debug: comm_point_close of 42: event_del
[1759345091] unbound[9433:0] debug: close fd 42
 
Last edited:
Back
Top