Part of the problem is answered by @Ben. I would caution on using external-dns open source as you may not like to create dependency on this very important function. It requires you to grant additional permission!
You will need a virtual private ip and it's achieved by internal load balancer annotation and it works. I recently documented end of end tls/ssl with internal load balancer and can find it at https://blogs.aspnet4you.com/2019/01/06/end-to-end-tlsssl-offloading-with-application-gateway-and-kubernetes-ingress/.
Keep in mind, my solution worked great until I removed http application routing add-on. Why? The add-on came with Azure Dns (public) and public load balancer. Both of them are removed for good when I removed the add-on but the removal broke the dns entry associated with vip of internal load balancer. I didn't intend to remove dns zone. My attempt to create new DNS Zone and add A record with private IP didn't work. Kubernetes can't resolve the fqdn. Tried with Azure Private DNS but it's not able to resolve either! My attempt to use configmap with kube-dns didn't work and it breaks dns resolution of other things if I included upstream! So, investigation continues!
I would love to hear how you solved the fqdn problem.
On the optimistic note, I think VM based custom dns server can be good option and you would likely have one for hybrid solution.