Ns8-dnshelper - Tool to allow other modules to control your DNS records

,

I guess if someone else won’t do it, and you can’t do it yourself, have Claude do it. I’d posted API-based DNS management back in January, suggesting/requesting the ability for NS8 to manage DNS records via your DNS hosts’ APIs. The discussion yesterday and earlier today about email client autoconfiguration reminded me of this, because it’d be helpful for whatever tool was used to actually set the relevant DNS records, rather than just show the admin what needs to be set.

There ensued a discussion with Claude, which pointed me to libdns, “universal DNS provider APIs for Go.” Over the course of the day, this module was built. Its purpose is to provide a simple interface for other modules, allowing them to create, edit, or delete DNS records. ns8-dnshelper stores the individual DNS zones and their associated credentials, so that (e.g.) the Mail or Webserver modules don’t have to. The README documents how your module can use this.

At this time, only five providers are supported: Cloudflare, Hetzner, Name.com, GoDaddy.com, and generic nsupdate/RFC2136. I’d like to add others, but don’t have domains/credentials to use to test (I’ve already paid for test domains with Hetzner, Name.com, and GoDaddy.com). If you do, and would be willing to share for a few hours, I’d appreciate hearing from you.

This is, of course, the initial release of an AI-coded tool that was built today. Bugs are expected, and testing is appreciated. Please let me know here, or on the issues page of the repo.

Improvements

  • Testing, obviously.
  • More DNS providers. If you can share a domain that’s using, e.g., Route53 or OVH (or Gandi, or anyone else libdns supports) for DNS, along with API credentials, implementing it shouldn’t take more than a matter of a few hours. I’d obviously recommend you share ephemeral credentials and revoke them once I’m done.
  • Translations are AI-generated; I’d appreciate review (and PRs, if needed) by native speakers.
5 Likes

That might come in handy. Here’s a bit of a niche tool that I use:

If you’re interested in a niche provider like that https://www.core-networks.de, I can also give you the login information.

I hope so. As I mentioned, it’s the email autoconfiguration discussion that brought it back to mind–adding autoconfiguration for a mail domain involves at least three DNS records, and the more the tool can do automatically, the less chance the user has to mess it up. It’s my plan to have automx use this tool if it’s available, but not require it.

Eventually, I’d like to see modules like webserver, lamp, and especially mail able to use this, but that’s likely a “down the road” discussion.

As to Core Networks, it looks like their API is currently in beta–do you know how stable it is?

1 Like

It has been in that status for years. This is probably a label used as a protective shield for the provider.

BTW: I’ve just found another free DNS provider with a REST API:

If only migrating whilst keeping the existing DNSEC weren’t such a faff and so unreliable…

But at least there would be a good introduction.

OK, 0.2.0 is released. Here’s what’s new:

  • Admin-focused docs (ns8-dnshelper/docs/USER-GUIDE.md at master · danb35/ns8-dnshelper · GitHub).
  • Support for core-networks.de DNS, with thanks to @capote for the test domain and credentials used to develop it.
  • A “Records” page. This will let you list, add, and delete records for any managed zone. It’s really intended for testing purposes, so you can validate that dnshelper is working against your DNS host/domain. It isn’t intended to be a full-blown DNS record editor, though I may move that direction.
1 Like

Just released 0.3.0. Changes:

  • Add support for four more DNS hosts:
    • Digital Ocean
    • Linode
    • Porkbun
    • Route53 (AWS)
  • Added an access preset for ns8-automx, making it easier to set up that access rule
  • Fixed a bug in the Cloudflare and name.com adapters that prevented creating the necessary SRV records for automx
  • Now available through my software repo at danb35 NS8 modules

I’d be interested in some feedback here–about the project generally, but specifically on this question:

Would you see value in this becoming a full-featured DNS record manager? And if so, what features would you like to see added?

I ask because that wasn’t my intent–this app is intended to be what it says it is, which is a helper for other modules. automx, or mail, or webserver, or whatever can just call dnshelper to update DNS records, and not need to worry about DNS providers’ APIs themselves. But then I decided it’d be helpful for an admin to be able to test it out without using some other tool, and thus the Records page was born. And now I have something that kind of looks like it should be a general-purpose DNS record manager, but isn’t.

So, what do you think? Would it be worth fleshing this out a bit?

I find the app very interesting because my provider’s web-based interface keeps causing errors when creating or editing records, and it’s practically impossible to get a clear overview.

Monitoring and maintaining the records for the currently valid Active RSA issuer CAs requires regular maintenance.

In this table, entries are constantly being removed and new ones added. TLSA certificates can then become invalid, and the DANE configuration stops working.

I’m not sure if it might be possible to use your tool to check which CAs are obsolete and which ones can be added. If certificate rotation were also handled, that would significantly improve operational reliability.

I think this is really nice module!

Still, many users still struggle to configure DNS, and even more do not use a DNS provider that provides API access.

In my dreams I always wondered to have an authoritative DNS servers inside NethServer where all records are automatically created and maintained by apps.
But then comes reality: very few people can arrange a correct network setup to make the DNS server available and even less people are able to point NS records to the NethServer itself.

