Skip to content
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

Unable to resolve .eu TLD #1044

Open
Meryl opened this issue Apr 12, 2024 · 10 comments
Open

Unable to resolve .eu TLD #1044

Meryl opened this issue Apr 12, 2024 · 10 comments

Comments

@Meryl
Copy link

Meryl commented Apr 12, 2024

Describe the bug
Unbound is unable to resolve domains for the .eu TLD. The dig command fails with timeouts. It works fine for other TLDs but not for any .eu-domain that I tested.

To reproduce
Steps to reproduce the behavior:

  1. Start unbound
  2. Do a request for an existing .eu domain (proven to work with other DNS services).

Expected behavior
A proper result instead of a timeout.

System:

  • Unbound version: 1.17.1
  • OS: Debian GNU/Linux 12 (bookworm)
  • unbound -V output:
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.11 19 Sep 2023
Linked modules: dns64 python subnetcache respip validator iterator
TCP Fastopen feature available

BSD licensed, see LICENSE in source package for details.
Report bugs to [email protected] or https://github.com/NLnetLabs/unbound/issues

Additional information
I'm running on a Raspberry Pi. This is the command output when testing:

tim@raspberrypi:~ $ sudo service unbound start
tim@raspberrypi:~ $ dig loots.eu @127.0.0.1 -p 5335 +short
;; 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.24-1-Debian <<>> loots.eu @127.0.0.1 -p 5335 +short
;; global options: +cmd
;; no servers could be reached

tim@raspberrypi:~ $ sudo service unbound stop

This was the log produced:
unbound.log

Relevant config files (uploaded as .txt because github doesn't like .conf):
unbound.conf.txt
pi-hole.conf.txt
resolvconf_resolvers.conf.txt
remote-control.conf.txt
root-auto-trust-anchor-file.conf.txt

@wcawijngaards
Copy link
Member

From looking at the logs, it seems that the issue is that Unbound is configured to DNSSEC validate. The .eu DNSKEY is too large to fit in a UDP response. UDP responses work fine, but the TCP response fails with a timeout. This happens again and again, until you give up. Perhaps the firewall is set to allow UDP but not TCP traffic? TCP traffic does not get answers, and this is why the resolution fails, it works but the DNSSEC verification fails to fetch the .eu DNSKEY RRset because it is large and needs to use TCP for transport, and TCP traffic fails with timeout. Unbound tries several of the upstream forwarders that are configured.

@Meryl
Copy link
Author

Meryl commented Apr 12, 2024

Well, disabling DNSSEC validation per this page in the docs does in fact make it work again.

I also tried disabling all rules in iptables and the firewall on my modem, neither seemed to matter. I also have no trouble setting up any other TCP connections, and it seems to be relatively recent development (it started around the beginning of this week). Do you know if there's a reliable way to test if this is a firewall issue of some kind?

@wcawijngaards
Copy link
Member

Supposedly when Unbound makes a TCP connection, this is very similar to performing a dig +tcp @that_ip_address query_name. From the same host as where unbound is running. If the option for outgoing interface is set, that would change the outgoing interface for that.

@Meryl
Copy link
Author

Meryl commented Apr 15, 2024

dig +tcp loots.eu @1.1.1.1 works fine. I tried with +dnssec +tpc to eu as well, seeing as somehow that would seem be the issue but everything came through fine.

@wcawijngaards
Copy link
Member

If it works like that then why can Unbound not do it? It is really doing the same thing; unless you use configuration options like outgoing-interface, or socket options, or TLS settings.

@jordycoding
Copy link

Are there any updates on this? I am also having this issue under NixOS 24.05

@petervdvendel
Copy link

Any updates? Same here in a docker container.

@wcawijngaards
Copy link
Member

Perhaps the dig that was tried did not attempt to fetch the large response, the .eu DNSKEY query. And that is why it succeeded, instead of failed. I guess it is the tcp configuration that fails, it would explain the issue. With log-servfail or val-log-level: 2 it could be shown that it is the dnskey lookup that fails. Or what fails is the UDP large response, and without any TCP indication from upstream unbound does not try tcp either, even if that would work. And then the .eu DNSKEY lookup is the issue, from UDP size. If the edns-buffer-size is configured larger than default and the network fails with larger UDP messages, this is the cause of the problem, but then that would be visible with a dig command too, if that is with an option to also set the edns size to that value.

@Meryl
Copy link
Author

Meryl commented Jul 15, 2024

@wcawijngaards I'm willing to test/troubleshoot stuff, but I'm not smart enough to figure out the steps I can take by myself. Do you have any suggestions? Something that can rule out certain things, for example?

@Jakker
Copy link
Contributor

Jakker commented Jul 15, 2024

Note that eu has a problem with DNSSEC. See https://dnssec-analyzer.verisignlabs.com/xn--qxa6a and https://dnsviz.net/d/xn--qxa6a/dnssec/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants