Redundancy (clustering) support

[rlagmlah]

Hello. TechnitiumDNS is often unresponsive. The cause is unknown, but usually when run for more than 3 days in a row. This issue seems to have no problems during the daytime if I restart TechnitiumDNS every night, but with a low probability (2% in my case) there was a case where TechnitiumDNS stopped working. To solve this, 2 TechnitiumDNS were executed respectively, and 2 TechnitiumDNS were registered in the DHCP server, but it is difficult to manage the settings and statistics because each DNS server has independent configuration files. I think it will be very helpful for stability if it supports clustering officially. thank.

[ShreyasZare]

Thanks for the feedback. Clustering is already in my to do list but it wont be available immediately as next release is more focused on ability to host primary, secondary and stub zones and for optimizing how zone data is stored in memory. The zone optimization should make the server more responsive under load.

[ShreyasZare]

New release is now available. This should fix most of the scaling issues.

[rlagmlah]

After applying the new release, the server became much more stable. The response is also stable. Now I'm going to test how many days it works without restarting the server. However, even if the server operates stably, I think it is better to use two or more servers for high availability. Nothing is more annoying than the sudden disconnection of the Internet. :)

[ShreyasZare]

Thanks for the feedback. I hope it works well and is stable. And as you said, redundancy is always useful no matter how well your infra is setup.

[rlagmlah]

The secondary DNS server ran without problems for 10 days without restarting, and the main DNS server ran without error for 14 days. It works stably. I decided to restart every weekend at dawn. :)

[ShreyasZare]

The secondary DNS server ran without problems for 10 days without restarting, and the main DNS server ran without error for 14 days. It works stably. I decided to restart every weekend at dawn. :)

Thanks for sharing. I am planning on using async IO which should improve the performance even more. Will update on it.

[Hemsby]

I am currently running 2 DNS Servers for redundancy/resilience and also interested in DHCP Failover and an AD like DNS Setup, where both are writeable. Currently having to have 2 DNS Servers, only 1 with DHCP, and the other with secondary zones only. So if the first is unavailable, no DHCP and even if static address no DNS Entry in the second DNS Server. Also as mentioned having to manually mirror the setup from one to another, ie dns blocked domains, forwarders etc is ok as its simple but would be nice to have a shared location for setup and logs etc

[ShreyasZare]

I am currently running 2 DNS Servers for redundancy/resilience and also interested in DHCP Failover and an AD like DNS Setup, where both are writeable. Currently having to have 2 DNS Servers, only 1 with DHCP, and the other with secondary zones only. So if the first is unavailable, no DHCP and even if static address no DNS Entry in the second DNS Server. Also as mentioned having to manually mirror the setup from one to another, ie dns blocked domains, forwarders etc is ok as its simple but would be nice to have a shared location for setup and logs etc

Thanks for the feedback. This should be available in a few months time.

[Zorlin]

Huge +1 for this - I'd particularly like to see cluster(able) DHCP, as I just switched away from a highly available Kea solution to Technitium in a very important installation serving two people 🤣 as Technitium has much nicer management of static leases, dynamic DNS and other niceties.

[MisterDeee]

Any update on this feature request? Am manually handling the sync between two servers but would be great to not have to :)

[ShreyasZare]

Any update on this feature request? Am manually handling the sync between two servers but would be great to not have to :)

Currently, multi user role based access support is being implemented. The clustering feature is planned after that major update.

[westdam]

hi, i agree on dhcp cluster or failover function. should be nice.

[westdam]

news about it?

[ShreyasZare]

news about it?

It will come after DHCPv6 feature is implemented.

[ViktorBarzin]

Hey checking in for updates :) Thanks for all the great work you've been doing, Technitium is awesome :)

[picanl]

Hey checking in for updates :) Thanks for all the great work you've been doing, Technitium is awesome :)

any updates in this feature? no pushing.... just curious

[computerkoenig]

Hey checking in for updates :) Thanks for all the great work you've been doing, Technitium is awesome :)

any updates in this feature? no pushing.... just curious

I don't think that they release this feature verry soon. I'm waiting for a long time now. Even before the creation of this thread and its the only reason why I'm still not able to use technitium in most cases. Its the only big and powerfull next-gen dns I know, which is not able to build a cluster..... But if the developers would think the same about it, the feature would already exist.

