ruby
IPv6 fallback to IPv4 broken by a8d1d94 in 0.5.0
Previously A records were resolved first, which was fine for users with broken IPv6 connectivity.
Now however, users with broken IPv6 connectivity are finding connectivity via net/http broken since the connection to a resolved AAAA address fails.
Perhaps this is a net/http bug?
I suspect that this is due to this change in the resolv gem: https://github.com/ruby/resolv/commit/a8d1d9470e6fa050a4d0151bea19b0034e498f70 which is in 0.5.0 of the resolv gem.
Do any of you want to open an issue at https://github.com/ruby/resolv/issues to report this regression, but also see if reverting that change locally fixes your issues?
I think you can test the older version of
resolv.rbthus:gem uninstall --force resolv gem install resolv -v 0.4.0
Originally posted by @satmandu in #10762
Seeing error messages like this after updating to resolv 0.5.0:
/usr/local/lib64/ruby/3.3.0/resolv-replace.rb:25:in `initialize': Failed to open TCP connection to gitlab.com:443 (Network is unreachable - connect(2) for "2606:4700:90:0:f22e:fbec:5bed:a9b9" port 443) (Errno::ENETUNREACH)
from /usr/local/lib64/ruby/3.3.0/resolv-replace.rb:25:in `initialize'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:1603:in `open'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:1603:in `block in connect'
from /usr/local/lib64/ruby/3.3.0/timeout.rb:186:in `block in timeout'
from /usr/local/lib64/ruby/3.3.0/timeout.rb:193:in `timeout'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:1601:in `connect'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:1580:in `do_start'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:1569:in `start'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:1029:in `start'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:822:in `get_response'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:803:in `get'
from /usr/local/lib/crew/lib/package_utils.rb:50:in `get_binary_url'
from /usr/local/lib/crew/lib/package_utils.rb:27:in `get_url'
from /usr/local/bin/crew:450:in `download'
from /usr/local/bin/crew:1303:in `install'
from /usr/local/bin/crew:1265:in `block in resolve_dependencies'
from /usr/local/bin/crew:1262:in `each'
from /usr/local/bin/crew:1262:in `resolve_dependencies'
from /usr/local/bin/crew:1154:in `resolve_dependencies_and_install'
from /usr/local/bin/crew:1826:in `block in install_command'
from /usr/local/bin/crew:1811:in `each'
from /usr/local/bin/crew:1811:in `install_command'
from /usr/local/bin/crew:1934:in `<main>'
/usr/local/lib64/ruby/3.3.0/resolv-replace.rb:25:in `initialize': Network is unreachable - connect(2) for "2606:4700:90:0:f22e:fbec:5bed:a9b9" port 443 (Errno::ENETUNREACH)
from /usr/local/lib64/ruby/3.3.0/resolv-replace.rb:25:in `initialize'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:1603:in `open'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:1603:in `block in connect'
from /usr/local/lib64/ruby/3.3.0/timeout.rb:186:in `block in timeout'
from /usr/local/lib64/ruby/3.3.0/timeout.rb:193:in `timeout'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:1601:in `connect'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:1580:in `do_start'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:1569:in `start'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:1029:in `start'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:822:in `get_response'
from /usr/local/lib64/ruby/3.3.0/net/http.rb:803:in `get'
from /usr/local/lib/crew/lib/package_utils.rb:50:in `get_binary_url'
from /usr/local/lib/crew/lib/package_utils.rb:27:in `get_url'
from /usr/local/bin/crew:450:in `download'
from /usr/local/bin/crew:1303:in `install'
from /usr/local/bin/crew:1265:in `block in resolve_dependencies'
from /usr/local/bin/crew:1262:in `each'
from /usr/local/bin/crew:1262:in `resolve_dependencies'
from /usr/local/bin/crew:1154:in `resolve_dependencies_and_install'
from /usr/local/bin/crew:1826:in `block in install_command'
from /usr/local/bin/crew:1811:in `each'
from /usr/local/bin/crew:1811:in `install_command'
from /usr/local/bin/crew:1934:in `<main>'
This is being reported by people who are able to resolve AAAA dns records for a host but do not actually have IPv6 connectivity to that host.
(Turning off IPv6 entirely on the system fixes the issue, so maybe this has to do with the link-local ipv6 address confusing the system.)
i.e., doing this fixes things:
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1