API endpoint to manage custom dns entries?

[jdani]

Hi all 😃

my gut feeeling tells me this is something that has been discussed somewhere before, but I didn't find it, so here it goes

In my homelab I was running blocky as an adblocker and internal dns server. It just works, no more complex than needed, but neither simpler. I like that 👍

But when I started using external-dns to get my ingresses fqdn's availables from the network automatically, I realized there was not a blocky provider. I tried to figure out an out of the box approach to make it work (updating the config and reload the config, for example?). I think a dedicated API Endpoint to manage the custom dns records can be useful in a number of situations, but in particular to write an external-dns provider.

Does this sound useful for someone else?

Regards

[ThinkChaos]

I personally don't like the idea of creating an API for this as it's essentially dynamic DNS which is standard.
So I would say it seems out of scope and to look into running a full DNS server upstream of blocky.

[jsclayton]

Does this sound useful for someone else?

🙌🏼 Yes! Ended up here also searching for external-dns interoperability. Blocky is sooooo close to my ideal home DNS solution with this one exception of not being able to point LAN users at apps running in my k3s cluster. I've also been looking at options for hacking existing features to do what I want, but an actual feature would be ideal.

Options I've considered:

• An external service running alongside Blocky that receives and persists the webhooks from external-dns.
  • It could update the config file's customDNS.zones entry and reload restart Blocky. Pro is that it uses the config file for persistence, con is that Blocky doesn't have a reload config and needs to be restarted.
    • Same update to the zones config, but using the $INCLUDE directive and a file change watcher.
  • It could expose the entries in a hostsfile syntax, which could be added in Blocky in hostsFile.sources and periodically downloaded. Pro is that a reload or restart isn't necessary, con is that it would only support A and AAAA records.
  • Updating the custom DNS resolver to allow downloading and updating from an external service similar to hose the hosts file resolver does. Pro is that the functionality to download already exists, just needs to be ported into the resolver, con is that I'd want it to download zone format for full fidelity, which may make the config more confusing.
• A generic API for managing custom DNS records. It could be implemented as part of the custom DNS resolver or as its own resolver. Persists to disk but serves from memory. An external-dns webhook provider could read and write with it. Pro is that it's generic, so not limited to external-dns, con would be needing to plumb HTTP API access down into the custom DNS resolver.
• HTTP endpoints specifically for the external-dns webhook. Probably done as a stand-alone externalDNSResolver. Persist to disk but serve from memory. Pros include native compatibility, so not having to run a sidecar with external-dns, and being simpler than trying to make a generic API, cons include the hard dependency on the external-dns webhook API and maintaining compatibility.

Of all of these, I really like the last one - an external-dns webhook built right in. Is that something the project would be open to as a contribution?