Btw: Does anyone know another, not annoying, way to rollout 2-n technitium servers in a docker/kuberneetes Cluster with automatic replication of everything?

[madeofpendletonwool]

I tried exposing the relevant volumes of two technitium containers and rsyncing them between the two different servers. Didn't work great. Technitium writes a lot of data so there was too many conflicts.

[jho1670]

FYI: https://gravity.beryju.io/ in docker has been working well for me since it offers redundancy.

[ShreyasZare]

Hey checking in for updates :) Thanks for all the great work you've been doing, Technitium is awesome :)

any updates in this feature? no pushing.... just curious

Thanks for asking. Will try to get this feature prioritized since its being requested frequently. This means other planned features like DHCPv6 will be done after this.

[rinseaid]

Just chiming in with my vote for clustering to be prioritized ahead of DHCPv6. ;)

[picanl]

FYI: https://gravity.beryju.io/ in docker has been working well for me since it offers redundancy.

prefer clustering in Technitium

[advisorgee]

another vote for clustering over DHCPv6.

[techguydave]

Also throwing in a vote for clustering over DHCPv6

[ShreyasZare]

Also throwing in a vote for clustering over DHCPv6

Initial clustering is planned for DNS zones and overall settings. DHCP clustering support will be added later with DHCPv6.

[The0cdguy]

I'm adding yet another vote for redundancy. In my use case, high availability is much more important than DHCPv6.

[westdam]

Agree.

Redundancy is higher for me too instead dhcpv6

Byez Marco

Il sab 23 dic 2023, 22:17 Jamie @.***> ha scritto:

I'm adding yet another vote for redundancy. In my use case, high availability is much more important than DHCPv6.

— Reply to this email directly, view it on GitHub https://github.com/TechnitiumSoftware/DnsServer/issues/134#issuecomment-1868371658, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP7YGHRTQ5E5MMZOTVOZSZ3YK5DAHAVCNFSM4MOZHPLKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBWHAZTOMJWGU4A . You are receiving this because you commented.Message ID: @.***>

[majiajun7]

Subject: Support for Redundancy (Clustering) in TechnitiumDNS

Dear @ShreyasZare and TechnitiumDNS Community,

I've been closely following the ongoing discussions regarding the implementation of redundancy (clustering) support in TechnitiumDNS, specifically in the context of issue #134. The insights shared by various contributors, notably @rlagmlah, have highlighted the critical need for stability and high availability in DNS services.

As someone who appreciates the robustness and user-friendly features of TechnitiumDNS, I strongly believe that introducing clustering support would significantly enhance its reliability. The challenges outlined by users, such as @Hemsby and @computerkoenig, regarding the manual synchronization of settings and the need for a seamless failover solution, resonate with my own experiences.

The progressive updates and responsiveness from the Technitium team, particularly in addressing scalability and performance issues, are commendable. However, as the demand for uninterrupted internet connectivity grows, the importance of redundancy cannot be overstated. It's encouraging to see the community's unanimous support for prioritizing clustering over other features like DHCPv6, as echoed in recent comments by @rinseaid and @The0cdguy.

In conclusion, I add my voice to the chorus of users advocating for the swift integration of clustering capabilities into TechnitiumDNS. This feature is not just a convenience but a necessity for ensuring continuous and reliable DNS services in various deployment scenarios.

Thank you for your dedication to enhancing TechnitiumDNS, and I eagerly await further updates on this feature.

Best regards, majiajun

[ShreyasZare]

@majiajun7 Thanks for the feedback and kind words. The clustering feature is already prioritized now and is in design phase with reading of Catalog Zones (RFC 9432).

Note that it may take a couple of releases for this to be available. The next release is already being worked for some common options, bug fixes, and upgrade to .NET 8 runtime. Later, the next major release should have Catalog Zones support at minimum and mostly full clustering support too.

[Prevok]

Looking forward clustering as well. I am slowly testing TechnitiumDNS for a future migration from Pi-hole.

In the meantime, assuming I run 2 instances, is it safe to:

• Stop server 1 and 2
• Rsync the config folder over server 2
• Restart both servers?

Should I target only specific files or would I even be able to rsync the content while server 1 is running?

I am planning on testing that scenario next week. It's mostly my existing flow with Pi-hole, copying over the static entries from dnsmasq, altough I don't have to stop server 1, as it's flat text files. Essentially I want to script replicating the static DNS entries. DHCP is a non issue, as both servers will server different range, at least for now.

Thanks.

[Prevok]

Looking forward clustering as well. I am slowly testing TechnitiumDNS for a future migration from Pi-hole.

In the meantime, assuming I run 2 instances, is it safe to:

• Stop server 1 and 2
• Rsync the config folder over server 2
• Restart both servers?

Should I target only specific files or would I even be able to rsync the content while server 1 is running?

I am planning on testing that scenario next week. It's mostly my existing flow with Pi-hole, copying over the static entries from dnsmasq, altough I don't have to stop server 1, as it's flat text files. Essentially I want to script replicating the static DNS entries. DHCP is a non issue, as both servers will server different range, at least for now.

Thanks.

I may have just answered my own question. Looks like I can simply copy over the zone files live and then restart server 2. As long as there isn't anything writing in the zones at the same time (in either one of them), I think this will accomplish what I need for now.

[gigantuar]

Looking forward clustering as well. I am slowly testing TechnitiumDNS for a future migration from Pi-hole. In the meantime, assuming I run 2 instances, is it safe to:

• Stop server 1 and 2
• Rsync the config folder over server 2
• Restart both servers?

Should I target only specific files or would I even be able to rsync the content while server 1 is running? I am planning on testing that scenario next week. It's mostly my existing flow with Pi-hole, copying over the static entries from dnsmasq, altough I don't have to stop server 1, as it's flat text files. Essentially I want to script replicating the static DNS entries. DHCP is a non issue, as both servers will server different range, at least for now. Thanks.

I may have just answered my own question. Looks like I can simply copy over the zone files live and then restart server 2. As long as there isn't anything writing in the zones at the same time (in either one of them), I think this will accomplish what I need for now.

Why not just set the zones up as secondary zones on the 2nd server and let them sync natively?

[ShreyasZare]

Looking forward clustering as well. I am slowly testing TechnitiumDNS for a future migration from Pi-hole.

In the meantime, assuming I run 2 instances, is it safe to:

* Stop server 1 and 2

* Rsync the config folder over server 2

* Restart both servers?

Should I target only specific files or would I even be able to rsync the content while server 1 is running?

I am planning on testing that scenario next week. It's mostly my existing flow with Pi-hole, copying over the static entries from dnsmasq, altough I don't have to stop server 1, as it's flat text files. Essentially I want to script replicating the static DNS entries. DHCP is a non issue, as both servers will server different range, at least for now.

Thanks.

Its even simple. Just use the Backup option on the first server to export a backup zip file for the specific things you want to copy and then use that zip file with the Restore option on the second server. This works without restarting and no downtime.

If you wish to sync just the zones then as @gigantuar mentioned, just create a secondary zone on the other server and it will auto sync any change you make in the primary zone.

[liamdawson]

One gap I've encountered in the current primary/secondary zone design is replicating conditional forwarding zones. I would like to create a conditional forwarding zone on the primary server, and sync the records within that to the secondary server. I haven't found any way to achieve that as of yet.

[ShreyasZare]

One gap I've encountered in the current primary/secondary zone design is replicating conditional forwarding zones. I would like to create a conditional forwarding zone on the primary server, and sync the records within that to the secondary server. I haven't found any way to achieve that as of yet.

This is not possible with the current release since the standard zone transfer and update mechanism works only with primary and secondary zones. Conditional forwarder zones are proprietary to the DNS server and do not have SOA records for the standard mechanism to work. The clustering feature will support this though.

[anonhostpi]

Is there a branch or fork for this feature yet that we can follow?

[ShreyasZare]

Is there a branch or fork for this feature yet that we can follow?

@anonhostpi the feature is still being designed. No code is yet pushed. Also, its not recommended to use code from develop branch as it may not be fully integrated.

[Ninjadude101]

I'm also eagerly waiting for clustering support :)

[liamfleming26]

Adding my vote for the clustering features too. Understand there are some intricacies with the proprietary conditional forwarding zones. Great work regardless!

[JL421]

At this point this issue has been open for over 50% of this project's lifetime, and it's always going to come "after the next major update" or some new feature. I'll be surprised if it ever actually shows up in a production release. I'd love to be proven wrong, but the stalling is getting old.

[jho1670]

It seems unreasonable to berate and accuse the maintainer of "stalling".

