all-inkl: adding zone override for multi-level subdomain dns challenge cert creation

[tdick-stackop]

Welcome

• Yes, I've searched similar issues on GitHub and didn't find any.

How do you use lego?

Docker image

Effective version of lego

v4.23.1

Detailed Description

Problem Description

I am generating certificates for multi-level subdomains (e.g., foo.bar.example.com) using DNS challenges with the All-Inkl provider. The domain example.com is registered with All-Inkl without custom NS delegation for bar.example.com (despite potential local DNS differences).

Expected behavior: Zone for foo.bar.example.com should be example.com for this All-Inkl setup, not bar.example.com (expected to have an option to override).

Current Issue

The All-Inkl provider incorrectly attempts to update the bar.example.com zone via KasApi, but this zone doesn't exist at All-Inkl. The TXT records should be created in the example.com zone instead.

Requested Feature

Add an environment variable to override the automatically detected zone for the All-Inkl provider, allowing manual specification of the correct zone (e.g., example.com) when the auto-detection logic fails.

Implementation Status

I have prepared a tested modification that adds a provider-specific environment variable for zone override without changing default behaviour by adding

EnvZoneOverride = envNamespace + "ZONE_OVERRIDE"

Default / unset env does not change behaviour, tested in binary build as well as docker build.

Question: Is this a valid feature to request for the all-inkl provider? Can I submit my implementation as a pull request?

Thanks!

[ldez]

Lego handles multiple domains and zones, so this type of option that works with only one zone is not a good idea.

The zone detection is based on SOA records (not NS records): it feels like your subdomain is not properly configured.

If the detected zone of foo.bar.example.com is bar.example.com, this zone should be editable or the domain configuration is not right.

Maybe it's possible to get the zone through API, but the API documentation is weak and mainly useless.

Also, if you are not generating wildcard certificates, I recommend using HTTP or TLS challenges instead of the DNS challenge.

[ldez]

If I create a PR to try using the API to detect the zone, are you able to test it?

[tdick-stackop]

If I create a PR to try using the API to detect the zone, are you able to test it?

Sure!

---

I am currently checking your remarks about SOA and potential domain or dns misconfiguration on my end (could be my fault, I handle some DNS requests different inside VPN vs public - let me check).

[tdick-stackop]

If I create a PR to try using the API to detect the zone, are you able to test it?

actually, I can try this also. Give me some minutes :)

[ldez]

I am already working on it.

[ldez]

#2539

For now, the PR calls the API and logs information I need to know if this could work.

[tdick-stackop]

#2539

For now, the PR calls the API and logs information I need to know if this could work.

Thx!

Pulling it now, getting back to you shortly.