Hi,

It is unclear whether the DNS record names (libdns.Record.Name):

1. use the standard "dot-suffix" relative/absolute notation (eg if zone FQDN is example.org. then subdomain.example.org. -> subdomain.example.org ; subdomain -> subdomain.example.org)
2. always use absolute paths implicitly (subdomain.example.org -> subdomain.example.org)

I think 1) is better as it directly reflects what a DNS server actually returns, but it seems that currently the API contract is implicitly 2).

Examples:

• the gandi provider has to manually trim the .example.org part to get a relative notation to pass that to Gandi (notice how it expects to receive subdomain.example.org without an ending dot suffix) which uses the standard dot-suffix notation
• the dnspod provider behaves the same (but is buggier because it replaces all instances of the zone in the domain name which is incorrect)
• the cloudflare provider passes the value as-is to the API, but the API docs clearly show that the API uses absolue paths implicitly (see example.org, should be example.org. if using the dot-suffix notation, but here's it's just example.org)
• the digitalocean provider does not work becauses libdns passes implicitly absolute paths without a dot suffix and the provider passes it as is to the API which expects the dot-suffix notation (1))

I suggest to choose which syntax/semantics we want to use for DNS record names, document it clearly and update the various libdns providers as necessary. I think using the standard absolute/relative notation depending on a final dot is better as it better correponds to what a DNS server returns.