@jaymemaurice: We're talking about slightly different SNI (well, it's the same SNI, but how it's used now vs. what the linked draft suggests). And that draft is strange, it looks like recipe for really overcomplicated hide & seek game to me.
According to it, if I want to connect to https://badforbiddenstuff.tld, browser will get the new DNS SNI record, which will tell it to send worldofkittens.tld as server name instead of badforbiddenstuff.tld. Server will still send back certificate valid for badforbiddenstuff.tld and client will verify that. It will do any good only with TLS 1.3 which can send certificates encrypted (I didn't know that, that's interesting news) and so attacker won't be able to get anything from it. Good so far, and I do believe that it could help against passive attacker. But I'm more worried about attackers who are less passive, who want to block stuff. And they will of course know that badforbiddenstuff.tld exists and that it has DNS SNI record with worldofkittens.tld. So unless worldofkittens.tld is real existing site sharing the same IP address with badforbiddenstuff.tld, it can be easily blocked. And worst case, when they really can't tell one from another, worldofkittens.tld will simply go as collateral damage. And I also have hard time to believe that browsers will actually implement this, because it means sending extra DNS query for every single hostname. So it's likely to end up like SRV records for HTTP(S), i.e. not supported because the extra queries could slow things down, it would be bad for user experience and it's just not worth it, because it would be used only by tiny fraction of sites anyway.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.