Comment 11 for bug 1734167

I suspect because in bionic/artful we're missing resolvconf package, that the systemd-resolved service ends up starting later in boot. The systemd-resolved-update-resolveconf.{service,path} require /sbin/resolvconf to run; this service had a path-based trigger that would get hooked whenever DHCP clients would call resolvconf to kick off a DNS update once config was available.
I suspect that systemd-networkd itself isn't poking DNS service properly after acquiring information.

The dependency loop comes from systemd-resolved using default dependencies which run after when cloud-init.service would run.

This then needs systemd-resolved to specify DefaultDependencies=No and something like network-online.target to require systemd-resolved.

I modified cloud-init.service to include an After=systemd-resolved.service but some other service may require dns, so I feel this is a property of network-online.target.