Bug 4091 - Reloading Unbound causes Auth zone data to be merged with previous auth zone data and not replaced
Reloading Unbound causes Auth zone data to be merged with previous auth zone ...
Status: ASSIGNED
Product: unbound
Classification: Unclassified
Component: server
1.7.0
Other Windows
: P5 normal
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-20 15:57 CEST by John Wigley
Modified: 2018-06-15 18:03 CEST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Wigley 2018-04-20 15:57:58 CEST
There appears to be a bug in Unbound 1.7.0 which means that if you define an authzone using a local zonefile and then update the zonefile, and then reload Unbound - the old and new zonefiles are merged instead of the new data replacing the old.

Steps to reproduce:
Create a local zone file with an A record = 1.1.1.1
Add an auth zone to the conf file using the local zonefile
Update the local zone file so the same A record now = 1.1.1.2
Reload Unbound using Unbound-Control
Query Unbound for that auth zone's A record - you will see that Unbound returns two A records with the old AND new values.

2nd related issue: if you remove an auth zone from the config, and then reload, then the auth zone continues to be served and is not removed as would be expected.

This all seems to be the same underlying behaviour - which is that upon reload Unbound just adds any authzones found to the existing in memory structure rather than replacing the in memory structure with the contents of the auth zones at the point of reload. Given that there doesn't appear to be any desriable reason for this behaviour I'm considering it to be a bug.
If you use auth zones then it's quite a problem as it leads to out of date zone data being served.

Also, there doesn't appear to be any functionality in Unbound-control to handle adding/updating/removing auth zones which different from all the other locally defined zone types such as local/forward/stub etc where Unbound-control supports adding/updating/removing zones for all of those types.
Comment 1 Wouter Wijngaards 2018-04-20 16:02:02 CEST
Hi John,

That is certainly not wanted.  The initial reason for the code was that due to zone transfers, the internal memory version of the auth zone could be (a lot) better than that zonefile; and rereading it wouldn't make sense.  So, it needs to keep track of that somehow, i.e. does rereading make sense.  And also the delete.

The unbound-control stuff sounds useful to have.

Best regards, Wouter
Comment 2 John Wigley 2018-04-20 16:12:38 CEST
From the perspective of zone transfers, that makes sense why it wouldn't necessarily always reload from disk.

Maybe the right approach then is for it to check which is newer, but I think it should definitely NOT merge old and new data.

Although not a bug it would definitely be very useful for Unbound-control to be able to instruct it to update a particular zone without having to stop and restart the whole server as you do now.
Comment 3 Wouter Wijngaards 2018-04-20 16:13:51 CEST
Hi John,

This patch, also committed to the code repository, should fix the problem of the merged contents.  It'll reread the file but replace the in-memory contents with the file contents.  (It doesn't treat the zone transfer vs. memory case and unbound-control features).

Index: services/authzone.c
===================================================================
--- services/authzone.c	(revision 4637)
+++ services/authzone.c	(working copy)
@@ -1560,6 +1560,11 @@
 		free(n);
 		return 0;
 	}
+
+	/* clear the data tree */
+	traverse_postorder(&z->data, auth_data_del, NULL);
+	rbtree_init(&z->data, &auth_data_cmp);
+
 	memset(&state, 0, sizeof(state));
 	/* default TTL to 3600 */
 	state.default_ttl = 3600;
Comment 4 Wouter Wijngaards 2018-04-20 16:14:55 CEST
Hi John,

Was busy implementing that patch, you are right that is the worst bug.  The others are nice to have, and I'll look at it.

Best regards, Wouter
Comment 5 Wouter Wijngaards 2018-04-20 16:47:08 CEST
Hi John,

I also implemented a fix that deletes zones when removed from config.  It has been committed to the code repository.

Best regards, Wouter
Comment 6 John Wigley 2018-04-20 17:21:52 CEST
Wouter,

Thank you so much for fixing that so quick, really appreciate you taking the time to deal with it.

Do you know when there is going to be an automated build for Win64 with this fix in it? I don't have a suitable build environment and so need to wait for the binaries to be updated?

Many thanks,

John
Comment 7 Wouter Wijngaards 2018-04-23 09:44:34 CEST
Hi John,

Here is a win64 build output with the fixes so far (of the code repository), it is a snapshot build:

http://open.nlnetlabs.nl/~wouter/unbound-1.7.1_20180423.zip and unbound_setup_1.7.1_20180423.exe

Best regards, Wouter
Comment 8 Wouter Wijngaards 2018-06-15 16:27:22 CEST
Hi John,

Unbound-control auth_zone_reload zonename is implemented, reads the file.  It does not reload the entire server, but only that file.

Best regards, Wouter
Comment 9 John Wigley 2018-06-15 16:50:44 CEST
Wouter, that's great news, thanks!
Look forward to trying it when the win binaries are updated.

John
Comment 10 John Wigley 2018-06-15 18:03:50 CEST
Wouter,

Along with the unbound-control auth_zone_reload zonename, is there planned to be the ability add/remove auth zones from unbound-control - as that would complete the feature set similar to local zones? Currently you have to reload the whole server config to add/remove auth-zones which seems overly resource intensive.

Thanks,
John