azure: zone name as environment variable

[fibbs]

This pull request solves issue #1432 (feature request).

In some cases you might want to use acme to fetch certificates while the server doing so does not have access to (public) DNS and therefore cannot fetch the SOA record of the domain. This happens to me with a subdomain. I have this subdomain in the authoritative DNS server of another provider, forwarding one sub-domain to an azure DNS hosted zone. This NS Record is not set at my company's internal DNS server, because I do not want to have the records inside the sub-domain to be visible from the internet.

For this to work, I need to supply the zone name within which lego should create the TXT validation records instead of letting lego gather this from DNS. This is what this pull request solves by adding an additional (optional) environment variable AZURE_ZONE_NAME.

[dmke]

This sounds like a useful feature to have, not only for the Azure provider, but for all DNS providers. I believe lego --dns.providers=... should be able to this already, though (if not, we should move the logic of dns01.FindZoneByFqdn for a more generic solution).

I've left some remarks on this PR, for the case we don't want to change dns01.FindZoneByFqdn.

[fibbs]

This sounds like a useful feature to have, not only for the Azure provider, but for all DNS providers. I believe lego --dns.providers=... should be able to this already, though (if not, we should move the logic of dns01.FindZoneByFqdn for a more generic solution).

To be honest, I have not checked how exactly other of the providers work exactly. I was supposing that this "get the actual zone within which the TXT record is to be added" was something specific to how the structure is in Azure DNS was, and that probably other provider's code could be working completely different. So, I do believe that fixing this is good enough only for Azure, as I don't know whether the function dns01.FindZoneByFqdn might be used by something completely different though.

Anyway, that's of course something you as the developers of this project have much more insights into. I would be happy with either solution.

I've left some remarks on this PR, for the case we don't want to change dns01.FindZoneByFqdn.

Fixed :)

[ldez]

@fibbs the message of @dmke is for me 😉