Yeah, well. That's got nothing to do with .dev. All the new TLDs are fucking dumb. Just a cash grab for the ICANN. Might as well get rid of TLDs altogether.
Honestly I don’t think it’s a cash grab for icann. There are plenty of registries that are making plenty of money, as well as domain owners selling the domains in the aftermarket.
The reason the new tlds were needed is the lack of options for buying a new domain. I know plenty of smaller biz and startups who couldn’t get the dot com they wanted and ended up choosing a really good keyword rich new tld.
Is steampowered.com sketchy? Even incredibly large companies often can't get the domains they want because they were bought twenty years ago by some Joe Schmo.
Downloaded it. Whooping 150 MB that took over two minutes to download. Then data took like 10 minutes to show up, with no clear sign that the app was bootstrapping and not merely non-functional.
The app keeps using 100% of my IO for 20 minutes now, writing to files like "KVStore.kv" and "searchindex/store". If I had an SSD I would close it, afraid of it frying the disk.
How is no channel history a feature? I think if you take a look at your reasoning you'll see that you are just defending IRC because you like it. Which is fine, but it is intellectually dishonest to pretend that flaws are not flaws.
It doesn't bother me because it's a Chromecast, an appliance I don't want or need. If I needed something similar, I could get it from other manufacturers.
FWIW, Chrome does this as well. Its DNS prefetch feature will ignore your local hosts file and configured DNS servers. It creates annoying problems if you have a VPN where some hosts resolve differently than they do publicly.
Granted, in this case if you block Google's DNS servers from routing, Chrome will use your system's name resolution configuration.
TIL! This upsets me more than the Chromecast using Google's DNS.
I barely use Chrome anymore (just for testing really) but the thought that any domain I wish to go to can be overridden by the browser by default - that's scary.
I mean what if Google doesn't like your website's content. They can block it on their DNS server and 99.999% of Chrome users would think something was wrong with your site.
I was thinking about buying a better network device for home and have VLANs and ACLs just to take control of my internet again. It is pretty annoying that Google not only trying to track me everywhere but actively overriding system wide settings to be able to get information what sites I am visiting.
I was looking into that yesterday. How can I disable forwarding in Dnsmasq for certain domain names? Maybe I should run a local resolver server myself instead of forwarding the DNS requests to 3rd parties and do it that way with ACLs? Let me know if you have detailed documentation about how to use OpenWRT for these.
I mean in theory your web browser doesn't have to respect the address bar, it can do whatever the fuck it wants. The point is what Chrome is already doing is not good behaviour.
Holy synchronicity! I just ran into this this morning when trying to null route a hostname on my co-workers computer and nobody could figure out why chrome could still resolve the IP after we changed the hosts file.
It was disheartening how much time I spent tracking this down. I generally use Firefox, but since the web is bifurcated, I need to be able to access some sites with Chrome.
This is extremely annoying. The VPN will switch DNS servers and macOS and Safari work fine, but Chrome will not find internal servers. I assumed it was just a cache, but this makes sense.
They also removed support for mandatory features of HTTPS [0], as defined in RFC 2818. Not that I'm against the change /per se/, but there correct way to go about it is to change the standard.
They also claimed Firefox was doing the same thing, which is false and not really sufficient justification for not supporting things that MUST be supported.
I think the idea is that getting Google to fix this by telling them this is unacceptable is a swifter course of action than hoping Google will notice your individual $35 purchase went elsewhere.
I just pointed the Pihole at 1.1.1.1 and added 8.8.8.8 to the block list. The Chromecast works fine with it. Not sure if the Pihole does something clever though? I’m very sure that the Chromecast does but I can see it’s traffic on the Pihole.
Not really, before you could firewall it off from the rest of your network - though now you can just masquerade 8.8.8.8 and 8.8.4.4 to your DNS server of choice
pass in quick on { $lan $wireguard } proto udp to { 8.8.8.8 8.8.4.4 } port 53 rdr-to 192.168.2.1
Locally I run Unbound for caching, local dns zones and ad/malware domain blocking[2]. I have a DNS forwarder in Unbound configured to a local Stubby[1] instance that does dns over tls to Cloudflare.
Having done "big data" contract work for the largest telco in my current country of residence who are some of the worst skilled people I have ever work with, your local ISP is highly likely abusing your DNS history profiling your household for various questionable things just as much as Google. At least with Cloudflare they have a clear privacy policy[3] and I have faith their technical skill to anonymize data and use it can't be as bad as my ISP.
Maybe. But it's trivial, for your ADSL/DSL/Fiber shitty $30 router to intercept port 53/(udp|tcp) bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP. When I say trivial I mean I've seen it happen on several setups, old me - we'll just change the DNS on this box to bust the cache here to 1.1.1.1(CF)/8.8.8.8(EvilG) but still end up a shitty ISP dns servers (and their poisoned cache regardless). There's a reason for the push for DNS over HTTPS.
You think you're guaranteed to be querying 8.8.8.8 with "nslookup hostname.tld 8.8.8.8"?
> bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP... There's a reason for the push for DNS over HTTPS.
This is looking at things and totally backwards. You have a local problem, a broken router and you suggest we fix this by changing how all edge nodes on the internet works.
In the age of ever increasing, untrustworthy IOT-devices, you don’t solve this problem by taking control away from the network operator. You need to increase his control. Taking DNS out of his hands is literally madness.
Good luck trying to block their attempts to spy and report on you now!
DNS over HTTPS is going to cause a shitload more problems than it solves.
In a world of mobile devices and public WiFi spots set up by random businesses, you're saying we should trust the network operator? That's a rather odd argument.
>DNS over HTTPS is going to cause a shitload more problems than it solves.
Oh, absolutely. What I wonder is if people don't notice this, or they do but believe Google is right in pushing fundamental internet design decisions that prioritize Google's incidental access to surveillance data over a high quality and resilient network for everyone.
I believe that they have created a double-edged razor blade. DoH can protect people that have malicious ISP's. It also hands over a lot more control to Google. I don't like either of those scenarios.
By control, what I mean is that once DoH usage to G servers hits critical mass, they can decide who can visit what. Not that they would, but they can. People generally do what people can do.
Because it's encrypted to the app rather than the endpoint's OS or local DNS, so it's more difficult for the system owner to override it or implement a systemic policy.
The performance characteristics are also rather unfortunate. TCP handshake + TLS handshake with multiple public key operations + TCP protocol overhead adds quite a lot of both latency and computation vs. UDP DNS. DoH is even worse. There would have been ways (e.g. DNSCurve) to get equivalent or better security with less latency and computation if it weren't for horrible middleboxes breaking everything they don't understand.
If we create internet infrastructure (like DNS over HTTPS) which prevents network operators from actually operating their networks, I’m 100% confident we will find it has bad, unintended and irreversible consequences.
If by "network operators" you mean ISP's then I don't care. They have proven beyond a shadow of a doubt that they are malicious ones more often than not and I want them to be a dumb pipe NOT someone who is mucking around with my network. I will take being able to PICK who I trust my DNS with over being forced to use my ISP's any day of the week. One of those things I can change, one of them I cannot.
Agreed. Many orgs will end up null routing the DoH resolver IP addresses. I warned them about this from the start of DoH development and they ignored me, since most end users won't block anything.
Yes I know. I've had it happen to me with a Huawei HG556a. You could disable it with admin access... which the ISP would not give you. Fun times.
A good way of bypassing this would be to simply have Google run their DNS server in a port other than 53. But I don't believe you can set a different port in /etc/resolv.conf
Possibly feasible with local netfilter/iptables rules or maybe userland proxy/rerouter. set /etc/resolv.conf to localhost:53, have that forward to 8.8.8.8:1053 or whatever, but without encryption it could be detected I'm guess with deep packet filtering (hopefully beyond the thoroughput constraints of eyeball ISPs)
Is it reasonable to fail if you can't access a specific DNS server?
This is unexpected behavior.
And I don't have access to the /etc/resolv.conf on my Chromecast, that's the problem!
Anyway, there's a new thread on this specific phenomenon. I'm glad I'm not the only one: https://news.ycombinator.com/item?id=19170671
If it's a hot-fix for ISP troubles then I can imagine it being overlooked. Nobody working at Google would ever fail to connect to 8.8.8.8 while developing it.
Oh and in the chromecast (non-ultra anyway), chromecast attempts to ignore any DNS servers supplied by your DHCP - hence why the watch-TV VPN's smartdns fails. Good luck rooting your Chromecast and chattr +i it's /etc/resolv.conf
How does a device "attempt to ignore" DNS servers supplied by DHCP? Like all devices connected to a network it must either use DHCP to get your DNS server or use a hardcoded value, it's not some kind of conspiracy.
"Attempt to ignore" Great question. So it uses hardcoded values of 8.8.8.8/8.8.4.4, unless it can't contact them by testing to resolve connectivity-test.google.com (or something like that), if it can't then it falls back to the DNS servers provided by your DHCP server/router. So to use smartdns with chromecast you have to both set your router to provide the SmartDNS servers and also blackhole 8.8.8.8/8.8.4.4 on your shitty ISP router (iirc static routes) - conspiracy? - i'll leave that to you? (the smartdns route is necessary since chromecast don't have their own VPN facility)
