[–] simonjgreen 3 days ago
[–] mqwdojhv5 2 days ago
But the good news is that at least the majority (for now) is against it.
[–] eqvinox 2 days ago
Even outside ideology, plain business sense makes ISPs not want to deal with censorship & co. It's work to do that, hence costs money. But there are also ISPs resisting out of ideology and civic duty.
[–] andreareina 1 day ago
[–] Geezus_42 2 days ago
[–] Jnr 2 days ago
[–] Melatonic 2 days ago
[–] Geezus_42 2 days ago
[–] gruez 2 days ago
[–] dspillett 2 days ago
[–] robjan 2 days ago
https://shkspr.mobi/blog/2021/03/advanced-network-error-sear...
[–] dreamcompiler 2 days ago
https://dn.org/the-sitefinder-debacle-that-shook-the-interne...
[–] dspillett 2 days ago
I was thinking about interfering with existing sites.
[–] DaSHacka 2 days ago
[–] wolrah 2 days ago
[–] paranoidrobot 2 days ago
Some carriers also passed info in these headers to be used to make billing calls to the Telco, such as subscribing to premium services with minimal (if any) consent from the user.
I got stung by this years ago. An ad for mobile ringtones showed up on some news site I visited on my phone, I scrolled past without clicking. Next minute I get a text telling me I've subscribed signed up to a (iirc) $25/month ringtone plan and that it'd show up on my phone bill. It took an hour on the phone to my carrier to block the charges and get a refund. The ringtone company kept messaging me for a year that I needed to contact them and "fix" the issue.
[–] dTal 2 days ago
[–] toast0 2 days ago
Even with free ringtones, I'd send myself about three if I got a new phone. These days, I just keep a copy of the Nokia dubstep ringtone on hand in case I turn the ringer on, but it doesn't happen.
[–] Brian_K_White 2 days ago
"WHO THE F gave them the right to modify the data in my tcp session!!!!".
Spying on it I assumed but modifying one byte of it? A naively written edi that did not expect that would be completely destroyed.
Probably shouldn't have been so stupid for 15 years already by that point. There is no such thing as the right, there is only the ability.
If someone has the ability to do something, they will. Reputation, right & wrong, none of that actually exists or matters.
I didn't track down if the mechanism was based on dns. Could have been but I don't see why it would have had to be. But I was also not attempting to use any non default dns on that device at that time anyway. Obviously since they are trasporting unencrypted data they could modify it any time simply because it's in their hands.
dns would just be one handy low-hanging-fruit way to detour the data to a convenient dedicated purpose server to do the work. But not special or necessary at all. If they want to do the same thing without hijacking dns, they can with almost not even any difference in total effort.
[–] cowlevel 2 days ago
[–] breakwaterlabs 2 days ago
It's sort of an absurd question, the prevalence of such things by ISPs was the literal impetus for DoH and DoT.
[–] somehnguy 2 days ago
This is a good reminder to login and take a look, I wouldn't put it past them to change the setting name and reset the default.
edit: apparently Verizon has zero record of the username I've used for my FIOS account for years (and have saved in my password manager). Their account reset also fails with an error. What a dumpster fire of a company.
[–] Projectiboga 2 days ago
[–] flakes 2 days ago
[–] breakwaterlabs 2 days ago
[–] somehnguy 2 days ago
[–] bradknowles 2 days ago
Netflix has always listed AT&T as their number one worst offender when it comes to net neutrality.
So, I always run VPNs that I can trust.
[–] Geezus_42 2 days ago
[–] pbnjeh 2 days ago
[–] GlickWick 2 days ago
[–] mafuy 2 days ago
[–] j45 2 days ago
If you've ever been hit with a "webpage isn't updating" issue when someone else can see it, often it's different DNS servers.
It's best to never use the ISP's DNS servers, regardless of the reason why they might do what they do.
[–] simonjgreen 1 day ago
[–] xiconfjs 2 days ago
But providers overwriting DNS packets regardless – this is the topic of the article :)
P.S.: And yes, there are ways around this like DNSsec etc.
[–] j45 2 days ago
Introducing what ISPs do with DNS information is helpful to understand how encompassing DNS self-hosting needs to be thought about - DNS requests are important to consider the appropriate encryption for.
From the homelab side, increasingly with the automated attacks on systems, it seems wise to keep all services off the internet directly and put it behind one or more service to keep them safe. From that perspective, setting up something like Tailscale can also help mitigate this kind of issue.
[–] akerl_ 2 days ago
One of the reasons a variety of providers have been pushing for DoH is because DoH fully closes the risk of ISP MITM without needing individual site operators to do anything. This is why you're seeing folks like Firefox and Chrome enable DoH by default.
[–] cowlevel 2 days ago
[–] account42 1 day ago
... by replacing it with Google/Cloudflare MITM with whom the user doesn't even have a business relationship or even shared jurisdiction.
[–] cowlevel 2 days ago
[–] saidnooneever 3 days ago
its usually not nefarious, that is just the simpelest (and usually, not always) wrong explanation.
people who think this is not normal probarbly didnt experience what kind of shit u could find on the pre google pre monitored internet. for sure shit u do not want your kids to find. if u dont understand, then likely u dont have kids and very weird fetishes...
[–] witnessme 3 days ago
[–] eqvinox 2 days ago
There are of course outliers but most people I know in the field care as much about personal rights & freedom as anyone else. Maybe even a small bit more.
[–] gib444 2 days ago
[–] jwrallie 3 days ago
But their DNS responses have latency spikes every couple of minutes of 1-2 seconds that was driving me crazy. I simply enabled DNS over HTTPS in Firefox and everything feels so smooth now.
I have no idea how my coworkers seem to be so insensitive to it.
[–] pbhjpbhj 3 days ago
But I guess that if they let you do it they're probably not competent enough to catch you.
[–] jwrallie 2 days ago
They also do not pay for my device, so it’s only fair I can configure things my own way.
I’m pretty sure the worst that could happen is they would ask me to turn it off.
[–] pprotas 2 days ago
[–] c16 2 days ago
[–] Cidan 2 days ago
[–] BizarroLand 2 days ago
[–] c16 2 days ago
As an employee I'd be against it, but company device so what can you do. As the one managing the security and ISO process, it made my life a lot easier from both auditing and "why is my computer acting funny lately" perspectives. Showing my own user account having triggered an ad-based block, and the company-wide malware block rate was enough to satisfy the auditor that we has appropriate controls in place for a small company and move on to the next item.
Provided you take the stance of everyone is trusted to do their jobs, so we only need to block ads, piracy and malware lists and don't retain logging except where a block has occurred for auditing, I think it strikes a reasonable middle ground.
[–] pjc50 2 days ago
[–] mcmcmc 2 days ago
[–] m3047 2 days ago
A few years ago the cognitive dissonance of people saying "DoH is faster" to the same DNS server(s) started really bugging me: is it really DoH, or is it simply TCP vs UDP? So I wrote a little thing I can install on my laptop to do DNS forwarding over plain old TCP (originally no encryption): https://github.com/m3047/tcp_only_forwarder
Golly, on my wifi TCP was certainly more reliable than UDP. It's due to how wifi devices prioritize and buffer traffic. Maybe they should implement / enable DoH on their own servers.
On the other hand if all of your access from the workplace network to web resources is proxied (and since DoH is a web service), they may not care.
[–] Terr_ 3 days ago
I suppose the answer is politics rather than technology: Get enough people together to make a rule against it, and at least it will become niche.
[–] marcosdumay 2 days ago
Things are crazy now. Our TVs snapshot the stuff we watch; our telephones, watches, and TVs are constantly listening what we say; our PCs have undocumented "remote administration" devices that we can't opt-out; every internet service out there is stealing every data that it physically can and selling it to a long list of organizations, including some military ones...
[–] _kb 2 days ago
Back in this time children and families playing AR games are actually just data collection for GPS-denied military drones [1]. ~70% of the world's population voluntarily carry continuously connected GPS trackers, multi-camera, multi-microphone devices with fairly advanced sensor suites and send this into a plethora of 'social' platforms. This includes when they're jogging/tracing the outline of aircraft carriers [2] and military bases [3]. Vehicles are internet connected, laughably insecure and record every movement, and the movement of everything else in their vicinity [4]. And, for some reason, everything in your house is 'smart' and the building you work in is filled with 'advanced IoT' sensors and high precision wifi-tralateration that provides a firehouse of data to countless third parties.
We've been steadily descending for a long time and seem intent of speed-running dystopia.
[1] https://www.nianticspatial.com/defense-and-intelligence
[2] https://www.bbc.com/news/articles/cd9vdel17wqo
[3] https://www.theguardian.com/world/2018/jan/28/fitness-tracki...
[4] https://www.abc.net.au/news/science/2024-10-09/car-brands-ar...
[–] Spivak 2 days ago
[–] Yevini 2 days ago
[–] pjc50 2 days ago
[–] daitangio 3 days ago
I ended up using PIHole as DHCP, to drive home devices to PIHole, and control my privacy.
The trick is simple: disable DHCP on your router, and activate it on PIHole. As a bonus, PIHole on my RasperryPI2 is way faster than the little chip on my provider Router, and can be patched automatically with unattended upgrades.
[–] someguyornotidk 3 days ago
[–] hdgvhicv 2 days ago
[–] noselasd 3 days ago
[–] jachee 3 days ago
[–] cowlevel 2 days ago
[–] lxgr 23 hours ago
[–] a-french-anon 2 days ago
[–] unethical_ban 2 days ago
[–] daitangio 2 days ago
[–] nunez 2 days ago
[–] sli 12 hours ago
[–] hansvm 2 days ago
[–] jihadjihad 2 days ago
[–] eqvinox 3 days ago
:-(
Coincidentally, a bunch of free wifi stuff blocks the root key queries unbound does at startup, resulting in nothing working until you get those records in there somehow (e.g. load_cache).
[–] yjftsjthsd-h 3 days ago
> In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol.
is true, then I'm ... pretty unsold on its usefulness. Anyone wanna ELI5 whether that's untrue or anything's changed in the last decade?
[–] jeroenhd 3 days ago
There are also potential downsides (like someone being able to enumerate your subdomains, if you care about such a thing) and it's often switched off by default on operating systems consumers use.
However, it's the only thing that validates DNS records at this moment. That alone makes it worth enabling, in my opinion. For many domain owners, you only need to tick the checkbox in your registrar's domain control pane. If you use a modern DNS server, it's also one config flag and maybe copy/pasting a handful of fields away.
I'll gladly turn off DNSSEC the moment we come up with something better. DoT/DoH doesn't solve the same problem and no real solutions seem to have been proposed. That said, modernisation efforts are still being done. Smaller keys and modern cryptography rather than the massive RSA ones for instance.
[–] alwillis 2 days ago
Another approach that we analysed in more detail is the distribution of the host key fingerprints via a special resource record. This removes any user interaction, potential human error, or presumed configuration of a user’s device because OpenSSH-client can query the DNS and do the comparison. It only requires the administrator to publish a host’s fingerprints as a set of SSHFP records, which can be securely obtained (DNSSEC). If the latter holds, MITM attacks are mitigated, and overall security is improved. [1]
[1]: "Improving SSH’s security with SSHFP DNS records" - https://blog.apnic.net/2022/12/02/improving-sshs-security-wi...
[–] tptacek 1 day ago
[–] eqvinox 1 day ago
Alternate solutions I'm aware of would be SSH certificates and querying LDAP. One of the issues with SSH certificates (AFAIK) is that they become rather cumbersome when administrative domains aren't cleanly separated, which is quite common once you're outside rigid and obvious organizational structures that reflect into sysadmin. LDAP has the same scoping issues, except even worse.
> You don't need any third-party PKI to get optimal SSH security!
This is a very binary view on an issue that is all about grimey, squishy user behavior. Sure, if users copy around SSH fingerprints, they don't need this. And either way they don't need it very often. But have you met users? The Web PKI goes to great lengths to avoid people shooting themselves in the foot (on both server and client side), why not look at some options for SSH?
[–] jeroenhd 2 days ago
I personally prefer the theoretical advantages of SSH certificates, but those don't have CRL support (let alone an ACME alternative) as far as I know, so that's not exactly perfect either.
I want DNSSEC('s goals and ambitions) to succeed, but having a "trusted" ISP server that sets a "trust me bro" bit is the design flaw that kills the original design.
[–] eqvinox 2 days ago
[–] teddyh 2 days ago
General DNSSEC rationale: <https://www.icann.org/resources/pages/dnssec-what-is-it-why-...>
DNSSEC adoption graph: <https://www.verisign.com/resources/dnssec-tools/dnssec-score...>
[–] teddyh 1 day ago
[–] eqvinox 1 day ago
Honestly, I would've expected everything in that table to be an order of magnitude worse for DNSsec. Good to know!
(It's linked from the article you linked, transitively thanks for that link!)
[–] tptacek 1 day ago
[–] usr1106 3 days ago
Out of curiosity I enabled DNSSEC checking beginning this year. I mostly noted nothing in my browsing. However, with 2 services I noted obscure problems that worked only partially. Some Jira plugins and Swedish railway SJ. I needed to excempt some of their domains from being checked to use their services. Of course you waste a couple of hours every time it happens because you don't think of DNSEC first when some web-based services behaves weirdly. There might be more requests not served to my browser, but I just never noticed or bothered to debug.
So not fit for general use. And even as an experienced developer it's not easy to understand why an exception would be needed. A bug in systemd? Incorrect data in DNS? A real attack?
Edit: I don't use standard DNS on port 53 at all. Blocked outgoing requests on that port. Everything DoH or DoT. Of course I need to trust those endpoints at least in repect to confidentiality. And most domains are unsigned. At least for those unsigned ones I need to just trust also in respect to integrity.
[–] jeroenhd 3 days ago
Give SJ the option to turn off DNSSEC and their website will stay broken. Give people a "someone might be tampering with your connection" popup and they would start caring.
There are also other issues with DNSSEC that need working out, but I still believe it does much more good than it does bad. Leaving everything in the background with an easy-to-disable setting makes it next to useless.
[–] eqvinox 2 days ago
Full ACK. As a part of this, DNSsec validation needs to be as close to the client app as possible and reasonable; definitely never off-host. (Caches can do additional validation, but that makes the error reporting complicated.)
corollary: the AD bit should never be relied on on anything actually on the network. Maybe on localhost, but even there it's questionable in UX results.
[–] cowlevel 2 days ago
[–] alwillis 2 days ago
You can run a DNSSEC-aware resolver like unbound on your laptop if you wanted to. It comes with a bunch of Linux distros.
[–] cowlevel 2 days ago
[–] tptacek 1 day ago
[–] alwillis 2 days ago
As noted above, DNS forgery attacks against the ACME server can
result in the server making incorrect decisions about domain control
and thus mis-issuing certificates. Servers SHOULD perform DNS
queries over TCP, which provides better resistance to some forgery
attacks than DNS over UDP.
An ACME-based CA will often need to make DNS queries, e.g., to [1]
validate control of DNS names. Because the security of such
validations ultimately depends on the authenticity of DNS data, every
possible precaution should be taken to secure DNS queries done by the
CA. Therefore, it is RECOMMENDED that ACME-based CAs make all DNS
queries via DNSSEC-validating stub or recursive resolvers. This
provides additional protection to domains that choose to make use of
DNSSEC.
An ACME-based CA must only use a resolver if it trusts the resolver
and every component of the network route by which it is accessed.
Therefore, it is RECOMMENDED that ACME-based CAs operate their own
DNSSEC-validating resolvers within their trusted network and use
these resolvers both for CAA record lookups and all record lookups in
furtherance of a challenge scheme (A, AAAA, TXT, etc.).
[1]: https://www.rfc-editor.org/info/rfc8555/#section-11.2[–] tptacek 1 day ago
[–] teddyh 2 days ago
<https://www.icann.org/en/engagement-calendar/details/icann-t...>
[–] tptacek 1 day ago
[–] teddyh 1 day ago
[–] eqvinox 2 days ago
> domain-validated certificates remain insecure
...99% of the internet runs on DV certificates; that's what ACME & Let's Encrypt are at the end of the day.
(You might also note I didn't actually speak in favor of DNSsec, I'm just arguing that running unbound locally without having DNSsec validation enabled isn't particularly useful. I am, generally, in favor of rolling out DNSsec, but it certainly has its problems. It doesn't help against ISP tampering on unsecured domains, for example. DoT and DoH are better against that, if [and only if] you have a trustworthy cache to point them at.)
[–] denkmoon 3 days ago
[–] cowlevel 2 days ago
[–] Bender 2 days ago
[–] johnhtodd 2 days ago
Also, encrypt everything. DOT/DOH/DOH3/DOQ - leave no packet available for observation. Criminals, nosy network snoopers, and governments either want to know what you're doing or they want to break the integrity of the internet for profit or political reasons, and it is work to keep them out of your business.
context: I work at Quad9, one of the larger public resolvers.
[–] lxgr 1 day ago
The "mess with the responses" part makes no sense. The point of signatures/authentication is to prevent tampering, and DNSSEC does that successfully.
For that to work, of course you need to validate the signatures on your own infrastructure and not rely on your ISP's resolver to do that.
[–] usacoder 21 hours ago
[–] unethical_ban 2 days ago
Unlike OP, I have all my DNS route completely to my home DNS server, and only make changes to that container and my VM host during a "change window" meaning not during work hours. I block port 53 outbound entirely and have host entries for the two domains that my DNS server uses for DoH. If I had a better firewall on the edge, I would leave 53 open for my DNS container, but this workaround seems suitable enough for the home network.
[–] AceJohnny2 3 days ago
[–] drewfax 3 days ago
[–] dylan604 3 days ago
[–] AceJohnny2 3 days ago
There's a difference between what you're likely referring to, where the ISP's own DNS, which most people are using by default, returning particular results, and what the author is showing here where the ISP is actively tampering with outside DNS responses to insert incorrect responses.
Until now, I was not aware of any ISP doing the latter.
[–] jeroenhd 3 days ago
It's not universal, the occurance or this type of abuse seems to vary wildly from country to country
[–] justauserid 3 days ago
[–] aand16 3 days ago
[–] figmert 3 days ago
[–] noselasd 3 days ago
Some countries have laws around Net Neutrality or Open Internet that can protect you from this, but even those countries have other legislations that can superseed that in specific cases. (e.g. hijacking DNS can be completely legal for some child protection laws, or to uphold laws that makes some web sites illegal)
[–] throwawayffffas 3 days ago
[–] aand16 2 days ago
[–] cowlevel 2 days ago
[–] jon128 2 days ago
And if the remote end is available over the local region's mesh network so to not use any commercially operated AS, even better.
current mood: https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2F...
[–] 1vuio0pswjnm7 2 days ago
But _their_ ISP can casually snoop or tamper with their DNS traffic in transit
Because these third party caches (generally) still retrieve DNS data over unencrypted connections to authoritative nameservers
Cloudflare is one of the internet's largest authoritative DNS providers
This no doubt reduces the number of remote queries their cache has to send, but it doesn't account for domains that are not using Clouflare nameservers
It's worth considering why authortative DNS providers (generally) do not offer encrypted DNS
If this service exists then the www user does not need to use third party caches in order to have "encrypted DNS"
[–] 1vuio0pswjnm7 1 day ago
Iterative resolution can substitute for recursive resolution
[–] hedora 1 day ago
I could point to ISP DNS, or 1.1.1.1 / 8.8.8.8 / etc but those are all centralized, and are all subject to surveillance and censorship laws.
DNSSEC, etc, are something, but they rely on CAs. I mostly just want some sort of system that's outside centralized control, but that can be externally audited for trustworthiness.
[–] j45 2 days ago
Set an external DNS server on your router, or learn to run your own locally.
[–] maeln 2 days ago
[–] itopaloglu83 3 days ago
[–] jfyi 3 days ago
Oh and btw, it's not "DNS Hijacking" it's a "Domain Helper", see: https://feross.org/shame-on-you-comcast/
[–] mgoetzke 3 days ago
[–] arcfour 3 days ago
https://support.mozilla.org/en-US/kb/understand-encrypted-cl... not anymore, with many (not all) sites.
[–] gib444 3 days ago
[–] arcfour 2 days ago
Also that was last updated 6 months ago...
[–] gib444 2 days ago
[–] temp0826 2 days ago
[–] m3047 2 days ago
[–] pocksuppet 2 days ago
[–] BLKNSLVR 2 days ago
[–] cowlevel 2 days ago
[–] nukanse 2 days ago
[–] Sha1rholder 3 days ago
[–] amstan 3 days ago
They have a counter of all of my devices, somehow (i mean... i guess their count is wrong, but it's infuriating that they try to keep track).
[–] gruez 2 days ago
[–] BLKNSLVR 2 days ago
It should only be done as a Customer Service, however, and disclosed in a normal sized font and, as I said above, opt-out-able.
I would also extend this to say that ISPs should do the same for known-bad ASNs, and network ranges. Following on from yesterday's discussion about (p)residential proxies, blocking access to known C&C server domains and addresses at an ISP level would be a great solution.
I am, of course, looking at this through a utopian lens where ISPs aren't in bed with big tech and data brokers and other sketchy industries where profit can be made from selling out your customers' data. A 'real' ISP, you know, like 'no true scotsman'. It's all a question of trust and responsibility.
I pretty severely 'mess' with DNS on my home network and, damn, it makes using the Internet a much nicer experience. In fact, it makes using the Internet tolerable, where otherwise it is decidedly not. It could be classified as 'insecure' to not mess with DNS on any network[0].
[0]: https://www.pcmag.com/news/fbi-recommends-installing-an-ad-b...
[–] mariofdistrust 3 days ago
[–] pocksuppet 2 days ago
[–] mariofdistrust 9 hours ago
[–] ck2 2 days ago
Cloudflare Warp is handy, complete tunnel even if not as private as real VPN
since 80% of the web is on cloudflare it accidentally makes it faster anyway
and you don't have to use the cloudflare client, you can use Wireguard
[–] ZebusJesus 2 days ago
[–] peter_d_sherman 1 day ago
[...]
Now here's the catch. DNS resolution doesn't happen over a single connection. Your resolver might have to talk to multiple nameservers to figure out an IP address, and these queries are traditionally sent over plaintext DNS, usually UDP. Which means, you guessed it, your ISP can snoop on or even tamper with your DNS traffic."
This article raises several excellent points.
Basically, unencrypted DNS requests are not private.
Even encrypted DNS, once it gets to the DNS Server wherever that is, is no longer private to the owner of that DNS server, because it is unencrypted there... it may go nowhere from there, but then again, there could be logging and/or monitoring...
And DNS servers that you think don't belong to your upstream ISP -- can be proxied/rerouted by your upstream ISP...
If those points are understood by consumers, then an average person can clearly see why there is such a market (and that's the magic word, "market") for privacy solutions, i.e., encrypted VPN's, encrypted 3rd-party DNS, IP source address anonymization, etc., etc., here in the U.S. ...
In other words, a savvy privacy company or companies could sell to all U.S. Internet customers regardless of who their upstream ISP is, or what their upstream ISP promises in terms of privacy, if (and it's a big if!) they truly understand these issues and could explain them from the ground up, one-to-one, to all such potential customers...
Yes, there are a lot of VPN and other such companies, and prior customers already (not to mention free alternatives, such as Tor (but I still have questions about the exact quality of privacy Tor actually provides given browser fingerprinting and other related technologies), but that market is still segmented, has a relatively low bar for entry, and is still "up-for-grabs" for new small companies (i.e., no need to invest billions in a datacenter of GB300's to get your first AI model out...)...
Anyway, great article.
I never considered some of these issues (or their implications!) before reading it!
[–] tripdout 2 days ago
[–] eqvinox 2 days ago
It's very much part of the design that roots and caches are separated. The security properties necessary between root and cache (authenticity) are fulfilled by DNSsec, not DoT/DoH (primarily privacy). And most TLDs are DNSsec signed, so this part is in fact OK. (Both give some level of tamper protection, in a different manner though.)
You're probably saying this because you run a local cache directly against the roots. If you need DoT/DoH, you shouldn't be doing that and rather forward your queries to a cache somewhere else.
(To make sure there's no misunderstanding here: DoT and DoH do absolutely nothing to guarantee the data you're getting is what the roots/TLD/owner published. It only ensures you're talking to the cache you think you're talking to. The cache can serve to you whatever it wants.)
[–] johnhtodd 2 days ago
[–] eqvinox 2 days ago
The end result of this will be ISPs dropping all traffic to port 853.
[–] netsharc 3 days ago
Edit: oh wait, it finally loaded, 3x3MB images of text with scenery in the background!
[–] bradknowles 3 days ago
[–] ozim 3 days ago
[–] asdff 3 days ago
[–] khafra 3 days ago
[–] throwawayffffas 3 days ago
[–] dspillett 2 days ago
The problem with this is you are adding a moving part to your DNS lookups. It might be worth adding two on separate VPS hosts and have your resolver fall back to the second if the first goes down.
Another, usually more minor, problem is that some services (like CDNs) use the source of your DNS query to modify the response so you get sent to a topologically near-by end-point. This means you might notice such services being slower as you are sent to a PoP near your VPN host not one closer to your actual location.
[–] cowlevel 2 days ago
[–] ozim 2 days ago
[–] asdff 3 days ago
[–] konart 2 days ago
Can't speak for Hetzner, but considering VPN use in Russia and China - I'd imagine most EU\US vps providers have someone's 3x-ui, remnawave or naked v2ray installed.
Plus - how are they going to detect your remnawave node sitting on 443 port? For them it's just some traffict.
And if you are worried about the amount (torrents) - you don't really need to torrent though them. You just need an access to a torrect tracker to get your magnet link and meta info.
Most default configs for 'ray have torrents locks for this very reason - you communicate with other people (seeds\peers) directly.
[–] gruez 2 days ago
What about all the outgoing traffic? That's going to be hard to mask unless you have another VPN for outbound
[–] asdff 3 days ago
[–] throwawayffffas 3 days ago
All your ISP can tell is you are using a VPN.
[–] asdff 3 days ago
[–] pjc50 2 days ago
[–] Geezus_42 2 days ago
[–] thesuitonym 2 days ago
I don't trust any public VPN provider because they all start off by lying about what their product does.
[–] z3t4 3 days ago
[–] Tepix 3 days ago
1. contact the ISP and ask wtf they are doing
2. switch ISPs
Many ISPs in many countries are forced to do this for certain enforcement action that gets put upon them by their respective states for things such as age gating, censorship, monitoring, it varies state by state.
And to be clear this is in no way an endorsement of the practice, and I am confident no ISP WANTS to do this.
I am speaking here as the owner of a UK ISP (who does not currently do this).