On 26/09/14 09:34, Christian Ruppert wrote: > Hi Simon, > > it's a VM with no real HW-Clock, that is correct. Using seconds since 1970 > would > be ok but the serial starts with "1" when dnsmasq has been (re-)started: > > # ps aux | grep dnsmasq > dnsmasq 17460 0.0 0.0 30296 956 ? S Sep25 0:06 > /usr/sbin/dnsmasq -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq --local-service > > So it's running since yesterday (2014/09/25) and has currently a serial of: > # dig -t SOA +short ipmi.rz.babiel.com @127.0.0.1 -p 5353 > . . 4947 1200 180 1209600 600 > > Now if I restart dnsmasq: > # /etc/init.d/dnsmasq restart > [ ok ] Restarting DNS forwarder and DHCP server: dnsmasq. > # dig -t SOA +short ipmi.rz.babiel.com @127.0.0.1 -p 5353 > . . 1 1200 180 1209600 600 > > It starts from 1 again.
This is a mystery. The code is quite simple, it's around line 212 in src/dnsmasq.c now = dnsmasq_time(); /* Create a serial at startup if not configured. */ if (daemon->authinterface && daemon->soa_sn == 0) #ifdef HAVE_BROKEN_RTC die(_("zone serial must be configured in --auth-soa"), NULL, EC_BADCONF); #else daemon->soa_sn = now; #endif If you can see how that code can end up with daemon->soa_sn having value 1 in your VM, that would solve the mystery. > > Re "--auth-soa": > I tried "auth-soa=20140926001" but: > # dig -t SOA +short ipmi.rz.babiel.com @127.0.0.1 -p 5353 > . . 2961056818 1200 180 1209600 600 > So that's not the serial that I specified. Anyway, after some time it > increased > to 19, 20, ... and after a restart it was again at "2961056818". So using > "auth-soa" won't help :( The serial gets incremented every time the DHCP lease database changes (because the domain includes names derived from the leases, so changing a lease can change the domain.) So that explains what you're seeing there. I concede it does make my suggestion not viable. I guess that's why the seconds-since-epoch value is used. It's a reasonable assumption that over a reasonable period, DHCP leases won't change more than once a second. Cheers, Simon. > > On 09/25/2014 11:04 PM, Simon Kelley wrote: >> On 25/09/14 10:39, Christian Ruppert wrote: >>> Hey Guys, >>> >>> I use the auth-zone, auth-sec, auth-peer features and I noticed that dnsmasq >>> looses its actual SOA resp. serial during restarts and thus it started again >>> from the beginning (1). All slaves were rejecting the changes because of >>> that >>> serial mismatch. E.g. the slaves all had "34286" and dnsmasq started from >>> "1" again. >>> It would be really good to save the serial in the lease file or somewhere >>> else >>> and re-use it afterwards to avoid such problems. Is that a bug or was it on >>> purpose? >>> >> >> It's supposed to work like this: >> >> The serial number starts as the time (seconds since 1970) when dnsmasq >> is started. Therefore stopping and restarting dnsmasq should _increase_ >> the serial. >> >> My guess is that you're using a platform which doesn't have a hardware >> real-time-clock, and so it's idea of the time gets reset whenever it's >> rebooted. Even if it uses NTP to get a good value of the time, this will >> happen after dnsmasq has started. >> >> >> You can set the initial serial number when starting dnsmasq using the >> command-line argument (or config option.) >> >> --auth-soa=<serial number> >> >> so you could implement something like the behaviour you want by keeping >> the serial in a file, incrementing it each time dnsmasq starts, and >> feeding it to dnsmasq via the command line. Shell scripting to do this >> left as an excercise.... >> >> >> Cheers, >> >> Simon. >> >> >> >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss@lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss