fix(DnsPinning): Ensure to always lookup based on FQDN

[DerDreschner]

• Resolves: [Bug]: App Updates with IPv6 and Debian Trixie: RequestException cURL error 60: SSL: no alternative certificate subject name matches target hostname 'github.com' #56489

Summary

After upgrading my private server from Debian 12 to Debian 13, I've experienced the same issue mentioned in #56489 which resulted in the app store to be totally unusable. Upgrading the Nextcloud version worked without any issues tho.

The investigation got the following results:

• The main issue is the DNS Pinning
• When looking up github.com, it tried to resolve A, AAAA and CNAME records
• It only got an A and AAAA record back
• The A record had the correct host and IP, but the AAAA record didn't. It was the result for github.com.dreschner.net
• cURL tries to connect via the (incorrectly) provided IPv6 address first
• The certificate doesn't match the expected hostname and resulting in the error 60

For reproducing the issue on command line level, you can use the following command on a server with IPv6 connectivity:

curl -v https://github.com/nextcloud-releases/integration_giphy/releases/download/v2.2.0/integration_giphy-v2.2.0.tar.gz --resolve 'github.com:443:140.82.121.4,2a0a:4cc0:c1:71d6:1876:e0ff:fe86:4038'

The reason is that we don't use FQDNs for resolving the DNS records and GitHub doesn't provide an AAAA record. Therefore, the program behind dns_get_records() looks for the host as subdomain of the local domain name. This works as I have a wildcard AAAA record set-up.

The fix is easy: just add a . at the end to make the requested domain name a FQDN and prevent the lookup under the local domain name when no record is being found in the first lookup.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[DerDreschner]

/backport to stable32

[DerDreschner]

/backport to stable33

[provokateurin]

Uh that is quite something 😅

[kesselb]

nit: @param/@return phpdoc comments are redundant with the type hints

[DerDreschner]

True, I have to figure out how to get PhpStorm to not do that when adding phpdoc comments.

[DerDreschner]

I've realized that my fix has an unexpected side effect. It totally prevents the usage of relative domains, as all domains are being treated as FQDNs from a DNS point of view. That's totally fine for the app store - but a bit unexpected for other developers and might break some apps, as it's usually possible to use both relative and absolute domains on any HTTP request. As most apps use our implementation, I lean on fixing it before someone might complain about it (and hence merging it into stable33 and stable32).

I can think of two ways to tackle that:

1. Put the list of IANA root zones into the resources folder (probably cache it for performance reasons) and check against that before marking the domain as an FQDN.
2. Rewrite the DNS pinning: Let cURL resolve the domain name, lookup the SOA record and then cache the result and inject it into any further request for the specified TTL.

The suggested change here to discard the record if it doesn't match the requested host would have the same unexpected side effect as my fix does. So, that solution is not possible, unfortunately. Also, as the example with github.com.dreschner.net demonstrates, we're unable to just check if the domain is likely a hostname (has no dot in it).

Any thoughts on this? @kesselb @provokateurin @ChristophWurst

[ChristophWurst]

Unfortunately I absolutely lack expertise in this area. I don't know.