Dnsmasq starts in wrong context after interface cycling?

I had a problem with Dnsmasq that led to my last post on understanding 
where policies come from. Now that I know and have had dnsmasq 
comfortably running with udp comms to unbound on port 553, I have run 
into the original problem that I thought I had caused.

I suppose I did cause it, but not in the way I imagined. I was awash 
again with AVCs from dnsmasq, but this time I took a closer look and 
realised the source context was not as expected. Instead of running in 
dnsmasq_t, it was running in resolvconf_t. I checked the binary and that 
was as expected so I restarted using run_init just to see if that was 
the problem, and it was! So now dnsmasq is running in the correct 
context, but how did it ever get to resolvconf_t? Surely if I had 
restarted it without using run_init then it would have been in sysadm_t?

One possibility is that it got into this context when my interface went 
down and up again. I had a problem last night with my Virgin fibre modem 
and I noticed that after the inevitable hardware reset, a bunch of 
services had been restarted. Besides the issue that dnsmasq is not bound 
to the interface in question, I guess I could test it quite easily, 
although I am not sure everyone else on the LAN will be too keen.

Any thoughts welcome

Robert Sharp