New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

import of existing zones to DB to save command line changes #90

Closed
empanadadexoubas opened this Issue May 8, 2014 · 14 comments

Comments

Projects
None yet
4 participants
@empanadadexoubas

empanadadexoubas commented May 8, 2014

Hello,

I have an environment in which web updates will be made by customers and admins, but console or SSH changes could be done too by admins.
It would be possible to create a programmable task to read all zone files and write its records to database to save manual changes in files with a text editor?
Maybe an adaptation of zoneImportWizard() function?

Thank you for your attention and for this very useful project.

@WillyXJ WillyXJ added feature labels May 8, 2014

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented May 8, 2014

Hello,

Thank you for this idea. The idea behind facileManager is to alleviate manual changes on the servers themselves. I'll consider this feature to see how it could be implemented.

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented Aug 14, 2014

Given this some thought and discussed it with another user. It seems in order for manually modified records (or managed through dynamic updates) to end up in the fM database for future zone reloads, the client would need to POST back the zone file to the server for record comparison. This could potentially make zone reloads slow with large environments. After kicking around some ideas, it seems the best solution to support this feature is to have a tick box to toggle for each zone so only selected zones will automatically update the database. In theory, this would be a small amount of zones in the entire infrastructure.

@WillyXJ WillyXJ added this to the 2.0 release milestone Aug 22, 2014

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented Mar 3, 2015

I'm going to post-pone this implementation to sort out a more solid method of importing. Adding new records via fmDNS or CLI would work as an import, but the use case came up of User1 updates a record on the CLI and User2 then updates the same record in fmDNS to a different value - which would be correct and how would fmDNS know? This is what needs to be sorted out.

@WillyXJ WillyXJ removed this from the 2.x release milestone Mar 3, 2015

@wispr

This comment has been minimized.

wispr commented Mar 17, 2015

Jon, I've gone around a few times with this thought too. In our environment, we too have a web portal that our customers can change DNS and unfortunately we run two separate DNS systems because of that at the moment. You and I had talked about the freeze/thaw options in BIND as it relates to Active Directory. We still cannot integrate our AD environment into this BIND environment because AD uses dynamic zones. If fmdns can use the freeze/thaw command, you could support dynamic zones with AD (yeah for me) but you might be able to use that same logic for zones controlled by multiple endpoints. IE, if a given zone could be updated by customers in a web portal, admins via ssh, and customer support reps via fmns, maybe you set that zone to dynamic in bind, fmdns issues a freeze on it, updates the record, and then thaws it again. You can track all of the changes the fmdns is making to the zone in a changelog for the zone. You'd have to check the serial number on the zone and use it to make sure you aren't reverting.

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented Mar 17, 2015

v2.0 will incorporate freeze/thaw during reloads. Thanks for the suggestion on how to potentially use the logic to fully support this request. Perhaps it can be included in a minor release.

@wispr

This comment has been minimized.

wispr commented Mar 17, 2015

oooohhhh, I'm exited for that. That means we can integrate our AD domain in BIND and use it for actual split horizon! Mostly though, since DNS updates in AD won't actually make it into fmdns, just in bind....

@peterschen

This comment has been minimized.

Contributor

peterschen commented Mar 18, 2015

I've tested freeze/thaw some more. In bind the zone file will be updated when dynamic updates are made to the zone.

When a reload/buildconf is triggered these dynamic changes are essentially gone.

I'm not sure what your ideas are around AD integration so I don't know exactly if this has impact on interoperability with AD integrated DNS.

@wispr

This comment has been minimized.

wispr commented Mar 18, 2015

Peter, you're 100% correct. Freeze/thaw is step 1 for dynamic updates with AD. Step 2 is this request, basically sync'ing data from bind into fmdns. I like the idea of defining a "dynamic" zone in fmdns, which can basically mean that other tools are updating the zone files and fmdns needs to update itself first.

when someone in fmdns clicks on a dynamic zone:
1.)freeze dynamic zone
2.)compares/imports/syncs/whatever existing dynamic zone into its db to ensure up to date copy
3.)thaw
4.)user makes changes in fmdns
5.)when use clicks reload, freeze, commit changes, thaw

