'Are there any drawbacks to this?'
Yes!
1) DNS already has a mechanism for this. As soon as you know a change might be coming, reduce the TTL for the hostname(s), so that your yet-to-be-decided change is propagated quickly when the time comes. Totally unplanned changes (e.g. I decide on a whim that I need to change the IP addresses for my web site) are rare.
2) The new feature would make DNS dependent on HTTP.
3) The web server has no way of knowing whether your DNS record(s) have changed. So, you'd need to tell it manually, or it would need to be linked to your DNS server, which is probably on a different machine. And, in any case, your web server shouldn't be dependent on your DNS server.
4) The responsibility of HTTP is to transfer pages, not to determine how DNS queries are handled. Your browser could be delegating DNS queries to some lower level system. Let's assume that (1) your web server is using HTTPS, and (2) you're connected to the web via a proxy server. Your proxy server is responsible for DNS, but your browser is meant to interpret the contents returned over HTTPS. How would your browser 'ask its DNS to update the cached entry'? You'd need to add another hack to HTTP, so that the browser could send some special message to the proxy, asking it to update its DNS cache.
5) You're trying to solve a 'problem' in one system (DNS) which covers only one of many use cases (HTTP). DNS is used to resolve hostnames for non-HTTP, and for other things like DKIM/SPF.