HTTP Routing V1 provider records contain raw 0.0.0.0 listen addresses instead of resolved interface addresses #11213

Activity

1. Rinse12

   added

   kind/bugA bug in existing code (including security flaws)A bug in existing code (including security flaws)

   need/triageNeeds initial labeling and prioritizationNeeds initial labeling and prioritization

   on Feb 26, 2026
2. lidel commented on Feb 27, 2026

   

   lidel

   on Feb 27, 2026

   Last edited by lidel

   Contributor

   More actions

   Thank you for reporting.

   Triage note:

   The issue is in boxo's routing/http/client.Client Provider addresses are captured once at client construction time via WithProviderInfo(peerID, addrs) and stored as a static []types.Multiaddr field. When ProvideBitswap() builds the request, it reads c.addrs directly:

   // boxo routing/http/client/client.go
   
   type Client struct {
       // ...
       peerID   peer.ID
       addrs    []types.Multiaddr  // static, set once at construction
       // ...
   }
   
   func (c *Client) ProvideBitswap(ctx context.Context, keys []cid.Cid, ttl time.Duration) (time.Duration, error) {
       // ...
       req := types.WriteBitswapRecord{
           Payload: types.BitswapPayload{
               ID:    &c.peerID,
               Addrs: c.addrs,       // <-- uses whatever was set at init
           },
       }
       // ...
   }

   Kubo calls WithProviderInfo with raw config strings from Addresses.Swarm (via httpAddrsFromConfig()), so 0.0.0.0 / :: end up in provider records verbatim.

   The DHT provider path does not have this problem because it uses a func() []ma.Multiaddr callback that is evaluated at provide-time:

   // kubo core/node/provider.go
   selfAddrsFunc = func() []ma.Multiaddr { return impl.Host().Addrs() }
   // ...
   dhtprovider.WithSelfAddrs(selfAddrsFunc)

   Proposed fix in boxo

   Add a callback-based alternative to WithProviderInfo so addresses are resolved at provide-time, not construction-time. This follows the same pattern kubo's DHT provider already uses with WithSelfAddrs.

   1. New option in routing/http/client/client.go:

   // Client struct gets one new field:
   type Client struct {
       // ...
       peerID    peer.ID
       addrs     []types.Multiaddr
       addrsFunc func() []types.Multiaddr  // if set, called instead of using static addrs
       // ...
   }
   
   // New option:
   func WithProviderInfoFunc(peerID peer.ID, addrsFunc func() []multiaddr.Multiaddr) Option {
       return func(c *Client) error {
           c.peerID = peerID
           c.addrsFunc = func() []types.Multiaddr {
               addrs := addrsFunc()
               out := make([]types.Multiaddr, len(addrs))
               for i, a := range addrs {
                   out[i] = types.Multiaddr{Multiaddr: a}
               }
               return out
           }
           return nil
       }
   }

   2. ProvideBitswap resolves addresses lazily:

   func (c *Client) providerAddrs() []types.Multiaddr {
       if c.addrsFunc != nil {
           return c.addrsFunc()
       }
       return c.addrs
   }
   
   func (c *Client) ProvideBitswap(ctx context.Context, keys []cid.Cid, ttl time.Duration) (time.Duration, error) {
       // ...
       req := types.WriteBitswapRecord{
           Payload: types.BitswapPayload{
               // ...
               ID:    &c.peerID,
               Addrs: c.providerAddrs(),  // <-- dynamic resolution
           },
       }
       // ...
   }

   That's the entire boxo change: one new field, one new option func, one helper method, one changed line in ProvideBitswap.

   Kubo side

   Once boxo exposes WithProviderInfoFunc, kubo threads host.Host into the HTTP router construction (it is already available in RoutingOptionArgs.Host at that point) and provides a callback:

   drclient.WithProviderInfoFunc(host.ID(), func() []multiaddr.Multiaddr {
       // prefer AutoNAT V2 confirmed-reachable addresses
       type confirmedAddrsHost interface {
           ConfirmedAddrs() (reachable, unreachable, unknown []ma.Multiaddr)
       }
       if ch, ok := host.(confirmedAddrsHost); ok {
           reachable, _, _ := ch.ConfirmedAddrs()
           if len(reachable) > 0 {
               return reachable
           }
       }
       // fallback: host.Addrs() resolves 0.0.0.0 to interface addrs
       // and applies Announce/NoAnnounce/AppendAnnounce filters
       return host.Addrs()
   })

   This gives us:

   • AutoNAT-confirmed public addresses when available (best case)
   • Resolved interface addresses otherwise (fixes this issue)
   • Existing WithProviderInfo keeps working as-is (no breaking change)

   Since this requires new boxo release, and is a bug in experimental opt-in feature, low priority, but we could ship this in 0.41 if someone submits a PR.
3. lidel

   added

   P2Medium: Good to have, but can wait until someone steps upMedium: Good to have, but can wait until someone steps up

   help wantedSeeking public contribution on this issueSeeking public contribution on this issue

   good first issueGood issue for new contributorsGood issue for new contributors

   and removed

   need/triageNeeds initial labeling and prioritizationNeeds initial labeling and prioritization

   on Feb 27, 2026
