Conversation
The c-ares integration created every UDP socket as AF_INET and rejected any AF_INET6 sockaddr with "No ipv6 yet", so a host whose resolv.conf lists an IPv6 nameserver could not resolve anything: c-ares reported ARES_ECONNREFUSED for every server. That is what an IPv6-only Kubernetes pod looks like (CoreDNS over IPv6). - do_socket creates the datagram channel with the family c-ares asked for instead of hardcoding AF_INET. - sock_addr accepts AF_INET6 and checks the sockaddr length. - do_recvfrom copies the source address by its real length; sockaddr is only wide enough for AF_INET, so an IPv6 source was being truncated and its length misreported. - options.servers is installed with ares_set_servers_csv after channel creation; ARES_OPT_SERVERS carries in_addr only. - ARES_ECONNREFUSED is rendered with c-ares' own text, "Could not contact DNS servers", so it stops reading like a refused TCP connect. IPv4 nameservers take the same AF_INET branches as before. Adds a unit test that answers a query from a mock nameserver bound to [::1].
Member
|
Please upstream to sesatar first, then downstream the change here. |
Author
|
No problem will close for now. |
|
Hi @david-yu , i wonder if you have a PR ready for seastar to upstream the support? |
Author
|
@baryluk I'll see what I can do, will try to perhaps upstream a PR next week. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The c-ares integration could only talk to IPv4 nameservers:
do_socketcreated every UDP channel asAF_INETregardless of the family c-ares asked for, andsock_addrthrew"No ipv6 yet"on anAF_INET6sockaddr. On a host whoseresolv.conflists an IPv6 nameserver — an IPv6-only Kubernetes pod with CoreDNS — every lookup fails withARES_ECONNREFUSED, which the error category renders as "Connection refused" although no TCP connect was attempted.do_socket: datagram channel with the requestedaf.sock_addr: acceptAF_INET6, check the sockaddr length.do_recvfrom: copy the source by its real length (sockaddrtruncatessockaddr_in6) and report it in*from_len.options.servers: installed viaares_set_servers_csvafterares_init_options;ARES_OPT_SERVERSisin_addr-only.ARES_ECONNREFUSEDtext → c-ares' own "Could not contact DNS servers".IPv4 nameservers take the unchanged
AF_INETbranches.Tests
Unit (this PR) —
tests/unit/dns_test.cctest_resolve_udp_ipv6_nameserver: a mock UDP nameserver bound to[::1]answers an A query; the resolver is configured withservers = {"::1"}. Before this change construction throwsServers must be ipv4 addresses; after it, the answer (127.0.0.42) comes back over the IPv6 transport. Skips when the host has no IPv6. The existing TCP split-response test's response builder was refactored to share the message body.Downstream (redpanda, with the pin bumped to this commit)
//src/v/rpc/test:rpc_gen_cycling_testecho_round_trip_ipv6_hostname:localhostresolved through c-ares with family INET6 →::1, RPC round-trip succeeds.resolv.conf→fd1d:cca8:a7aa::a): an unpatchedv26.2.2cluster loops forever onC-Ares:11; with this change the 3-broker cluster forms, and survives rolling upgrade/downgrade, pod kill, all-at-once restart, scale 3→4→3, tiered storage and cloud topics to S3, config changes — 29/29 cases. Producer throughput is within 1% of an identical IPv4 cluster. Also verified on dual-stack AKS and GKE.Context: redpanda-data/redpanda-operator#1855. Companion core change: redpanda-data/streaming-enterprise#330. Will also be proposed upstream to scylladb/seastar.