Describe the bug
TLS channel does not wait for readiness of socket. Even if it never reaches connected state, TLS channel setup is tried on it.
To reproduce
Steps to reproduce the behavior:
- We have broken IPv6 in the office and it is intentional. It works only locally, but cannot reach the public network.
# ping -6 -c 2 nlnetlabs.nl
PING nlnetlabs.nl(dicht.nlnetlabs.nl (2a04:b900::1:0:0:10)) 56 data bytes
From 2620:xx:0:xx::3fc (2620:xx:0:xx::3fc) icmp_seq=1 Destination unreachable: Address unreachable
From 2620:xx:0:xx::3fc (2620:xx:0:xx::3fc) icmp_seq=2 Destination unreachable: Address unreachable
--- nlnetlabs.nl ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms
- Now when I configure cloudflare.conf:
server:
tls-cert-bundle: "/etc/pki/tls/certs/ca-bundle.trust.crt"
forward-zone:
name: "."
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853
forward-addr: 2606:4700:4700::1111@853
forward-addr: 2606:4700:4700::1001@853
forward-tls-upstream: yes
unbound-host -C cloudflare.conf nlnetlabs.nl
# unbound-host -C cloudflare.conf nlnetlabs.nl
[1652280699] libunbound[1465:0] error: SSL_handshake syscall: No route to host
[1652280699] libunbound[1465:0] error: SSL_handshake syscall: No route to host
nlnetlabs.nl has address 185.49.140.10
[1652280699] libunbound[1465:0] error: SSL_handshake syscall: No route to host
[1652280699] libunbound[1465:0] error: SSL_handshake syscall: No route to host
nlnetlabs.nl has IPv6 address 2a04:b900::1:0:0:10
nlnetlabs.nl mail is handled by 1 mx.soverin.net.
Expected behavior
It should not even attempt any action on IPv6 sockets until its socket is ready to write. That should ensure connection were successful. TLS and TCP are stateful protocols and such state should be tried first. That would ensure TLS setup errors would not appear even in network without real IPv6 connectivity, but with local IPv6 addresses.
System:
- Unbound version: 1.15
- OS: Fedora release 37 (Rawhide)
unbound -V output:
Version 1.15.0
Configure line: --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-pythonmodule --with-pyunbound PYTHON=/usr/bin/python3 --enable-dnstap --with-libnghttp2 --with-libevent --with-pthreads --with-ssl --disable-rpath --disable-static --enable-relro-now --enable-pie --enable-subnet --enable-ipsecmod --with-conf-file=/etc/unbound/unbound.conf --with-pidfile=/run/unbound/unbound.pid --enable-sha2 --disable-gost --enable-ecdsa --with-rootkey-file=/var/lib/unbound/root.key --enable-linux-ip-local-port-range
Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.2 15 Mar 2022
Linked modules: dns64 python ipsecmod subnetcache respip validator iterator
BSD licensed, see LICENSE in source package for details.
Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues
Additional information
Add any other information that you may have gathered about the issue here.
Describe the bug
TLS channel does not wait for readiness of socket. Even if it never reaches connected state, TLS channel setup is tried on it.
To reproduce
Steps to reproduce the behavior:
unbound-host -C cloudflare.conf nlnetlabs.nlExpected behavior
It should not even attempt any action on IPv6 sockets until its socket is ready to write. That should ensure connection were successful. TLS and TCP are stateful protocols and such state should be tried first. That would ensure TLS setup errors would not appear even in network without real IPv6 connectivity, but with local IPv6 addresses.
System:
unbound -Voutput:Additional information
Add any other information that you may have gathered about the issue here.