Board: [fsxNet] Retro Computing Subject: old inet = your own DNS? From: Malvinas(21:4/167) Date: Sun Sep 20, 2026 23:03 SUBJECT: I asked DeepSeek about my WiFi DNS problem and he turned it into a rant about the death of the old internet So I was having WiFi issues and started digging through Event Viewer. Found a bunch of DNS Client Event 1014 warnings for some domain called sf-helper.com. Figured I'd ask DeepSeek about it. What started as a routine troubleshooting session turned into a long conversation about DNS centralization, DDoS economics, and why the old internet is basically dead. Here's how it went. I kicked things off by saying I was having trouble with my WiFi. DeepSeek asked for details and suggested the usual—restart the router, move closer, check other devices. I told him I'd paste the Event Viewer error instead. He asked for the exact text, Event ID, source, log name, timestamp, and whether anything else appeared nearby. So I gave him this: Name resolution for the name userproxy-ext-raw.sf-helper.com timed out after none of the configured DNS servers responded. Event ID: 1014 Source: DNS Client Events Log Name: System Timestamp: 9/20/2026 8:59:50PM And mentioned there was a Kernel-EventTracing error close by. DeepSeek explained that Event 1014 is a DNS timeout warning, usually not fatal. The Kernel-EventTracing error was almost certainly unrelated—anti-cheat or monitoring software, harmless. He suggested changing DNS servers, flushing the DNS cache, and asked if I recognized the domain sf-helper.com. I told him I was already using 8.8.8.8 as primary and 4.4.2.2 as secondary. That's when he caught something: 4.4.2.2 is not Google's secondary—it's Level3. Then he noted that sf-helper.com is tied to SaveFrom.net Helper and similar video-downloader extensions, which are known for phoning home to sketchy domains. Told me to check my browser extensions. I confirmed I had several of those installed and deleted them. Said I'd monitor Event Viewer for a while. DeepSeek said that was a good move, suggested watching for new 1014 events, and mentioned flushing DNS and fixing the secondary DNS as follow-ups. I asked if I should flush DNS now, just to be safe. He said yes—harmless and a good idea right after removing extensions. He gave me the ipconfig /flushdns command, and while I was at it, he mentioned clearing the browser's own DNS cache by fully restarting it—close all windows, not just tabs. He specifically called out Chrome and Edge as having an internal cache that persists until the browser is completely closed. That's when I told him I use Firefox, not Chrome, and that I don't want anything Google-related. I said I'd keep Google DNS for now but would later fall back to my ISP's DNS. DeepSeek warned me about Firefox's DNS over HTTPS (DoH) feature—by default it can bypass Windows DNS entirely and route through Cloudflare. Told me how to check and disable or customize it. Also gave a table of privacy-focused DNS providers (Quad9, Mullvad, DNS0.eu, dns.sb) and noted that ISP DNS logs everything. I clarified that my privacy concern is Google specifically, not my ISP. He gave a cleaner list of non-Google, non-big-tech DNS providers with DoH URLs. Suggested changing Windows DNS, setting Firefox DoH to the same provider, flushing DNS, and monitoring. Then I asked how to check which DNS I'm using if I let Windows use the ISP's automatically configured DNS. DeepSeek gave three methods: ipconfig /all, Get-DnsClientServerAddress in PowerShell, and the Settings app. Noted that if the ISP forwards to Google behind the scenes, you can't see it from Windows —only Wireshark could reveal it. I pointed out that if I leave DNS on automatic, ipconfig /all just shows my router's LAN IP. He confirmed that's normal—the router acts as a forwarder. Explained that the real upstream DNS is hidden one hop away and only visible in the router's admin page. I logged into the router/modem web interface app and perused for the DNS setup. I gave him the DNS from the gateway interface: 181.30.140.134. He said that IP belongs to Telecom Argentina (ASN 7303), so the ISP is using its own DNS, not Google. Laid out the chain: PC → gateway → Telecom DNS. I wouldn't believe Telecom Argentina would have its own DNS server on-premise, but DeepSeek backed his case with a handful of sources. Said the IP is in a Telecom-registered block, not Google's. Cited Telecom's own nameservers (DNS1.CVTCI.COM.AR), user reports of Telecom DNS IPs, and a 2008 incident where Fibertel's DNS failed specifically for Google domains—which wouldn't make sense if they were just proxying to Google. Then I went off a bit. Ranted about how big companies ate up the old tech and now we depend on them for URL-to-IP translation, when the whole point of the internet was to not depend on companies. A big company translates your provided URL into an IP, so you can connect to whatever you're after. You can actually use the internet, because there's a big company translating URLs into IPs. DeepSeek agreed with the core of it, and came up with an ordered list of "How to concentration happened...": 1. Default settings. Most people never change their DNS. ISPs and router manufacturers set defaults, and those defaults point to a small set of upstream resolvers. 2. "Free" public DNS. Google (2009), Cloudflare (2018), Quad9, etc. offered fast, reliable, free resolvers. Convenient—but it moved resolution from distributed ISP-level servers to a few centralized ones. 3. HTTPS + CDNs. Once most traffic became HTTPS, the DNS query itself became one of the few remaining plaintext leaks. DoH/DoT solved that—but routed everyone through a handful of DoH providers. 4. Scale economics. Running a globally anycast, low-latency, DDoS-resistant resolver is expensive. Only big players can afford it well. I pointed out that point 4—the DDoS thing—means a truly free open-source DNS could just get bashed into the ground by the big sharks with a DDoS attack. A piece of cake for big players with a lot of cash and a huge rig at their disposal. DeepSeek agreed completely. Explained that DNS is UDP by default, spoofable, and used for amplification attacks. A single 100+ Gbps DDoS will saturate most connections. Anycast is the only real defense, and it requires BGP peering, multiple data centers, and serious money. Concluded that "public DNS for everyone, run by a hobbyist" is basically dead —not because the software is bad, but because the threat environment killed it. The big players didn't just out-compete the small ones; they occupy the only position from which DDoS defense is affordable. He suggested the only honest paths left would be to run a resolver for yourself only (localhost or LAN) or run it for a small trusted group over a VPN. The internet's architecture is decentralized but its operation has consolidated, and how DDoS economics quietly enforce that consolidation. You can still run your own resolver, but you can't run a public one without becoming a target. The old internet worked because it was small and mostly trusted. Scaling trust turned out to be the hard part. Anyway, if anyone here runs Unbound or Pi-hole locally, I'd be curious to hear your setup. There might be a handful of pointers that could be useful for anyone thinking of going that route. Pol Malvinas. Islas Malvinas, siempre Argentinas! .... Islas Malvinas, siempre Argentinas. --- Mystic BBS v1.12 A47 2021/12/25 (Windows/64) * Origin: The Vault BBS (21:4/167) .