[GH-ISSUE #164] more efficient slave dns updates #154

New issue

Closed

opened 2026-02-26 09:36:09 +03:00 by kerem · 1 comment

kerem commented

2026-02-26 09:36:09 +03:00

Owner

Originally created by @ThomasWaldmann on GitHub (Sep 12, 2014).
Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/164

currently, when the master dns gets a dynamic update, it notifies its slave(s) and the slave then does a AXFR (zone transfer) to fetch the updated zone from the master.

it seems that zone transfer is not the most efficient way, especially if the zone gets rather big and the updates happen rather frequently.

an alternative might be to support multiple dns server entries in the nsupdate.info database and to send dynamic updates to them all to keep them all updated (and disable notifies in the master). if course this requires that the slave can be updated dynamically (and not just by notify/axfr).

Originally created by @ThomasWaldmann on GitHub (Sep 12, 2014). Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/164 currently, when the master dns gets a dynamic update, it notifies its slave(s) and the slave then does a AXFR (zone transfer) to fetch the updated zone from the master. it seems that zone transfer is not the most efficient way, especially if the zone gets rather big and the updates happen rather frequently. an alternative might be to support multiple dns server entries in the nsupdate.info database and to send dynamic updates to them all to keep them all updated (and disable notifies in the master). if course this requires that the slave can be updated dynamically (and not just by notify/axfr).

kerem

2026-02-26 09:36:09 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-26 09:36:09 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Sep 16, 2014):

I normal slave should do a IXFR (bind default configuration) which does an incremental, efficient update.

What I have seen (AXFR) seems to be caused by a strange software or configuration running on the (3rd party) slave DNS.

Closing for now, not a problem usually (and not our fault in this specific case).

@ThomasWaldmann commented on GitHub (Sep 16, 2014): I normal slave should do a IXFR (bind default configuration) which does an incremental, efficient update. What I have seen (AXFR) seems to be caused by a strange software or configuration running on the (3rd party) slave DNS. Closing for now, not a problem usually (and not our fault in this specific case).