@peterschen

This comment has been minimized.

Contributor

peterschen commented Mar 18, 2015

I like the idea of having the option to mark a zone dynamic. This way we only need to process those marked as dynamic and save a lot of time by just generating the config for all static zones from db.

I was thinking if the following would also be a valid option: instead of writing the whole zone file an algorithm is devised which calculates the differences between the old zone and the new zone and instead of simply writing the whole zone file only the differences are applied.

A "downside" to this is that dynamic changes would not turn up in fmDNS. In case of AD or DynDNS enabled DHCP this is fine in my opinion.

@WillyXJ WillyXJ modified the milestone: 3.0 release Dec 4, 2015

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented Jan 28, 2016

I'm currently working on this feature in the 3.0 development branch. The easy work has been added to flag a zone with dynamic updates support (checkbox) and now the work to support it is proving to be quite challenging.

From a user-perspective, it seems to make sense to freeze, import zone from one DNS server, and then thaw the zone when a user clicks to edit the zone via the UI. This way the zone will be fully represented at that time of editing.

However, between the time of zone edits and reloading the zone, more changes could have taken place in the zone file directly via dynamic updates. So, during a reload, the freeze, compare/update, write, thaw process would have to occur in order to preserve the changes.

Would it make more sense to only perform the compare/update at zone reload time rather than the additional process while editing the zone within the UI leaving the user partially blind to the dynamic zone? Or perhaps a button at the top of the zone edit page to initiate a zone compare/update?

I'd like to see what some of you (users) think so any feedback/ideas you have would be most appreciated and helpful in determining the direction of this feature development.

@wispr

This comment has been minimized.

wispr commented Feb 3, 2016

Yeah, maybe a button to launch the compare/update might be a good way to
go. Or maybe that process is launched when a user tries to edit a zone.

User clicks edit, the zone is compared/updated, and the zone is then
displayed to the user. User makes their changes, hits submit, and a
compare/update is done again.

Robbie Wright
Siuslaw Broadband https://siuslawbroadband.com
541-902-5101

On Thu, Jan 28, 2016 at 12:32 PM, WillyXJ notifications@github.com wrote:

I'm currently working on this feature in the 3.0 development branch. The
easy work has been added to flag a zone with dynamic updates support
(checkbox) and now the work to support it is proving to be quite
challenging.

From a user-perspective, it seems to make sense to freeze, import zone
from one DNS server, and then thaw the zone when a user clicks to edit the
zone via the UI. This way the zone will be fully represented at that time
of editing.

However, between the time of zone edits and reloading the zone, more
changes could have taken place in the zone file directly via dynamic
updates. So, during a reload, the thaw, compare/update, write, thaw process
would have to occur in order to preserve the changes.

Would it make more sense to only perform the compare/update at zone reload
time rather than the additional process while editing the zone within the
UI leaving the user partially blind to the dynamic zone? Or perhaps a
button at the top of the zone edit page to initiate a zone compare/update?

I'd like to see what some of you (users) think so any feedback/ideas you
have would be most appreciated and helpful in determining the direction of
this feature development.


Reply to this email directly or view it on GitHub
#90 (comment)
.

WillyXJ added a commit that referenced this issue Mar 30, 2016

WillyXJ added a commit that referenced this issue Aug 1, 2016

fmDNS - #90 - dynamic zone loads
When editing a dynamic zone, the data is pulled/compared from one DNS
server
@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented Sep 8, 2016

This is now included in 3.0-alpha1 and later. More testing required.

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented Dec 9, 2016

Has anybody been able to test this feature in the 3.0-alpha releases? It's such a big change that I'd like some feedback prior to the stable release.

WillyXJ added a commit that referenced this issue Apr 12, 2017

@WillyXJ

This comment has been minimized.

Owner

WillyXJ commented Jun 23, 2017

This is now included in 3.0 and later.

@WillyXJ WillyXJ closed this Jun 23, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment