Re: Now this would be a great idea...
There is a bigger problem to consider: SNI (Server Name Indication), which allows a single webserver / IP address to support multiple certificates.
Over time, SNI has become more and more prevalent, and it means that someone sniffing a TLS connection can see what hostname you're trying to connect to. TLS itself is now so leaky that DNS is no longer the issue.
To prove this to yourself:
1. In one terminal, type:
tcpdump -c10 -i eth0 -nn -s0 -A '(host 104.20.250.41 or host 104.20.251.41)'
(WIndows users: do the Wireshark equivalent)
2. In another terminal, type
curl https://www.theregister.co.uk/
(or just use a web browser which hasn't recently connected to El Reg). At around the fourth packet in the exchange you'll see:
13:18:11.210438 IP x.x.x.x.55010 > 104.20.250.41.443: Flags [P.], seq 1:206, ack 1, win 8192, length 205
E.....@.@.-.
...h..)......_.....P. .i>.............Z2z.H(...<...._.....K...'.>.~..b..D...,.+.$.#.
. ...0./.(.'...........k.g.9.3.......=.<.5./.
.............W.........www.theregister.co.uk.
.......................................................
There it is - in clear text - the name of the secure site you're connecting to.
SNI is a result of IP address depletion, but actually the problem would still be there without it.
Even if every TLS website had a unique IP address (and SNI were disabled), you could still easily build a database of hostname to IP address mappings, just by taking logs from any heavily-used DNS cache.
Generating random IPv6 target addresses for each distinct client might help.