Why does "rpk topic create" switch to using IPv6?

[SunSparc]

I have a cluster setup and am trying to automate the creation of topic by using the rpk remotely. I can check the cluster health, info, and even get a topic list without error, but as soon as I try to create a topic, rpk grabs an IPv6 address and tries to use that, which fails. My DNS is specifying only IPv4 addresses. I do not see any mention in the documentation of a way to force only using IPv4. What am I to do in this situation? Is this a bug?

$ rpk cluster health
CLUSTER HEALTH OVERVIEW
=======================
Healthy:                          true
Unhealthy reasons:                []
Controller ID:                    0
All nodes:                        [0 1 2]
Nodes down:                       []
Nodes in recovery mode:           []
Leaderless partitions (0):        []
Under-replicated partitions (0):  []
Cluster UUID:                     135b8523-64ae-4c3c-7c44-6743761d9b13

$ rpk cluster info
CLUSTER
=======
redpanda.f5a791d5-5344-4b6f-830b-46507d83a6fc

BROKERS
=======
ID    HOST                         PORT
0*    https://redpanda-a.test.com  9092
1     https://redpanda-b.test.com  9092
2     https://redpanda-c.test.com  9092

TOPICS
======
NAME      PARTITIONS  REPLICAS
_schemas  1           3

$ rpk topic list
NAME      PARTITIONS  REPLICAS
_schemas  1           3

$ rpk topic create test-topic-stream -p 16 -r 3 -c cleanup.policy=delete -c retention.bytes=1073741824 -c retention.ms=86400000 -v
10:13:05.983  DEBUG  opening connection to broker  {"addr": "redpanda-a.test.com:9092", "broker": "seed_0"}
10:13:06.138  DEBUG  connection opened to broker  {"addr": "redpanda-a.test.com:9092", "broker": "seed_0"}
10:13:06.138  DEBUG  issuing api versions request  {"broker": "seed_0", "version": 4}
10:13:06.138  DEBUG  wrote ApiVersions v4  {"broker": "seed_0", "bytes_written": 31, "write_wait": "70.542µs", "time_to_write": "49.333µs", "err": null}
10:13:06.188  DEBUG  read ApiVersions v4  {"broker": "seed_0", "bytes_read": 331, "read_wait": "352.833µs", "time_to_read": "49.565375ms", "err": null}
10:13:06.188  DEBUG  connection initialized successfully  {"addr": "redpanda-a.test.com:9092", "broker": "seed_0"}
10:13:06.188  DEBUG  wrote Metadata v8  {"broker": "seed_0", "bytes_written": 24, "write_wait": "204.7645ms", "time_to_write": "120.375µs", "err": null}
10:13:06.238  DEBUG  read Metadata v8  {"broker": "seed_0", "bytes_read": 270, "read_wait": "108.416µs", "time_to_read": "49.773625ms", "err": null}
10:13:06.239  DEBUG  opening connection to broker  {"addr": "[https://redpanda-a.test.com]:9092", "broker": "0"}
10:13:09.242  WARN  unable to open connection to broker  {"addr": "[https://redpanda-a.test.com]:9092", "broker": "0", "err": "dial tcp [2e03:4f1:e2:2032::]:9092: i/o timeout"}
10:13:09.242  DEBUG  opening connection to broker  {"addr": "[https://redpanda-a.test.com]:9092", "broker": "0"}
10:13:12.247  WARN  unable to open connection to broker  {"addr": "[https://redpanda-a.test.com]:9092", "broker": "0", "err": "dial tcp [2e03:4f1:e2:2032::]:9092: i/o timeout"}
10:13:12.248  DEBUG  retrying request  {"request": "CreateTopics", "tries": 1, "backoff": "260.815265ms", "time_since_start": "6.2654035s", "request_error": "unable to dial: dial tcp [2e03:4f1:e2:2032::]:9092: i/o timeout", "response_error": "unable to dial: dial tcp [2e03:4f1:e2:2032::]:9092: i/o timeout"}
10:13:12.509  DEBUG  opening connection to broker  {"addr": "[https://redpanda-a.test.com]:9092", "broker": "0"}
10:13:15.511  WARN  unable to open connection to broker  {"addr": "[https://redpanda-a.test.com]:9092", "broker": "0", "err": "dial tcp [2e03:4f1:e2:2032::]:9092: i/o timeout"}
10:13:15.511  DEBUG  opening connection to broker  {"addr": "[https://redpanda-a.test.com]:9092", "broker": "0"}
10:13:18.513  WARN  unable to open connection to broker  {"addr": "[https://redpanda-a.test.com]:9092", "broker": "0", "err": "dial tcp [2e03:4f1:e2:2032::]:9092: i/o timeout"}
unable to create topics [authorization-context-http-stream]: unable to dial: dial tcp [2e03:4f1:e2:2032::]:9092: i/o timeout

