After updating some of my nameserver VMs to current tumbleweed today (which included systemd updates), named no longer started on boot.

named is a legacy (sysv init) service. The usual /etc/init.d/rc3.d links were still in place. Neither "systemctl enable named" nor an "insserv -r / insserv" pair changed anything.

This was and is working on not-yet updated servers (already on tumbleweed)

Versions on the working (older) system:
 systemd-sysvinit-232-8.1.x86_64
 systemd-232-8.1.x86_64
 bind-9.10.4P5-24.1.x86_64

Now-problematic versions after update:
 systemd-sysvinit-232-9.1.x86_64
 systemd-232-9.1.x86_64
 bind-9.10.4P5-25.1.x86_64

Looking under /run/systemd I see that the previously generated symlinks in /run/systemd/generator.late/multi-user.target no longer exist.

working-system:~ # find /run/systemd/ -ls | fgrep named.service
 30222074      0 lrwxrwxrwx   1  root     root           41 Apr 12 11:45 /run/systemd/generator.late/graphical.target.wants/named.service -> /run/systemd/generator.late/named.service
 30222072      0 lrwxrwxrwx   1  root     root           41 Apr 12 11:45 /run/systemd/generator.late/multi-user.target.wants/named.service -> /run/systemd/generator.late/named.service
 30222070      4 -rw-r--r--   1  root     root          607 Apr 12 11:45 /run/systemd/generator.late/named.service

nonworking-updated-system# find /run/systemd/ -ls | fgrep named.service
     1108      4 -rw-r--r--   1  root            root                 558 Apr 28 11:49 /run/systemd/generator.late/named.service

I could work around the issue with a oneshot additional real systemd service drawing in named.service using a Requires/After dependency. But this is a regression that will hurt others, too.