NetworkManager[792]: <warn> dnsmasq not available on the bus, can't update servers.

Starting to dig around that rrsig failure:

Looks like bind9 settings need to be blamed.

This is what i've changed inside /etc/bind/named.conf.options:
// dnssec-validation auto; # disabled for testing
dnssec-enable no; # added

Also suspect the deprecated ntpdate; so i've purged it.

Then i've rebooted and i've seen a much more cleaner journalctl

As the NTP synchronization is no more done as ntpdate has been purged, i've installed ntp to compare with the previous ntpdate (which has no apparent installed active 'dependant').
After rebooting, i've also made that change to get around the RTC problem:

 timedatectl
      Local time: mar. 2015-06-30 11:00:57 CEST
  Universal time: mar. 2015-06-30 09:00:57 UTC
        RTC time: mar. 2015-06-30 11:00:57
       Time zone: Europe/Paris (CEST, +0200)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone. This
         mode can not be fully supported. It will create various problems with time
         zone changes and daylight saving time adjustments. The RTC time is never updated,
         it relies on external facilities to maintain it. If at all possible, use
         RTC in UTC by calling 'timedatectl set-local-rtc 0'.
[11:00 - 0]
[u32 3] ~ > timedatectl set-local-rtc 0
[11:02 - 0]
[u32 4] ~ > timedatectl
      Local time: mar. 2015-06-30 11:03:00 CEST
  Universal time: mar. 2015-06-30 09:03:00 UTC
        RTC time: mar. 2015-06-30 09:03:00
       Time zone: Europe/Paris (CEST, +0200)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

***** i suppose that systemd-timesync should handle these issues *******

It's much more likely that this is due to the update of dnsmasq (https://launchpad.net/ubuntu/+source/dnsmasq/2.73-1):

juin 30 09:51:14 u32 NetworkManager[812]: <warn> dnsmasq not available on the bus, can't update servers.
juin 30 09:51:14 u32 NetworkManager[812]: <error> [1435650674.886674] [dns-manager/nm-dns-dnsmasq.c:398] update(): dnsmasq owner not found on bus: Could not get owner of name 'org.freedesktop.NetworkManager.dnsmasq': no such name
juin 30 09:51:14 u32 NetworkManager[812]: <warn> DNS: plugin dnsmasq update failed

Can you please test downgrading dnsmasq-base to the previous version https://launchpad.net/ubuntu/+source/dnsmasq/2.72-3.1build1 ? If that works, then it's a dnsmasq regression, or NetworkManager needs to get adjusted to the newer version.

If that doesn't work, can you please try to downgrade to the previous systemd version? This is much less likely to work as systemd doesn't do any network configuration beyond starting NetworkManager (which obviously works) and calling ifupdown (which you don't seem to use).

@Martin

that problem is resolved (workaround) by the change made into #2 comment above. Will try to downgrade dnsmasq-base but 2.73-1 is only available into Wily repo.
So should i need to revert the #2 change and force dnsmaq Utopic package (2.71-1) ? wonder about possible dependency conflict.

Maybe i will wait for network-manager beeing upgraded; and stay with the #2 change
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1467267

Comment about the ntp/ntpdate journal spamming

the journal.ntp.log shows (compared to journal.new.log) that lot of spamming entries are back: ureadahead & named[] mostly

Oh, so networking actually works again now? Then there's no need to downgrade dnsmasq-base indeed. You can still do it to investigate the ntp regresssion though -- from https://launchpad.net/ubuntu/+source/dnsmasq/2.72-3.1build1 you select your architecture, and from there you can download the older dnsmasq-base_*.deb and then sudo dpkg -i dnsmasq-base_*.deb

#8 answer

thanks Martin, yes the problem is solved by #2 comment (apparently); so there is no hurry on my side and i'm waiting the new network-manager (should not wait a long time, it has been set to 'triaged') ; i then will revert my change to test the standard settings.

As it has happened on a fresh vivid being dist-upgrading to wily, i suppose some other users will also meet that issue.

So what is the precise status now? What is "the new netowrk-manager", is there a different bug that tracks this issue?

the new nm needs to land into wily archive from Debiab main; see comment #6 above with the bug link. No better status.

OK, thanks. I'll close this one in favor of bug 1467267 then.