dhall-aws-cloudformation VS octoDNS

I have been writing a fair amount of Dhall using autogenerated CloudFormation bindings ( https://github.com/jcouyang/dhall-aws-cloudformation/ ). It is a fantastic way to reduce boilerplate and factor out recurring blobs. My main frustration is that the type checker is not smart enough (or maybe the type system is undecidable?) - every time you want to use a polymorphic function, you must pass in the type parameters yourself (this is also true for empty lists and `None`). This makes simple FP idioms extremely noisy, to the point where you're better off writing longhand. In a language that's meant to be alleviating YAML/JSON boilerplate.

It's still a massive improvement, but it could be so much better if the typechecker was smarter.

Change to a supported provider for octoDNS. I've done some automating of bind files using Jinja2/Ansible, but I had to roll my own.

I'd use OctoDNS with the ZoneFileSource to parse the zone files into the YAML files so I have structured data to work with, then I'd write a script to loop through each one and generate the above var.records data structure for each

We use https://github.com/octodns/octodns for some of our DNS records. It's flexible, much faster than Terraform for thousands of records, and the maintainer Ross has been responsive on issues and pull requests. Also see Cloudflare's blog for how they use it

OctoDNS https://github.com/octodns/octodns

Have them all hot and live rather than any sort of failover system. Keep everything in sync with OctoDNS or similar

https://github.com/octodns/octodns

Finally, you could explore the use of third-party sync tools - https://github.com/octodns/octodns might be a good choice.