Versions
rpk:  v25.2.7, v25.2.8
redpanda: v25.2.2, v25.2.8

[dotnwat]

cc @r-vasquez

[r-vasquez]

Hi @SunSparc can you provide your redpanda.yaml please? specifically what you have set for the Kafka listeners and advertised kafka listeners. Thanks!

[r-vasquez]

Thanks for sharing the logs/configuration.

Some initial thoughts and clarifications needed:

Hostname and Scheme:

In the logs, the second connection attempt shows [https://redpanda-a.test.com/]:9092 while the first uses redpanda-a.test.com:9092. Can you confirm that both addresses are the same? And also that the https:// URL scheme is present (or not). This address is passed directly to net.Dial and it does not expect URLs.

Also, can you confirm that the advertised_kafka_api in your sanitized config is the same as the one in the logs?

Go Dial / Dual-stack resolution
Go's network stack does dual-stack resolution by default. If the hostname resolves to an IPv6 address, Go will try that path. This can be tested easily outside Redpanda with a Go program that attempts to dial the problematic address. Here is an example that can give you some insights:

// Usage: go run dial_debug.go redpanda-a.test.com 9092
package main

import (
	"context"
	"fmt"
	"log"
	"net"
	"net/http/httptrace"
	"os"
)

func main() {
	if len(os.Args) < 3 {
		fmt.Fprintf(os.Stderr, "Usage: %s <host> <port>\n", os.Args[0])
		os.Exit(1)
	}

	d := &net.Dialer{}

	ctx := httptrace.WithClientTrace(context.Background(), &httptrace.ClientTrace{
		DNSStart: func(info httptrace.DNSStartInfo) {
			log.Printf("DNSStart: %q", info.Host)
		},
		DNSDone: func(info httptrace.DNSDoneInfo) {
			log.Printf("DNSDone: %s", info.Addrs)
		},
		ConnectStart: func(network, addr string) {
			log.Printf("ConnectStart: %s %s", network, addr)
		},
		ConnectDone: func(network, addr string, err error) {
			log.Printf("ConnectDone: %s %s %v", network, addr, err)
		},
	})

	host := os.Args[1]
	port := os.Args[2]

	fmt.Printf("Resolving %s:%s ...\n", host, port)

	// Resolve IPs like Go’s net.Dial would
	addrs, err := net.DefaultResolver.LookupIP(ctx, "ip", host)
	if err != nil {
		fmt.Fprintf(os.Stderr, "Lookup error: %v\n", err)
		os.Exit(1)
	}

	for i, addr := range addrs {
		fmt.Printf("[%d] %s (%s)\n", i, addr, family(addr))
	}

	fmt.Println("\nAttempting to connect sequentially to show which address works:")
	for _, addr := range addrs {
		dialAddr := net.JoinHostPort(addr.String(), port)
		fmt.Printf("Dialing %s ... ", dialAddr)
		conn, err := d.DialContext(ctx, "tcp", dialAddr)
		if err != nil {
			fmt.Printf("failed: %v\n", err)
			continue
		}
		fmt.Printf("success!\n")
		conn.Close()
	}
}

func family(ip net.IP) string {
	if ip.To4() != nil {
		return "IPv4"
	}
	return "IPv6"
}

[SunSparc]

I am not sure what you mean when you ask me to be sure that these two addresses are the same:

- [https://redpanda-a.test.com/]:9092
- redpanda-a.test.com:9092

The only place that I specify a protocol is in this block in the redpanda.yaml file on the broker:

advertised_kafka_api:
  - name: external-listener
    address: "https://

"can you confirm that the advertised_kafka_api in your sanitized config is the same as the one in the logs?"

Yes, they are the same.

Here is the result of running dial_debug.go locally (same machine that is running rpk):

$ go run dial_debug.go redpanda-a.test.com 9092
Resolving redpanda-a.test.com:9092 ...
2025/10/08 12:36:29 DNSStart: "redpanda-a.test.com"
2025/10/08 12:36:29 DNSDone: [{6.7.8.9 }]
[0] 6.7.8.9 (IPv4)

Attempting to connect sequentially to show which address works:
Dialing 6.7.8.9:9092 ... 2025/10/08 12:36:29 ConnectStart: tcp 6.7.8.9:9092
2025/10/08 12:36:29 ConnectDone: tcp 6.7.8.9:9092 <nil>
success!

$ go version
go version go1.25.1 darwin/arm64

If it helps, here is the rpk.yaml file that my local command line is using:

version: 7
globals:
    prompt: ""
    no_default_cluster: false
    command_timeout: 0s
    dial_timeout: 0s
    request_timeout_overhead: 0s
    retry_timeout: 0s
    fetch_max_wait: 0s
    kafka_protocol_request_client_id: ""
current_profile: testprofile
current_cloud_auth_org_id: ""
current_cloud_auth_kind: ""
profiles:
    - name: test profile
      description: A profile for testing.
      prompt: hello world
      from_cloud: false
      kafka_api:
        brokers:
            - redpanda-a.test.com:9092
            - redpanda-b.test.com:9092
            - redpanda-c.test.com:9092
        tls: {}
      admin_api:
        addresses:
            - redpanda-service.test.com:9644
      schema_registry: {}
      license_check:
        last_update: 1759945245
cloud_auth: []

[r-vasquez]

Do you get the same result with go run dial_debug.go https://redpanda-a.test.com 9092?

[SunSparc]

$ go run dial-debug.go https://redpanda-a.test.com 9092
Resolving https://redpanda-a.test.com:9092 ...
2025/10/08 13:02:09 DNSStart: "https://redpanda-a.test.com"
2025/10/08 13:02:09 DNSDone: [{1a2b:3cc:4d:5678:: } {6.7.8.9 }]
[0] 1a2b:3cc:4d:5678:: (IPv6)
[1] 6.7.8.9 (IPv4)

Attempting to connect sequentially to show which address works:
Dialing [1a2b:3cc:4d:5678::]:9092 ... 2025/10/08 13:02:09 ConnectStart: tcp [1a2b:3cc:4d:5678::]:9092
2025/10/08 13:03:24 ConnectDone: tcp [1a2b:3cc:4d:5678::]:9092 dial tcp [1a2b:3cc:4d:5678::]:9092: connect: operation timed out
failed: dial tcp [1a2b:3cc:4d:5678::]:9092: connect: operation timed out
Dialing 6.7.8.9:9092 ... 2025/10/08 13:03:24 ConnectStart: tcp 6.7.8.9:9092
2025/10/08 13:04:39 ConnectDone: tcp 6.7.8.9:9092 dial tcp 6.7.8.9:9092: connect: operation timed out
failed: dial tcp 6.7.8.9:9092: connect: operation timed out

Oh, interesting, specifying the protocol changes the result. Does that mean that the local rpk may be using the advertised_kafka_api address? I only specify the protocol there because I saw it being specified in an example in the documentation. Should that address not have the protocol?

I just updated the redpanda.yaml on all the brokers. I removed the protocol and now the local rpk is working without trying to use IPv6. That must have been the problem. Thank you!

[r-vasquez]

Thanks @SunSparc for the report and debugging with us 👍, we are correcting the docs now to avoid others from hitting this issue.