Maybe this module could be a small step in that direction! :crossed_fingers:

2 Likes

Which is exactly the point. An experienced admin is going to be able to set up the DNS records; this tool (in connection with whatever other app he’s using) just makes it more convenient. But automating the process may be the difference between success and failure for a less-experienced admin.

But the landscape has changed in the past several years, so that a great many DNS providers do provide this–and even provide it for free. Cloudflare is of course the big name, but Linode, Vultr, Porkbun, GoDaddy, just to name a few, all do as well. Don’t want it in .us? Fair; Hetzner has you covered (so do OVH and Gandi, but my tool doesn’t support them yet). Users have lots of options here, and they don’t have to cost much, if anything at all.

Just saying…

But I’m really not sure which is the better approach. Cloudflare (just as one example) have vastly better infrastructure than I’m ever going to have. They have multiple geographically-diverse nameservers, redundant power, backups, all that good stuff. All that points toward letting them serve my DNS, rather than me trying to do it myself. OTOH, if I’m doing it myself, I (or the software running on my system) have complete control, and I’m not subject to the quirks of whatever commercial DNS provider’s API (and I’m encountering lots of these) that I’m using.

Though as I think of it, you could do both. My tool already supports nsupdate/RFC2136. So if you were to develop a BIND package for Nethserver to provide public DNS, it should be pretty easy to wire my tool up to it. Presto, anything that can use my tool can now update the DNS server running on the NS8 instance.

I hope so. I expect the place that needs it most to be among the last to adopt it, though: mail. Mail’s obviously a critical part of many folks’ infrastructure, and it’s one of relatively few apps you’ve tagged at support level 5. I don’t expect you’re going to jump into modifying it to work with this brand-new tool (though I hope you will do so eventually).

OTOH, mail depends so heavily on DNS. Even leaving autodiscovery aside (which I’m handling separately, of course), there are so many other records–MX, SPF, DKIM, DMARC, TLSA, just to name a few. Most of these have very specific requirements. To have the mail module be able to just push those records out to the user’s DNS host would be a big win.

2 Likes

Is that core-networks? If so, thanks to your help, this tool does now support them.

I think that would really be the task of another app, probably the mail app.

But have you checked out the Records page of this app? Though it wasn’t really designed for this purpose, it might give an easier-to-use interface for you to make the changes to your records as you need them.

yes it is. Thank you for your fast implementation.

t might give an easier-to-use interface for you to make the changes to your records as you need them.

Yes I saw it it it the GUI your GUI is much better.

The weakness of all the UIs I’m familiar with is that they’re always just unstructured lists sorted alphabetically.
I have no idea how this could be done, but grouping items by topic—such as general records, email records, web server records, or similar—could make things clearer.
Your attempt to spread the records across multiple pages based on the number of entries displayed means that users either have to switch between pages or remove the line limit.

This cannot be said or emphasized strongly enough. A convenient, error-reducing solution has significantly lowered the barriers to entry.

You can sort by the record type, which may help. That still doesn’t get to the purpose of the record, though (especially with TXT records, which are used for just about everything). And it does let you search, though you obviously need to know what you’re searching for.

I expect that’s a matter of Claude reusing an existing list widget, one which I complained about here: UI bug - list chunking doesn't persist. And it makes sense to reuse UI elements, but this one has some bugs that I hope will be fixed upstream shortly.

1 Like

I’ve released dnshelper 0.4.0 today, adding support for six more DNS providers:

  • deSEC
  • Gandi
  • Google Cloud DNS
  • IONOS
  • PowerDNS
  • Vultr

This brings the total to 16 supported DNS providers, all tested against real zones on live accounts (except for RFC2136 and PowerDNS, which were tested against local instances). I’ve also made sure to have some European providers, since I recognize some of you wouldn’t be comfortable using a US-based service at this point.

An interesting incidental finding, though: When I started this project, I figured I’d be able to use libdns code, and really just build a wrapper around it. It turns out, though, that only three of the supported providers (RFC2136, Hetzner, and Route53) were able to use the libdns adapter as-is. Two more (Cloudflare and name.com) use a patched version of the libdns adapter to work around a bug, and the remaining 11 use completely new adapters, mostly due to bugs in the upstream project. There’s a lot more of “my own” (that is, Claude’s own) code in this project than I’d expected; I should probably work on pushing some of this upstream.

The good news is that Claude doesn’t seem to have any trouble writing these adapters, and is able to knock one out, including a good bit of testing, in under an hour.

1 Like

Something just occurred to me. It would be nice if you could quickly back up the zone in the GUI before editing it and, in case of an error, quickly restore the zone file.

Good idea. I’m not sure I want to expand the scope of this to be a full DNS zone manager, but I’ve added this to the list in case I do. I’d appreciate any other suggestions along these lines–if I were going to incorporate a zone editor, what features would you want to see? Editing existing records (rather than delete/add that you currently have to do) is an obvious need. But what else?

1 Like

really impressive dan, I did a tour of the code, not a review on my side but It feels good

good project

4 Likes

I might help testing OVH DNS zones.