Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DNS over TLS – Thoughts and Implementation

sagi.io

Post reply on HN
Print view View original

81–88 of 88 posts

Re: DNS over TLS – Thoughts and Implementation

#81

Post by gsich »

zaarn wrote: post #80
gsich wrote: post #77

Earlier quoted context omitted.

>That's a laughable argument, they don't sell you unrestricted internet access, that's already given by the fact we have datacaps and SMTP traffic from port 25 blocked. Some do and I would complain about it. Maybe port 25 has a spam related reason, but every other port has not. But to come back: crappy networks are not a reason to ditch "custom" ports. Fix the network.

>But to come back: crappy networks are not a reason to ditch "custom" ports. Fix the network. I heavily disagree. Broken and crappy networks exist and for the user it's easier if the software we write works on broken and crappy networks. Most users will not complain to the network if YOUR software doesn't work on it but other software works fine. That's simply the reality of the situation.

You can disagree all you want. Nothing will change if you build for crappy networks. Build your application so that it can detect such a setup and tell the user.

It works for gaming. This alone is proof that it can work.

Re: DNS over TLS – Thoughts and Implementation

#82

Post by zaarn »

gsich wrote: post #81
zaarn wrote: post #80

Earlier quoted context omitted.

>But to come back: crappy networks are not a reason to ditch "custom" ports. Fix the network. I heavily disagree. Broken and crappy networks exist and for the user it's easier if the software we write works on broken and crappy networks. Most users will not complain to the network if YOUR software doesn't work on it but other software works fine. That's simply the reality of the situation.

You can disagree all you want. Nothing will change if you build for crappy networks. Build your application so that it can detect such a setup and tell the user. It works for gaming. This alone is proof that it can work.

It works for gaming because most games that need non-crappy networks happen to run on connections that are more rarely crappy networks.

And despite that I get regular issues when I need to play true p2p lobby games because of various people having a variety of difficult-to-work-around routers or ISPs. So in part atleast it doesn't work for gaming either. I don't consider your proof valid.

Re: DNS over TLS – Thoughts and Implementation

#83

Post by gsich »

zaarn wrote: post #82
gsich wrote: post #81

Earlier quoted context omitted.

You can disagree all you want. Nothing will change if you build for crappy networks. Build your application so that it can detect such a setup and tell the user. It works for gaming. This alone is proof that it can work.

It works for gaming because most games that need non-crappy networks happen to run on connections that are more rarely crappy networks. And despite that I get regular issues when I need to play true p2p lobby games because of various people having a variety of difficult-to-work-around routers or ISPs. So in part atleast it doesn't work for gaming either. I don't consider your proof valid.

If you consider port 80/443 as essential, then you can add 853 to that list. Every network who blocks it, blocks an essential port, similar to blocking 443. This is the angle one needs to work with here. Why keep the status quo for all eternity?

People have difficulties port forwarding. It's fixable, but then again, this is a different issue. You are talking about incoming ports, not outgoing.

Re: DNS over TLS – Thoughts and Implementation

#84

Post by zaarn »

gsich wrote: post #83
zaarn wrote: post #82

Earlier quoted context omitted.

It works for gaming because most games that need non-crappy networks happen to run on connections that are more rarely crappy networks. And despite that I get regular issues when I need to play true p2p lobby games because of various people having a variety of difficult-to-work-around routers or ISPs. So in part atleast it doesn't work for gaming either. I don't consider your proof valid.

If you consider port 80/443 as essential, then you can add 853 to that list. Every network who blocks it, blocks an essential port, similar to blocking 443. This is the angle one needs to work with here. Why keep the status quo for all eternity? People have difficulties port forwarding. It's fixable, but then again, this is a different issue. You are talking about incoming ports, not outgoing.

Adding ports to a list of "essential" ports is hard considering some middleboxes haven't been updated since IPv6 standard was published (1998) and those aren't even the oldest once I've seen. They will drop and mangle packets as they please and unless it costs them millions of dollars a month these boxes will not be replaced or reconfigured, period. That is reality on the internet.

Re: DNS over TLS – Thoughts and Implementation

#85

Post by gsich »

zaarn wrote: post #84
gsich wrote: post #83

Earlier quoted context omitted.

