I hate to be the bearer of bad news, but this isn't fixable at the DNS level.
I can't remember when it was first researched, but sometime after the birth of Tor, there was increased interest by DoD and others to track connections over an obscured network. The end result was a paper that showed you could identify the sources and destinations of traffic solely by monitoring aggregate traffic over major routes in the network. In essence, for completely encrypted tunnels, you could know exactly what user was using what Tor exit node, assuming you had enough network sensors spread out and enough sample data. There was also the possibility of discovering Tor hidden nodes and what users were using them.
Therefore, regardless of traffic (ex. DNS), if you have the motive to find out who is doing what on the internet, and the capital and access for the network sensors, you can find out who's going where (and even doing what to a certain extent).
The more traffic is encrypted, and the more we push for more privacy and more difficult we make it to monetize our network access, the more reason they have to increase their surveillance, so they can continue to fund all these products and technologies we take for granted.
The cause of an arms race isn't arms. It's the inability to come to terms on an issue. We should be addressing the issue, not ramping up our weapons research. I know this isn't a "sexy solution", but it would definitely free up our time to worry about more important or interesting things.
I have configured local Unbound to use four different open DNS provideds, round-robin, the rationale being each one gets 1/4th of requests. On the other hand, I am sending requests to four providers instead of one, so I have to trust four providers instead of one. What’s better?
This isn't a concrete software recommendation, but the DNS would lend itself exceptionally well to a distributed p2p resolver that would prevent most queries from hitting centralized servers in the first place - it's just a simple distributed database. You'd need some sort of multiparty trust metric to avoid tampering (or DNSSEC), but modulo that peers could just freely pass around records.
There would be a little more complexity these days with large companies changing answers based on the address of the requester, but that doesn't seem too hard to account for or even just ignore. And to reduce traffic even further, you could take some liberties with TTLs, for records that actually don't change often.
That was my take on it too. The first resolver knows who you are, so can return the DNS query response but not the actual query itself as it’s encrypted. The exit resolver (exit node if you will) knows the DNS query but not the original source of the request, since it came from the first resolver. So at this point it looks like the idea of onion routing applied to DNS queries. Sound about right?
"Knowing the domain names of the websites you visit, or servers that apps access on your behalf, is valuable intelligence. DNS traffic is especially valuable because it reflects what users are doing in real time.
"The names you asked for, and when you ask for them, say an awful lot about you," Huston said in his presentation to the APNIC 52 conference on Wednesday."
This goes on the assumption that a DNS request and HTTP request are coupled in time. They can be decoupled.
Ive been gathering DNS data in bulk for many years. This can be done, e.g., by making UDP/TCP DNS requests to the appropriate authoritative nameservers, making UDP/TCP requests to DNS caches run by third parties (this is what developers seems to prefer; its an inefficient, inconsiderate and braindead method, IMO), extracting the data from public scan datasets available for download, extracting from passive DNS datasets, and most recently making pipelined HTTP requests to DoH servers over a single TCP connection. Its good to have multiple sources of DNS data so one can note any differences.
A surveillance capitalist acting as a passive DNS data or DoH provider could be observing this data gathering but it would be difficult to connect any subsequent HTTP requests, separated in time, days, months or years later, with particular domainnames. With the way CDNs are used today, a large percentage of these domainnames can be requested from the same IP address. Obviously CDNs can have troves of data on users' browsing habits. Perhaps surveillance capitalists approach CDNs to get data about users.
What this article fails to mention is TLS 1.2 leaking domainnames in certificates and SNI extensions, in plaintext. Using third party DNS like Google, or even "Oblivious DNS" wont stop ISPs and others on path from seeing every domainname for every site the customer visits. TLS 1.3 with ESNI will fix this but its still experimental and Cloudflare is the only host I am aware of that supports it. Nevertheless I use it and it works well. For non-Cloudflare sites that require SNI (its quite a small of the sites submitted to HN) I use archive.org. Of course, I am trusting that archive.org isnt engaged in "surveillance capitalism". :) Another trick for Cloudfront hosted sites is one can use the [hash].cloudfront.net domainnname for SNI instead of the "real" domainname. If only mall number of customers are doing this, it makes more work for ISPs or marketers for very small reward, but its a trivial amount of work. Archive.org is the best solution I have so far.
For recreational web use, I have stopped using DNS altogether. I let the forward proxy store the IP address info for each host in memory. Its very fast.
ESNI is superseded by a better design and implementation called ECH. It’s still not widely available, but has been available in Firefox. Cloudflare, of course, supports it (Fastly is the third co-author of this).
instead of firefox as the ech client, its possible to use esni/ech-enabled openssl together with proxy, so can use any tcp client, not just web browsers or only certain web browsers. because i use openssl i dont have to wait for firefox releases.
the "bleeding edge" ech is not in firefox. the above link says firefox is still stuck on drafts 08 and 09. openssl is on drafts 10 and 13.
I am not happy with the design of ESNI as in its current form it is not straightforward to implement as it relies on dns hackery. I would rather instead that the outer tunnel be encrypted using a cert for the IP address, and the inner tunnel as before using the cert for the domain. This is analogous to how EAP works with an outer and inner identity.
only reason esni is even usable now is because its with a cdn. one key works for hundreds of thousands of websites. having to request a different key for every website would be far too much hassle. its a shame whenever folks write about encryoted sni they never offer the user perspective of sni which is that the sni extension prioritises cost savings for websites and increased business for cdns over privacy for users. sni was never something users needed. it may have solved a problem for websites who didnt want to pay for dedicated ssl certs (arguably, this has since been better solved by lets encrypt), and created a business opportunity for cdns, but it has created a new problem for users.
There are at least two ways of looking that make using 8.8.8.8 sense.
First is that if you assume that Google has a decent profile of you anyways (from other services), then feeding in DNS data to Google would have relatively minor impact on your privacy.
Second is that at least Google is relatively competent and restrictive in providing any of the important data to 3rd parties, whereas other providers (like your ISP) is more like to sell the data wholesale left and right.
Both are sort of "better the devil that you know" ways of thinking.
> Second is that at least Google is relatively competent and restrictive in providing any of the important data to 3rd parties, whereas other providers (like your ISP) is more like to sell the data wholesale left and right.
While this is true (of all the entities trying to gather my data I'd expect Google to be one of the least likely to leak it - after all, no matter your preconceptions, Googlers are usually pretty good at what they do) it's at least somewhat moot because while your ISP (or, say, MasterCard) is more likely to sell your data, Google is more likely to be buying that data (from, say, MasterCard). If any basket acquires more than a certain percentage of my eggs (or footprints), I start to get uncomfortable.
According to Google [1], they keep client IP addresses and DoH headers for up to 48 hours and then strip them after that, and don’t use the logs for any personalization.
Everyone else here is assuming you can’t trust what they say, but it’s worth pointing out that, if they’re telling the truth, none of the rest of this privacy discussion matters.
Sure, which is why Oblivious DNS would be a nice upgrade. One less thing to worry about.
But I expect that, compared to 8.8.8.8 or 1.1.1.1, the user experience will be unaffected, and there will be no measurable improvement in user privacy. (Because we have no way to measure it unless something bad happens and it can somehow be traced back to one of these DNS services.)
The handshake team itself has never used language like "overthrow", and have carefully designed the system to work with DNS, not necessarily replace it. From their FAQ:
> Does Handshake replace DNS?
No. Handshake is meant to replace the root zone file, not DNS. Browsing the web with human readable names is what Internet users have gotten acclimated to. Our solution allows for a seamless transition between a centralized name root zone file controlled by private parties to a decentralized root zone file controlled by actual Internet users. The Handshake blockchain itself is essentially one big distributed zone file in which anyone has the right to add an entry in.
The word "overthrow" is not used anywhere in that thread.
"Collision" is used 26 times, mainly referring to name collisions between different root zone domains or to the ICANN NCAP project (Name Collision Analysis Project).
"Collision Course" is used only once, by a contributor who was not part of the original Handshake team but joined and became a major contributor later.
Hardly representative of the entire community, and definitely not of the founding team.
the context for that comment is that handshake took a snapshot of the icann namespace. so any names icann adds or changes after the fact will conflict with the HNS namespace.
The comment is the start of a longer thread that is one data point in understanding how HNS would rather be adversarial than cooperative, from my perspective and others. Much of the crypto public speak is about replacing rather than enhancing existing systems. There is no join, only beat. They would likely become the very thing they desire to replace. It's human nature
There are factions within crypto, some think the "end of history" looks like crypto replacing centralized systems. others (like myself) think those systems are complements and simply alternatives in the marketplace.
As to being adversarial... ICANN was allocated 1.2% of the total HNS supply, and all existing TLD owners (at the time of the snapshot) can claim their TLDs on chain. The icann allocation is 5.8% of the current circulating supply.
i suppose there could have been a way to give ICANN a blank check to modify the handshake namespace in perpetuity, but i suspect that might either be technically unworkable or just made the whole venture pointless.
It sounds great. Do you use it? Curious to learn about people's experiences with it and things like it. Centralized control over DNS is flawed, and I would like to see more solutions to this problem deployed and in use. Unfortunately, many HNers will immediately scoff at the mere mention of blockchain.
I scoff at the plethora of pointless blockchains shoehorned into a problems where neither centralization nor trust are essential complexity of the problem domain. Most new blockchain tech claims that they'll solve centralization and trust (in a domain that doesn't have those problems) -- as long as you centralize on their platform and trust them. Most blockchain is a whitewash for new-age centralization.
But DNS does have those problems inherent in the domain. It's one of the very few use-cases for blockchain that actually makes a modicum of sense.
It was actually one of the legit uses of blockchain. It actually replaces ICANN, not DNS. There are registrars that have built on top of HNS, but serving DNS requests still uses the same tools and tech.
A couple of problems with it is that the do not prevent existing domains from transacting (unless you are in the top 100k) and the real big problem is the same guy who ruined Freenode, essentially controls handshake.
Unless a blockchain based DNS is involved with a blockchain currency, I see nothing to stop the mad grab of all memorable, pronounceable, or legible names less than 40 characters long almost immediately.
If I was so inclined to participate, I'd just grab a ton of blockchain DNS names, back them up, and hope I can sell one someday.
> artblockscurated.eth bought for 7.0Ξ ($24992.66)
There are tons of similar sales apparently. Some of it just doesn't make sense. $200k for artdao.eth? Really? The last two are apparently NFT related things. The only one in there I can maybe understand is esports.eth since $10k for an esports company to have a premium wallet address makes sense to speculate on given that market.
However, they have domain validated integration of existing (ICANN) domains now, so I don't see much value in the .eth stuff. There's some value in avoiding confusion. Saying "send money to esports.eth" is less ambiguous than "send money to esports.com" because the latter could be confused with normal eTransfers. Beyond that though, what makes a .eth domain worth $10k+?
I use it, and own a small portfolio of names on chain. "base" and "faq" are a couple of them. It's been pretty interesting to watch the ecosystem mature.
Just recently a small dev team released a desktop app that syncs name data to your local device and lets you browse sites with lookups to the handshake root before falling back to icann root https://impervious.com/fingertip.html
the way handshake addresses this problem is putting a cap on the total number of names that can be registered, and then users compete on fees in order to get their transaction mined to renew the name
yeah. right now it's ~$0 since there's no fee competition, but as soon as the total names registered gets close to the limit (66 million) then the cost of renewall will go up and it will be costly to squat. there are 1.85 million names registered currently.
I've looked at HNS and ENS a bit. I want a domain on both, but haven't bought any. The biggest problem is having to deal in crypto currency.
In Canada buying and selling crypto currency is similar to dealing with stocks. You need to track it like an asset and both sales and transfers create taxable events.
Imagine you want to buy a 2x4 at Home Depot. In the crypto equivalent world, you'd have to provide KYC / AML information to an exchange that supports Home Depot to get an account, buy Home Depot stock, use the stock to buy lumber, sell your excess stock, and claim any relevant losses / gains on your taxes. It's a hilariously bad user experience.
Then on the ENS side the fees are insane. To buy a "$5" .eth domain right now shows me .001 ETH (they try to keep it around $5 USD) for the domain plus .083 (~$285) ETH for gas fees for ~$290 total.
I went as far as signing up to an exchange to get a .eth domain and that exchange charges .008 ETH to transfer my money off the exchange which is another $30. So all in, right now it would cost me (up to) $320 USD to buy a "$5" .eth domain.
Paying $315 in fees to buy a $5 good doesn't seem like the free market efficiency the crypto crowd is selling. To me it feels like a bit of a grift where whoever's getting those fees is taking a ton of money out of the system.
Then if you jump over to the HNS side, the exchange I signed up with doesn't support HNS, so I would need to provide them (HNS) KYC levels of identity verification too and I'm not willing to do that because they're not listed in FINTRAC (Canada's AML regulator). I think Coinbase would be ok, but what a hassle!
DNS is getting rather long in the tooth and I expect it will be replaced largely RSN. Article assumes we will keep internet address assignment the same as well and not at least move to IPV6 and a less stingy model of effectively static addresses. And the use of VPN today and something rather different tomorrow will likely change this. What happens when you effectively throw an authenticated request into some pool/queue of outstanding request and something else pools it and forwards it then putting response in pool? The assumed direct link of packet IP address to website that is fixed is not likely to last so long imho. Already we are starting to see blockchain mediated DNS like services. I would not be surprised by some kind of NFT registration of sites.
What cannot you do with traditional internal DNS that you can do with those newfangled DNS replacements? They offer censorship resistance and potentially a much lower cost to register your name, but they have plenty of drawbacks too.
Quite frankly, I suspect I might be getting trolled by GPT-3, but I'm asking the question anyway for the benefit of the community.
I can't remember when it was first researched, but sometime after the birth of Tor, there was increased interest by DoD and others to track connections over an obscured network. The end result was a paper that showed you could identify the sources and destinations of traffic solely by monitoring aggregate traffic over major routes in the network. In essence, for completely encrypted tunnels, you could know exactly what user was using what Tor exit node, assuming you had enough network sensors spread out and enough sample data. There was also the possibility of discovering Tor hidden nodes and what users were using them.
Therefore, regardless of traffic (ex. DNS), if you have the motive to find out who is doing what on the internet, and the capital and access for the network sensors, you can find out who's going where (and even doing what to a certain extent).
The more traffic is encrypted, and the more we push for more privacy and more difficult we make it to monetize our network access, the more reason they have to increase their surveillance, so they can continue to fund all these products and technologies we take for granted.
The cause of an arms race isn't arms. It's the inability to come to terms on an issue. We should be addressing the issue, not ramping up our weapons research. I know this isn't a "sexy solution", but it would definitely free up our time to worry about more important or interesting things.