Domain resolution issue affecting topic embeds

AI-generated summary

A domain resolution issue is affecting topic embeds in Discourse, where URLs like https://opensource.org/blog/osi-response-to-ntia are being resolved to IPv6 addresses (e.g., 2604:a880:800:a1::2f0:a001) via FinalDestination and then failing when Excon attempts to connect. Angus explains the process, noting that while Excon.get on the original URL works, the embedded request times out due to the IPv6 resolution. David suggests the server resolves IPv6 records but lacks fallback to IPv4, which may be why the request fails—unlike the direct Excon.get, which likely retries with IPv4. The issue stems from the lack of fallback logic in FinalDestination#resolve.

There is possibly a domain resolution issue affecting topic embeds.

  1. The topic embed system relies on FinalDestination to resolve topic embed urls (see here).

  2. FinalDestination resolves the hostname of a url to an IP via SSRFDetector (see here)

  3. FinalDestination then sends the uri to Excon for the actual request (see here).

This means that some topic embed urls, for example

"https://opensource.org/blog/osi-response-to-ntia"

end up being sent to Excon for a GET request like so:

"https://[2604:a880:800:a1::2f0:a001]/blog/osi-response-to-ntia"

This request will time out. An Excon.get of the original URL will not.

It seems ok here on Meta:

From your description, my guess would be that your server is resolving ipv6 records when making DNS lookups (we use getaddrinfo for that). But then when attempting to connect to them, it’s failing.

That might be because it tries the ip6 address, fails, and then falls back to the ip4 address. We don’t currently have that kind of fallback logic in FinalDestination#resolve:

2 Likes