If you consider port 80/443 as essential, then you can add 853 to that list. Every network who blocks it, blocks an essential port, similar to blocking 443. This is the angle one needs to work with here. Why keep the status quo for all eternity? People have difficulties port forwarding. It's fixable, but then again, this is a different issue. You are talking about incoming ports, not outgoing.

Adding ports to a list of "essential" ports is hard considering some middleboxes haven't been updated since IPv6 standard was published (1998) and those aren't even the oldest once I've seen. They will drop and mangle packets as they please and unless it costs them millions of dollars a month these boxes will not be replaced or reconfigured, period. That is reality on the internet.

But not on customer networks. So what's the problem? Crappy wireless networks are not worth it. Mobile works, corporate can configure it.

I think this has gone full circle now...

Re: DNS over TLS – Thoughts and Implementation

#86

Post by zaarn »

gsich wrote: post #85
zaarn wrote: post #84

Earlier quoted context omitted.

Adding ports to a list of "essential" ports is hard considering some middleboxes haven't been updated since IPv6 standard was published (1998) and those aren't even the oldest once I've seen. They will drop and mangle packets as they please and unless it costs them millions of dollars a month these boxes will not be replaced or reconfigured, period. That is reality on the internet.

But not on customer networks. So what's the problem? Crappy wireless networks are not worth it. Mobile works, corporate can configure it. I think this has gone full circle now...

Corporate will not configure anything unless it costs them millions. Same for Mobile (which breaks frequently but thank you very much) and same for wireless networks.

Nobody will update their machines that haven't been updated since the 90s because your protocol needs a new port to be freely accessible. Nobody will thusly adopt it and in turns nobody will update their machines.

The TCP/UDP/ICMP trio has been ossified as the ground protocols of the internet, ports 53/80/443 for traffic and TLSv1.2 for SSL traffic. Almost everything outside these parameters breaks in a variety of networks from "bad performance" to "simply doesn't work", depending on whether you sit on a VPS or a normal landline like business or consumer DSL.

We have to deal with that if we want updated protocols to even remotely have a chance of adoption. As I have repeatedly said, this is the reality of the modern internet, face it or have you protocol forgotten and unused.

Re: DNS over TLS – Thoughts and Implementation

#87

Post by gsich »

zaarn wrote: post #86
gsich wrote: post #85

Earlier quoted context omitted.

But not on customer networks. So what's the problem? Crappy wireless networks are not worth it. Mobile works, corporate can configure it. I think this has gone full circle now...

Corporate will not configure anything unless it costs them millions. Same for Mobile (which breaks frequently but thank you very much) and same for wireless networks. Nobody will update their machines that haven't been updated since the 90s because your protocol needs a new port to be freely accessible. Nobody will thusly adopt it and in turns nobody will update their machines. The TCP/UDP/ICMP trio has been ossified…

>Corporate will not configure anything unless it costs them millions.

Of course they will if it has a purpose. Not everything is driven by money as you suggest. Besides: corporates have internal resolvers anyway.

>Same for Mobile (which breaks frequently but thank you very much)

No. If it does, complain to your ISP. There is no reason why an outgoing port should be blocked.

>and same for wireless networks.

They will update too.

>Nobody will update their machines that haven't been updated since the 90s because your protocol needs a new port to be freely accessible. Nobody will thusly adopt it and in turns nobody will update their machines.

Dangerous assumption. Opening a port does not need an update. It's TCP, the same protocol as http on port 80 or 443.

This is a minority problem. Networks do work.

Re: DNS over TLS – Thoughts and Implementation

#88

Post by fanf2 »

amaccuish wrote: post #78
fanf2 wrote: post #47

I deployed DNS-over-TLS on Cambridge University’s central recursive DNS servers last week, and they immediately started receiving traffic from Android P users - not very much traffic, a few queries per second, but not negligible. I did some followup investigation of how Android behaves in the wild and posted them to the IETF DoH list (and the dprive list but for some reason those copies did not go through) - see http…

Is there a new dhcp option to indicate availability, or is it opportunistic, when the device notices port 853 is open?

Android 9 Pie is opportunistic: it tries to connect to port 853 and sends a probe query to make sure the server behaves plausibly well. Other clients need explicit configuration.
Post reply on HN