search

NLnetLabs / unbound

Unbound is a validating, recursive, and caching DNS resolver.
https://nlnetlabs.nl/unbound
BSD 3-Clause "New" or "Revised" License
3.15k stars 359 forks source link

Unable to resolve tonymacx86.com #834

Closed seanob86 closed 1 year ago

seanob86 commented 1 year ago

Describe the bug Unbound 1.17.0 in recursive mode (in docker container) attempting to resolve tonymacx86.com and times out. Cloudflare, Google, Quad9 etc can resolve.

To reproduce

On the unbound docker container

dig tonymacx86.com

; <<>> DiG 9.16.33-Debian <<>> tonymacx86.com
;; global options: +cmd
;; connection timed out; no servers could be reached

Attempting dig command with google successfully resolves

; <<>> DiG 9.16.33-Debian <<>> tonymacx86.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59244
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;tonymacx86.com.                        IN      A

;; ANSWER SECTION:
tonymacx86.com.         14400   IN      A       66.232.110.83

;; Query time: 376 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Jan 22 16:40:10 AEDT 2023
;; MSG SIZE  rcvd: 59

Expected behavior DNS should resolve per google dns and the like.

System:

Configure line: --disable-dependency-tracking --prefix=/opt/unbound --with-pthreads --with-username=_unbound --with-ssl=/opt/openssl --with-libevent --with-libnghttp2 --enable-tfo-server --enable-tfo-client --enable-event-api Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.7 1 Nov 2022 Linked modules: dns64 respip validator iterator TCP Fastopen feature available


**Additional information**
Attempting to rule out issue on my end, I tested the resolution via unboundtest.com
This too also fails:

Query results for A tonymacx86.com ----- Unbound logs ----- Jan 22 04:39:56 unbound[29087:0] notice: init module 0: validator Jan 22 04:39:56 unbound[29087:0] notice: init module 1: iterator Jan 22 04:39:56 unbound[29087:0] info: start of service (unbound 1.16.3). Jan 22 04:39:57 unbound[29087:0] info: 127.0.0.1 tonymacx86.com. A IN Jan 22 04:39:57 unbound[29087:0] info: resolving tonymacx86.com. A IN Jan 22 04:39:57 unbound[29087:0] info: priming . IN NS Jan 22 04:39:57 unbound[29087:0] info: response for . NS IN Jan 22 04:39:57 unbound[29087:0] info: reply from <.> 192.5.5.241#53 Jan 22 04:39:57 unbound[29087:0] info: query response was ANSWER Jan 22 04:39:57 unbound[29087:0] info: priming successful for . NS IN Jan 22 04:39:57 unbound[29087:0] info: response for tonymacx86.com. A IN Jan 22 04:39:57 unbound[29087:0] info: reply from <.> 2001:500:2f::f#53 Jan 22 04:39:57 unbound[29087:0] info: query response was REFERRAL Jan 22 04:39:57 unbound[29087:0] info: response for tonymacx86.com. A IN Jan 22 04:39:57 unbound[29087:0] info: reply from 2001:500:d937::30#53 Jan 22 04:39:57 unbound[29087:0] info: query response was REFERRAL Jan 22 04:39:57 unbound[29087:0] info: resolving ns1.tonymacx86.com. AAAA IN Jan 22 04:39:57 unbound[29087:0] info: resolving ns2.tonymacx86.com. AAAA IN Jan 22 04:40:06 unbound[29087:0] info: Capsforid: timeouts, starting fallback Jan 22 04:40:06 unbound[29087:0] info: Capsforid: timeouts, starting fallback Jan 22 04:40:06 unbound[29087:0] info: Capsforid: timeouts, starting fallback

Error running query: read udp 127.0.0.1:55438->127.0.0.1:1053: i/o timeout



I also logged with `log-servfail: yes` and `verbosity: 4`

