DnsControl VS lexicon

See RFC5507: "Why Adding a New Resource Record Type Is the Preferred Solution"

DNS providers should support a wide range of RR types, and domain owners should vote with their NS records.

See https://github.com/StackExchange/dnscontrol/blob/master/docu... for a list of DNS providers that support CAA.

I would create an AWS account for Route53 only. No other services or resources would be deployed. To manage the DNS records I may use: https://github.com/StackExchange/dnscontrol

How is this compared to https://dnscontrol.org/ from Stackoverflow?

Hover's DNS is very simple and bare bones. dnsimple works with dnscontrol so I can manage all my domains programatically

Have you tried dnscontrol.org? It ties into the registrar and DNS providers API's

Was typing on phone and thought that was it. This one https://docs.dnscontrol.org/ explains a bit what it does and heres its github https://github.com/StackExchange/dnscontrol

DNSControl[1] or another similar tool also helps a lot when moving. My DNS records are configured by a small JavaScript file in a git repository, and I can very easily point it at another DNS provider.

[1]: https://dnscontrol.org/

One of the biggest benefits of dehydrated is that it doesn't try to integrate with a DNS provider on its own. It just calls a hook, which can be implemented with a simple shell script[1]. The most popular third-party integration is lexicon[2], though you're not required to use Lexicon. (e.g. you're free to use awscli, gcloud, linode-cli, etc. to do the actual DNS record manipulation)

This means its dependencies footprint is much smaller, and allows you to do things that can be a nightmare to configure with Certbot or other alternatives. For example, at one of the scenarios I had to set up was that we had to query a credential via HashiCorp Vault, which is then used to cURL into an API endpoint. The shell script in total was pretty short (< 100 LOC) and it worked extremely well.

[1]: https://github.com/dehydrated-io/dehydrated/blob/master/docs...

[2]: https://github.com/AnalogJ/lexicon

A reminder that if you an internal-only server where the typical http-01' verification connection method will not work, especially if you cannot easily/dynamically update DNS records, one can use dns-01* by using DNS aliasing/CNAME:

* https://dan.langille.org/2019/02/01/acme-domain-alias-mode/

* https://www.eff.org/deeplinks/2018/02/technical-deep-dive-se...

So if you want a cert for www.internal.example.com, you will first have do a one-time change to have a _acme-challenge.www.internal… CNAME created to point to any other (sub-)domain where you can easily update things dynamically, e.g., www-internal.example-dnsapi.com.

When request the cert for "www.internal…", LE/ACME will look up the corresponding _acme-challenge record, and go to "_acme-challenge.www-internal.example-dnsapi.com. The nonce token will be there in the 'final' destination following the CNAME in a TXT, which shows LE/ACME that you control the DNS chain.

To do the DNS updating, you can use a CLI/Python library like Lexicon, which supports dozens of APIs:

* https://github.com/AnalogJ/lexicon

This leverages the ACME DNS server which has a REST API:

* https://github.com/joohoi/acme-dns

If your DNS provider has an API, you can hook into that for internal-only web servers; this handy code supports several dozen APIs so you don't have to re-invent the wheel:

* https://github.com/AnalogJ/lexicon

* https://pypi.org/project/dns-lexicon/

* https://dns-lexicon.readthedocs.io/en/latest/user_guide.html

> It even comes preconfigured for various DNS providers[2]

Also, CLI utility that supports a bunch of APIs:

* https://github.com/AnalogJ/lexicon

Then, you can use ddclient, which supports many DNS services (including those providing DynDNS protocol), or you can write a Python script using the dns-lexicon module to manipulate the DNS records over the API.