That’s not entirely true. It’s only very recently that browsers have started using a new system called Encrypted Client Hello which hides the domain of the request. Prior to this all requests needed too have the Host field unencrypted so the receiving server knows which certified to respond with. I imagine there’s still quite a few servers which don’t support the new setup still.
I don’t know about that. Technically it wouldn’t be necessary but I can see providers limiting you to a single IP instead of a /64 and needing to do it anyway, because the tech exists anyway. Or for privacy reasons. There is IPv6 NAT, after all…
I don’t see carrier grade NAT ever being used for IPv6. The extra equipment for that makes the network more expensive, less reliable, and introduces extra latency.
One thing ISPs are doing is still handing out dynamically assigned prefixes rather than static. Self hosting is still going to be a pain.
Correct me if i am wrong but DNSSEC has nothing to do with encryption of your request. It is used to verify that the record you received is from the correct authority. Furthermore your DNS requests have to go through your ISP even if you don’t use their DNS server as it is your only connection to the Internet.
The only thing you could do is encrypt the traffic somehow (dns over https exists), but then you have to trust that provider instead, and your ISP can still see the IP addresses you try to reach after you know them and might be able to still do a domain lookup using DNS if it is also configured to return the domain when looking up the IP. If they would put in the effort of course.
ISP can’t see pages. They can see domains or IPS but that’s it.
They can’t even reliably see domains when you use HTTPS, because some IP addresses serve many domains.
That’s not entirely true. It’s only very recently that browsers have started using a new system called Encrypted Client Hello which hides the domain of the request. Prior to this all requests needed too have the Host field unencrypted so the receiving server knows which certified to respond with. I imagine there’s still quite a few servers which don’t support the new setup still.
And we wouldn’t need any of that if we implemented IPv6.
I don’t know about that. Technically it wouldn’t be necessary but I can see providers limiting you to a single IP instead of a /64 and needing to do it anyway, because the tech exists anyway. Or for privacy reasons. There is IPv6 NAT, after all…
Most ISPs offer IPv6 right now, and they tend to hand out at least a /64. Often as much as a /54.
RIPE strongly discourages ISPs from handing out prefixes longer than /56: https://www.ripe.net/publications/docs/ripe-690/
I don’t see carrier grade NAT ever being used for IPv6. The extra equipment for that makes the network more expensive, less reliable, and introduces extra latency.
One thing ISPs are doing is still handing out dynamically assigned prefixes rather than static. Self hosting is still going to be a pain.
In an ideal world, sure.
Most ISPs are also the default DNS resolver for a lot of people, so they see the domain you’re requesting an IP for.
They can still (mostly) sniff SNI for now which gives them a domain even when the IP isn’t unique.
deleted by creator
That’s a good point. Almost everyone uses their ISP’s DNS.
Correct me if i am wrong but DNSSEC has nothing to do with encryption of your request. It is used to verify that the record you received is from the correct authority. Furthermore your DNS requests have to go through your ISP even if you don’t use their DNS server as it is your only connection to the Internet.
The only thing you could do is encrypt the traffic somehow (dns over https exists), but then you have to trust that provider instead, and your ISP can still see the IP addresses you try to reach after you know them and might be able to still do a domain lookup using DNS if it is also configured to return the domain when looking up the IP. If they would put in the effort of course.