At that point you might as well use DoH. But you're also reasoning axiomatically about something we have a lot of documentary evidence for: the DNS operator community (or a big chunk of it) favors DoT and opposes DoH because they want to make it easier to block encrypted DNS; they frame this in terms of "control over their own networks".
What benefit is the additional complexity and overhead of HTTP buying you there?
> the DNS operator community (or a big chunk of it) favors DoT and opposes DoH because they want to make it easier to block encrypted DNS; they frame this in terms of "control over their own networks".
This is one of the main issues here: When then DNS operator is you, i.e. your local network at home or your corporate network within your own company, you should be able to control DNS on your own network, which you can't if a bunch of adversarial devices are bypassing your DNS servers.
When the DNS operator is your ISP, letting them block encrypted DNS is bad.
So what we need is some way to distinguish between these situations so that the local network administrator's preferences are heeded but Comcast can go pound sand. But browsers are too late in the stack for that because they have no way to tell if the system DNS server is the one the user wants or the one they got by default from their ISP and never knew to change.
I don't think we need any way to distinguish these situations any more than we needed to preserve the non-ephemeral key exchanges in the jump from TLS 1.2 to TLS 1.3, which were opposed for the same reason. You can control which computers you allow on your network, and allow only computers which give you endpoint monitoring. The 2025 TCP/IP protocol stack should not be going out of its way to give network operators more visibility into what applications are doing.
At that point you might as well use DoH. But you're also reasoning axiomatically about something we have a lot of documentary evidence for: the DNS operator community (or a big chunk of it) favors DoT and opposes DoH because they want to make it easier to block encrypted DNS; they frame this in terms of "control over their own networks".
> At that point you might as well use DoH.
What benefit is the additional complexity and overhead of HTTP buying you there?
> the DNS operator community (or a big chunk of it) favors DoT and opposes DoH because they want to make it easier to block encrypted DNS; they frame this in terms of "control over their own networks".
This is one of the main issues here: When then DNS operator is you, i.e. your local network at home or your corporate network within your own company, you should be able to control DNS on your own network, which you can't if a bunch of adversarial devices are bypassing your DNS servers.
When the DNS operator is your ISP, letting them block encrypted DNS is bad.
So what we need is some way to distinguish between these situations so that the local network administrator's preferences are heeded but Comcast can go pound sand. But browsers are too late in the stack for that because they have no way to tell if the system DNS server is the one the user wants or the one they got by default from their ISP and never knew to change.
I don't think we need any way to distinguish these situations any more than we needed to preserve the non-ephemeral key exchanges in the jump from TLS 1.2 to TLS 1.3, which were opposed for the same reason. You can control which computers you allow on your network, and allow only computers which give you endpoint monitoring. The 2025 TCP/IP protocol stack should not be going out of its way to give network operators more visibility into what applications are doing.
4 replies →