[unbound.log](https://github.com/NLnetLabs/unbound/files/10473856/unbound.log)

Keen to know whether this is an issue with config on unbound side or configuration on the tonymacx86 side. No other resolution issues for other DNS requests.

FYI: unbound sits behind pihole, but I have ruled out pihole by querying directly on unbound docker container.
alpominth commented 1 year ago

I'm not using Docker but here works fine:

user@localhost:~$ dig @127.0.0.1 -p 53 tonymacx86.com

; <<>> DiG 9.18.10-2-Debian <<>> @127.0.0.1 -p 53 tonymacx86.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57898
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;tonymacx86.com.            IN  A

;; ANSWER SECTION:
tonymacx86.com.     5183958 IN  A   66.232.110.83

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sun Jan 22 16:39:19 EST 2023
;; MSG SIZE  rcvd: 59

My config:

server:
  interface: 127.0.0.1
  interface: ::1
  port: 53
  cache-max-ttl: 5184000
  cache-min-ttl: 5184000
  cache-max-negative-ttl: 604800
  val-bogus-ttl: 0
  chroot: ""
  username: permcache
  directory: ""
  pidfile: ""
  do-not-query-localhost: no
  module-config: "validator cachedb iterator"

cachedb:
  backend: redis
  redis-server-host: ::1
  redis-server-port: 6379
  redis-timeout: 5000

forward-zone:
  name: "."
  forward-addr: ::1@10053
$ /opt/unbound/unbound -V
Version 1.17.2

Configure line: --prefix=/usr --includedir=${prefix}/include --infodir=${prefix}/share/info --libdir=${prefix}/lib/aarch64-linux-gnu --mandir=${prefix}/share/man --localstatedir=/var --runstatedir=/run --sysconfdir=/etc --with-chroot-dir= --with-dnstap-socket-path=/run/dnstap.sock --with-libevent --with-libhiredis --with-libnghttp2 --with-pidfile=/run/unbound.pid --with-pythonmodule --with-pyunbound --with-rootkey-file=/var/lib/unbound/root.key --disable-dependency-tracking --disable-flto --disable-maintainer-mode --disable-option-checking --disable-rpath --disable-silent-rules --enable-cachedb --enable-dnstap --enable-subnet --enable-systemd --enable-tfo-client --enable-tfo-server
Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.7 1 Nov 2022
Linked modules: dns64 python cachedb subnetcache respip validator iterator
TCP Fastopen feature available

BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues
seanob86 commented 1 year ago

The use of forward-zone just means that another dns server is performing the lookup, doesn’t it? That other server if resolving with a public dns server such as google, cloudflare etc will work as i mentioned in my notes.

The issue is if unbound is only configured as a recursive resolver which directly queries the root servers. A sample config to reproduce:

server:
    # If no logfile is specified, syslog is used
    # logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # 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

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    root-hints: "/var/lib/unbound/root.hints"

    # 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

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: 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: 1m

    # 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
saint-lascivious commented 1 year ago 
~ $ dig tonymacx86.com @192.168.1.10 -p 5335

; <<>> DiG 9.16.36 <<>> tonymacx86.com @192.168.1.10 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40545
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;tonymacx86.com.                        IN      A

;; ANSWER SECTION:
tonymacx86.com.         14327   IN      A       66.232.110.83

;; Query time: 32 msec
;; SERVER: 192.168.1.10#5335(192.168.1.10)
;; WHEN: Tue Jan 24 18:43:16 NZDT 2023
;; MSG SIZE  rcvd: 59

The above was resolved using 1.17.2 in recursive operation.

Also yes, the above commenter is operating in a forwarding configuration, but that resolver is just someone else's recursor, be it Google, Cloudflare, ISP, what have you.

seanob86 commented 1 year ago

Shall be closing this. Found on tonymacx86 forum other users in similar conditions where others were being blocked because their public ip had found to be port scanning them or some other behaviour which they deemed to be malicious. Not sure how and why I have been blocked but glad that it had nothing to do with my unbound configuration.