4. rayspock commented on Mar 1, 2026

   

   rayspock

   on Mar 1, 2026

   More actions

   Hi, I’m new to the Kubo repo but I’ve been looking into this issue and the proposed direction seems reasonable.

   From what I understand, HTTP Routing V1 provider records currently expose raw 0.0.0.0 listen addresses, and the goal would be to resolve these into actual interface addresses before returning them.

   If no one is actively working on this, I’d be happy to take it on and put together a PR. Please let me know if there are any design constraints or preferred approaches I should be aware of before starting.
5. infektyd

   added a commit that references this issue on Mar 2, 2026

   fix: resolve addresses from host for HTTP delegated routing

   ...

   82ef5ed
6. lidel

   added a commit that references this issue on Mar 14, 2026

   fix: resolve provider addresses dynamically for HTTP routing

   ...

   This issue will close once commit 44d8d85 is merged into the 'master' branch.

   44d8d85
7. lidel commented on Mar 14, 2026

   

   lidel

   on Mar 14, 2026

   Last edited by lidel

   Contributor

   More actions

   @Rinse12 are you able to test if

   • fix: correct provider addresses for custom HTTP routing #11234

   addresses your needs?

   It uses confirmed public addrs from AutoNATv2 system, and also respects Addresses.Announce (static override) and Addresses.AppendAnnounce (adding static addrs in addition to dynamic / Wwarm ones)
8. Cripto5588 commented on Mar 16, 2026

   

   Cripto5588

   on Mar 16, 2026 · Hidden as off-topic

   show commentMore actions
9. lidel commented on Mar 16, 2026

   

   lidel

   on Mar 16, 2026 · Hidden as off-topic

   show commentMore actions
10. lidel

    self-assigned this

    on Mar 18, 2026
11. lidel

    removed

    help wantedSeeking public contribution on this issueSeeking public contribution on this issue

    good first issueGood issue for new contributorsGood issue for new contributors

    on Mar 18, 2026
12. lidel

    closed this as completedin #11234on Mar 18, 2026
13. pull

    added a commit that references this issue on Mar 18, 2026

    fix: correct provider addresses for custom HTTP routing (ipfs#11234)

    ...

    This issue will close once commit 9c4e268 is merged into the 'master' branch.

    9c4e268
14. Rinse12 commented on Apr 24, 2026

    

    Rinse12

    on Apr 24, 2026

    Author

    More actions

    I just tested it on Kubo 0.41.0 and unfortunately it still announces 0.0.0.0 addresses.

    You can test it out on https://github.com/Rinse12/kubo-http-router-0.0.0.0-address-bug
15. lidel commented on Apr 24, 2026

    

    lidel

    on Apr 24, 2026

    Last edited by lidel

    Contributor

    More actions

    @Rinse12 i suspect this is due to you not running libp2p DHT and/or AutoNAT? You really should consider enabling DHT, not doing so is bit counter-productive, especially with recent improvements (provide sweep, strategy pinned+mfs+unique etc).

    Update:

    • You're right, 0.41.0 only fully resolves addresses when AutoNATv2 has confirmed at least one reachable address. When the node is isolated (like your mock-router repro) the fallback path sends the raw Addresses.Swarm strings verbatim, so /ip4/0.0.0.0/... goes through untouched.
    • Working on a proper fix that delegates to the same address resolution the DHT provide path already uses, so wildcard binds get resolved to concrete interface addresses, and Addresses.NoAnnounce CIDR filtering applies correctly. Targeting Kubo 0.42.

    Workaround until 0.42

    Set Addresses.Announce explicitly to the address(es) you want in provider records (include all transports you use):

    "Addresses": {
      "Announce": [
        "/ip4/<your-reachable-ip>/tcp/<swarm-port>",
        "/ip4/<your-reachable-ip>/udp/<swarm-port>/quic-v1"
      ]
    }
16. lidel

    reopened this on Apr 24, 2026
17. Rinse12 commented on Apr 26, 2026

    

    Rinse12

    on Apr 26, 2026

    Author

    More actions

    i suspect this is due to you not running libp2p DHT

    Correct we're not using them intentionally. We would like to keep our apps very light in terms of network and computing resources with less moving parts involving IPFS. We've had issues with DHT in past, while they're probably fixed by now but we wanna get an MVP out with only http routers for now, then eventually explore http routers + DHT setup for backup.

    Feel free to try out one of our apps bitsocial-cli.

    👍React with 👍1Reacted by Marcin Rataj
18. lidel

    closed this as completedin #11297on Apr 27, 2026
19. lidel

    added a commit that references this issue on Apr 27, 2026

    fix: resolve wildcard swarm in http provides (#11297)

    ...

    This issue will close once commit 508f112 is merged into the 'master' branch.

    508f112
20. Rinse12

    added a commit that references this issue on Jun 11, 2026

    refactor(pkc): remove address rewriter proxy (no longer needed with k…

    ...

    This issue will close once commit 6bc9c47 is merged into the 'master' branch.

    6bc9c47