Hacker News new | ask | show | jobs
by zaarn 2842 days ago
I'll give you corporate networks though that's more guesswork than actual hard data on that. Plus point still stands that other protocols will be blocked unless using 443 or 80 ports.

Mobile networks in my experience block a variety of protocols and intercept DNS fairly regularly, even in presence of DNSSEC or DNSCrypt. Not sure what calling the regulator would give me, they're not responsible for what ports the network blocks. Not every operator is in the US, a majority of people do not live in the US and may want to use the internet without the operator playing around in DNS responses.

1 comments

>I'll give you corporate networks though that's more guesswork than actual hard data on that. Plus point still stands that other protocols will be blocked unless using 443 or 80 ports.

Yes. But this is a corporate network. It's not up to you to decide which protocols should be allowed or not. (Unless you are in the position to do so of course) I know it's quite easy to tunnel everything through something, but why do that in a corporate environment. If you need to access X then get access to it (via proper channels?)

>Mobile networks in my experience block a variety of protocols and intercept DNS fairly regularly, even in presence of DNSSEC or DNSCrypt.

But do they block port 853 and if so, on what grounds? They sell you an Internet access, if a port is blocked, this is no longer a valid Internet access. If the port is not blocked however, then the ISP can no longer play around in DNS responses.

>But do they block port 853 and if so, on what grounds?

I don't know why they decide to block it but they do. Most of the time it's to prevent spam or to protect customers (ports lower than 1024 are sometimes blocked for that reason).

>They sell you an Internet access, if a port is blocked, this is no longer a valid Internet access.

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.

Fact is, ports get blocked. The mentioned networks do it a lot. We should accomodate these restrictions because alternatively the software breaks for a consumer and if it's a choice between "uninstall DNSCrypt/DoT/DoH" or "complain to ISP or operator" then most consumers will not complain to the ISP because prior to DNSCrypt their internet worked for all they care.

>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.

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.