If you don't like it, find other software.

[gigantuar]

I agree with @jho1670

Would love to see redundancy myself as well, but this is a large project with one person working on it.

[rinseaid]

Better yet, @JL421, maybe the author would accept pull requests if you're willing to write the functionality?

[JL421]

@jho1670 I mean that's your prerogative, but at this point what else can you call it?

2020-04-23: Clustering is already in my to do list but it wont be available immediately as next release is more focused ...

2020-07-07: ... redundancy is always useful ...

2021-01-20: ... This should be available in a few months time.

2022-07-21: Currently, multi user role based access support is being implemented. The clustering feature is planned after that major update.

• Looks like v9.0 was the next major release after this comment. We're currently on 12.1

2023-04-07: It will come after DHCPv6 feature is implemented.

2023-10-31: ... Will try to get this feature prioritized since its being requested frequently. This means other planned features like DHCPv6 will be done after this.

2023-12-11: Initial clustering is planned for DNS zones and overall settings. DHCP clustering support will be added later with DHCPv6.

2024-01-05: ... The clustering feature is already prioritized now and is in design phase ...

2024-02-18: ...the feature is still being designed. ...

[jho1670]

Thank you @ShreyasZare for the work that you do.

[JL421]

@rinseaid That's kind of what appears to be the problem. They're hesitant to let people work on the core of the project because "core features require deep understanding of DNS concepts".

Maybe if they were slightly more open to discussing the problems they're encountering with implementing features they could get more assistance with the project? Maybe somewhere in the development goal to serve ~400mbps of DNS responses off of a seven year old desktop CPU, core design decisions were made that make clustering a near impossible task? Maybe there's a reason why you can't configure two independent instances to "cluster" with each other through the already existing API endpoints?

Who's to say on any of that apart from the developer who hasn't shared any progress, roadmap, development challenges, or thoughts on this issue?

[computerkoenig]

It seems unreasonable to berate and accuse the maintainer of "stalling".

If you don't like it, find other software.

powerdns for example. dns clustering is the most common thing dns servers are able to. even this ... windows dns server.

it's just a shame that the maintainers are working on every other crap that most users will never use or even need.

I'm disappointed and afraid, that people could be so far from reality. And I'm disappointed to read the same lies again and again. "soon", "in the next release", ...

Congrats, you really made it. Once I loved Technitium, but now I will switch to anything else without lying developers.... Even if lots of - mostly useless - functions are missing.

Hope you're happy now!

[rinseaid]

Good. So that's one person that will no longer clutter this issue with noise.

Please, all, let's keep this issue on topic toward forward advancement of the feature of clustering and not on complaints and commentaries about your expectations of software you haven't paid for or contributed to. Please feel free to use social media for those discussions.

[JL421]

No, I have no plans on going anywhere. Look, maybe we started off wrong, I'll try this again.

Ahem

Hi there, I too would also like to raise my support for adding the clustering feature that has been much talked about for a few years. I know development can be difficult, especially on core services to many networks like this project touches. You also seem to mostly be working on this project alone.

Help us help you:

• A Wiki could help remove some of the common questions raised in Issues and Discussions, and could be community populated through pull requests
• Utilizing the Projects tab could help potential contributors see where you'd like to focus development energy and give more visibility to users on progress on bug fixes, feature requests, etc.
• Some contribution guidelines, issue templates, or pull request templates could also help the community help you along
• And even on specific issues, letting us know what roadblocks, proposals, RFCs, etc. you've had can help move things along

You have a passionate group of supporters here, and I'm sure they'd like nothing more than to help contribute if given the tools to help you more. Or maybe not, I can't speak for anyone but myself.

---

Anyway, pandering aside, I know money isn't a motivator on these kinds of projects. It doesn't buy time, which is what everyone needs more of. I've still signed up for the Patreon just in-case it helps get some of these older, highly requested and commonly available features across the line. Who knows, it might be enough to get more eyes on the project, and get you some more coding help.

[liamfleming26]

F*** me, I know I commented on an old issue / feature request but really didn't expect this response.

This thread was here from the initial issue and to express your intrest. Not to start moaning and taking jabs at the developer.

That's the beauty of free software. Free to use, also free not to use it and use somthing else instead.

Solid work @ShreyasZare ! Patiently awaiting any releases to test.