pdns: API endpoint not at URL root resulting in incorrect URL queried and thus failing with error code 404 about lego HOT 2 OPEN

Hello,

I'm not sure to understand your problem.

As you can see we have dedicated tests on joinPath:

Your implementation will break everything.

And the tests seems to say the opposite of the behavior you described 🤔 .

from lego.

Hi,

Thanks for the quick reply!

Please find a bit more concrete explanation below.

There are four places where joinPath is used (which just adds the path to the PDNS_API_URL, potentially adding /api/v1 to the front if the provided path does not start with /api and if the API version is not 0):

The problem is with the latter two usages. Here, the path that is passed to joinPath is starting with zone.URL, where zone is the parsed return of the API call within GetHostedZone (see second code block above). However, at least for my provider, the URL that is returned by querying, in my case, https://login.udmedia.de/dns/api/v1/servers/udmedia/zones/example.com. is an absolute path to the host's root and thus also includes the relative path to the API again that is aready part of PDNS_API_URL (i.e., starting with /dns below rather than /api/v1/...):

{
    "id": "example.com.",
    "url": "\/dns\/api\/v1\/servers\/udmedia\/zones\/example.com.",
    "name": "example.com.",
    "type": "Zone",
<snip>

When this path is then passed to joinPath, this leads to URL with the duplicated /dns/api/v1/dns/api/v1 that I have listed in my original post.

My crude solution suggested above for the 3rd and 4th usage above (NOT replacing joinPath for the first two) works for my case and should also work for the standard case, where the API endpoint sits at the URL root with API version 1 where the /api/v1 should already be part of zone.URL.

However, there are also possibly less invasive solutions. If any of them sounds reasonable, please let me know and I can potentially flesh them out some more:

• Instead of using zone.URL in the 3rd and 4th joinPath calls above, one could recreated the relative URL analogously to the 2nd usage. With a relative URL, this should then work fine. From reading the PowerDNS API documentation, the URL sounds to be fixed and thus zone.URL usage just saves some work but should hopefully be replaceable.
• When zone.URL should still be used, an environmental variable option (something like PDNS_ZONE_URL_ABSOLUTE=1), whether it is known to contain the absolute URL to the URL's root, could be added and only if that is set, one could basically use my crude solution or try to retrospectively make the zone.URL a relative path before using joinPath by removing the path from PDNS_API_URL from the start of the zone.URL.

from lego.