This is generally the level of diligence (i.e. emailed verification link) that registrars are held to. DNS providers should be held to the same when the requesting account isn't the same account that created the 'earlier' zone file for a given domain at the very same provider.
Maybe we should add a requirement that the zone register sends some notification on behalf of the DNS provider. That could work, at least on the TLD level.
Point being that, short of transfer Auth-Codes[5], a verification link sent to the registrant's email address by the DNS provider is the functional equivalent of nearly the most that a registrar may be required to do in order to contact and/or verify a registrant.
[1] https://www.icann.org/resources/pages/ra-agreement-2009-05-2...
[2] https://www.icann.org/resources/pages/ra-agreement-2009-05-2...
[3] https://www.icann.org/resources/pages/benefits-2013-09-16-en
[4] https://www.icann.org/resources/pages/registration-data-accu...
[5] https://www.icann.org/resources/pages/auth-2013-05-03-en
So the only way the DNS service can get a notification to the domain owner is if it's forwarded by the registar.
The DNS provider absolutely can send a notification to the registrant without having to 'go through' (meanining interact with) the registrar. Even a third-party privacy service merely exists as a notification broker. Any notification sent by the DNS provider would simply pass through onto the registrant directly.
[1] https://www.icann.org/resources/pages/governance/bylaws-en/#...
In the case of a large-scale, multi-domain authoritative nameservers assignment change, only the DNS provider would be able to facilitate the process programmatically. And at that kind of scale (i.e. hundreds of domains), one would hope verification would not only be obtained through, but require some form of human-to-human contact coupled with thoroughly documented scope.