-
-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unbound not able to resolve broadcom.com and post.ch #1231
Comments
It probably is related. Unbound can show detailed reports of what is going wrong in the logs. With For me the two domains resolve fine, with Unbound. Also with DNSSEC. But then I noticed that both domains have a large DNSKEY response, of more than 1700 bytes. The If the other domains work fine. And these two do not work. Then the TCP fallback could be the issue. The TCP fallback would not activate for other lookups. But for these two it is needed to make DNSSEC work. One option is to turn off DNSSEC, by commenting out the trust anchor config line. Or by |
really appreciate your detailed write-up and analysis so far:) this issue just started recently. but i can't say if it's related to my Modem change. i'm now on Fiber 10GB with crappy locked down Modem from my provider. this is the output with logging enabled "verbosity 2" [1737712266] unbound[287883:0] info: query response was nodata ANSWER |
Yes the logs looks like the DNSKEY cannot be looked up. The dig command for testing probed for the A record. The dig command that would elicit the large response would be |
Looks like post.ch DNS server resetting the connection once TCP started. dig +tcp +trace @192.168.1.102 post.ch DNSKEY ; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> +tcp +trace @192.168.1.102 post.ch DNSKEY ;; Connection to 2001:503:c27::2:30#53(2001:503:c27::2:30) for post.ch failed: network unreachable. ;; Connection to 2001:503:c27::2:30#53(2001:503:c27::2:30) for post.ch failed: network unreachable. ;; Connection to 2001:503:c27::2:30#53(2001:503:c27::2:30) for post.ch failed: network unreachable. post.ch. 3600 IN NS dns1.post.ch. ;; Connection to 2a00:17c8:0:8000::201#53(2a00:17c8:0:8000::201) for post.ch failed: network unreachable. |
That is interesting. One not so important result, that the machine does not do IPv6. Setting unbound But the tcp access succeeds, for dig, to the servers for the root and .ch, but tcp access fails towards the servers for post.ch. For ipv6 it fails like the other IPv6 connections. But for IPv4 it gives timed out. Perhaps post.ch disallows all tcp traffic, but has an overly large DNSKEY. If I try this here, then the IPv4 address responds fine over TCP. So, the dig query that fails, without the long trace, is Perhaps there is a firewall that disallows tcp access. But then only towards post.ch and not the root servers or .ch nameservers. Not some blanked denial of all DNS TCP, and I do not know what is going on. I have no clue why the TCP connections time out. |
just so you know "do-ip6: no" already set in the config. not sure why it still tries it. I've just contacted my provider to check what's going on. Funny enough i've found a thread in my providers community forum were a user with almost exactly the same setup having the same issue. Additionally, i would like to thank you very much for your help:) dig @194.41.216.137 +dnssec post.ch DNSKEY |
Glad to hear that there is way to figure out more. The reason that IPv6 was visible there is because that was the output of the 'dig +trace' program, and not from unbound that is using the unbound configuration. The dig command for the DNSKEY shows precisely the failed connection output. |
Describe the bug
Unbound not able to resolve broadcom.com and post.ch, so far.
I use unbound as my Upstream DNS Servers on a Raspi PiHole installation.
Unbound listens on port 5335.
In general DNS resolution is working perfectly fine.
To reproduce
Steps to reproduce the behavior:
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
;; communications error to 127.0.0.1#5335: timed out
; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> broadcom.com @127.0.0.1 -p 5335
;; global options: +cmd
;; no servers could be reached
Expected behavior
A clear and concise description of what you expected to happen.
System:
unbound -V
Version 1.17.1
Configure line: --build=aarch64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/aarch64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --with-pythonmodule --with-pyunbound --enable-subnet --enable-dnstap --enable-systemd --with-libnghttp2 --with-chroot-dir= --with-dnstap-socket-path=/run/dnstap.sock --disable-rpath --with-pidfile=/run/unbound.pid --with-libevent --enable-tfo-client --with-rootkey-file=/usr/share/dns/root.key --disable-flto --enable-tfo-server
Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.15 3 Sep 2024
Linked modules: dns64 python subnetcache respip validator iterator
TCP Fastopen feature available
Additional information
For both domains "https://dnsviz.net/" website show warning and or errors. but i don't know of this is related to my issue.
The text was updated successfully, but these errors were encountered: