Where is the DNS headed?(potaroo.net)
potaroo.net
Where is the DNS headed?
https://www.potaroo.net/ispcol/2020-06/row.html
56 コメント
There are a lot of arguments about how DoH with TLS 1.3 will give us privacy etc by the proponents of DoH(not this article).. but it’s basically moving the trust from ISPs to CDNs. There are fewer major browsers and fewer major CDNs than ISPs, I suppose.. so not sure if it’s a good move.
> but it’s basically moving the trust from ISPs to CDNs.
Not just CDNs, ISPs can certainly operate their own DoH servers on their existing DNS infrastructure. If they want to continue selling their users' browsing data to marketing firms, that is what they will have to do.
This also moves trust to the browser and OS TLS certificate stores, which may be problematic depending on your opinion of whether or not you can trust every single one of the governments and organizations behind the hundreds of root CAs.
Not just CDNs, ISPs can certainly operate their own DoH servers on their existing DNS infrastructure. If they want to continue selling their users' browsing data to marketing firms, that is what they will have to do.
This also moves trust to the browser and OS TLS certificate stores, which may be problematic depending on your opinion of whether or not you can trust every single one of the governments and organizations behind the hundreds of root CAs.
People can host their own DoH server themselves. If I can setup DoH and a VPN over one weekend with a Raspberry Pi, then others can do it too.
I am using DNSCryptProxy on a Pi and it fully supports DoH + eSNI even without cloudflare. Works perfectly with Firefox.
The service picks from 65 DoH servers based against the fastest ping time.
That was/is a lot better than before when in reality my only choice was my ISP DNS. In fact I just learned for the last few years that my ISP was hijacking all DNS requests anyway.
I am using DNSCryptProxy on a Pi and it fully supports DoH + eSNI even without cloudflare. Works perfectly with Firefox.
The service picks from 65 DoH servers based against the fastest ping time.
That was/is a lot better than before when in reality my only choice was my ISP DNS. In fact I just learned for the last few years that my ISP was hijacking all DNS requests anyway.
[deleted]
Why can't the ISPs run DoH too?
I agree that due to social issues the problems are fairly real (ISPs ain't gonna do shit). But on a purely technical level DoH should be fine.
I agree that due to social issues the problems are fairly real (ISPs ain't gonna do shit). But on a purely technical level DoH should be fine.
They can. But the problem lies with Browsers (looking especially at Firefox) just ignoring that. The technical aspects of DoH (or DoT) are fine.
Mozilla provides a clear policy for how you get your resolver onto their list. US ISPs (the DoH resolver is only enabled by default in the US) could obey that policy and apply to be added to the list.
But it seems like none of them have done that. Maybe the policy terms are objectionable? Let's see:
"Only aggregate data that does not identify individual users or requests may be retained beyond 24 hours."
But how will the poor ISP make extra money selling DNS query information?
"When a domain requested by the user is not present, the party operating the resolver should provide an accurate NXDOMAIN response and must not modify the response or provide inaccurate responses that direct the user to alternative content."
An ISP that obeys this can't put up advertising banners or sell search engine redirects when you typo a name - they'll have to actually earn money providing Internet service instead.
But it seems like none of them have done that. Maybe the policy terms are objectionable? Let's see:
"Only aggregate data that does not identify individual users or requests may be retained beyond 24 hours."
But how will the poor ISP make extra money selling DNS query information?
"When a domain requested by the user is not present, the party operating the resolver should provide an accurate NXDOMAIN response and must not modify the response or provide inaccurate responses that direct the user to alternative content."
An ISP that obeys this can't put up advertising banners or sell search engine redirects when you typo a name - they'll have to actually earn money providing Internet service instead.
Mozilla can't verify that the providers behave. Apart from the obvious NXDOMAIN answers (not many providers will do so).
Also it is questionable why a free service would be better then a paid one. If one assumes that the ISP is evil, DNS providers are not suddenly less evil.
Also it is questionable why a free service would be better then a paid one. If one assumes that the ISP is evil, DNS providers are not suddenly less evil.
As with its Trust Store Mozilla operates in public. If you believe that providers aren't behaving you can and should present evidence to the community.
Mozilla isn't suggesting you choose services based on how cheap they are, but on whether they implement these policies.
NextDNS, who are on Mozilla's list, offer a paid service if you want advertising filters or porn filtering or whatever but if you're damn sure you "get what you pay for" then pay them their subscription fee and don't switch on any filters.
Mozilla isn't suggesting you choose services based on how cheap they are, but on whether they implement these policies.
NextDNS, who are on Mozilla's list, offer a paid service if you want advertising filters or porn filtering or whatever but if you're damn sure you "get what you pay for" then pay them their subscription fee and don't switch on any filters.
>Mozilla isn't suggesting you choose services based on how cheap they are, but on whether they implement these policies.
Mozilla doesn't know if they do. They can't verify it. So if Mozilla says "Cloudflare and Nextdns adhere to our policies" it's not verifiable by me and neither by them. I don't see a "trust but verify"-implementation. This is my gripe with this behaviour.
Mozilla doesn't know if they do. They can't verify it. So if Mozilla says "Cloudflare and Nextdns adhere to our policies" it's not verifiable by me and neither by them. I don't see a "trust but verify"-implementation. This is my gripe with this behaviour.
How is DoH a net loss to decentralization (by moving to a few major cloud providers) when DoH is merely encrypting the information to prevent MitM spying? Surely nothing stops your favourite ISP or any other local startup from providing DoH services right? Presumably the DNS servers will still talk to each other on the backend over plain text, but if a DoH front-end can be provided by ANY DNS service then how can it be accused of centralising the Internet?
> How is DoH a net loss to decentralization (by moving to a few major cloud providers) when DoH is merely encrypting the information to prevent MitM spying?
It is not merely encrypting the information. Hand-in-hand comes running the resolvers (which, as you noted everyone can) and having all the DNS-using software use them.
Which is much bigger problem, that causes the centralization. Applications are coming today hard-coded for a specific resolver. Configuring it is application-specific and not-automatable, and certainly not automatable in generic manner for all applications. I.e. as a network operator you cannot say that everyone should be using this or that resolver, as you can with the plain old 53/udp DNS and DHCP.
Users are not going to reconfigure each and every application every time they change their network. They will leave it at the default value. The net effect is that the centralization will just happen.
It is not merely encrypting the information. Hand-in-hand comes running the resolvers (which, as you noted everyone can) and having all the DNS-using software use them.
Which is much bigger problem, that causes the centralization. Applications are coming today hard-coded for a specific resolver. Configuring it is application-specific and not-automatable, and certainly not automatable in generic manner for all applications. I.e. as a network operator you cannot say that everyone should be using this or that resolver, as you can with the plain old 53/udp DNS and DHCP.
Users are not going to reconfigure each and every application every time they change their network. They will leave it at the default value. The net effect is that the centralization will just happen.
Applications can choose to ignore the system resolver regardless if it's over UDP or HTTPS. DoH/DoT is showing up in operating system resolvers just not as fast as apps like browsers were willing/able to add it. Standard DHCP options for defining DoH details are still missing though (I think, haven't checked in a while)
> Applications can choose to ignore the system resolver regardless if it's over UDP or HTTPS.
They can, but up until Firefox legitimized this practice, they didn't, maybe except some malware.
> DoH/DoT is showing up in operating system resolvers just not as fast as apps like browsers were willing/able to add it.
The browsers were so fast, that they skipped the discussion about ramification of this change with the rest of community and just abused their position. One might even wonder, why.
Does not make for good relations in future.
> Standard DHCP options for defining DoH details are still missing though
Yup. Here, browsers are not using their position to finish their push, so maybe the situation is acceptable for them.
They can, but up until Firefox legitimized this practice, they didn't, maybe except some malware.
> DoH/DoT is showing up in operating system resolvers just not as fast as apps like browsers were willing/able to add it.
The browsers were so fast, that they skipped the discussion about ramification of this change with the rest of community and just abused their position. One might even wonder, why.
Does not make for good relations in future.
> Standard DHCP options for defining DoH details are still missing though
Yup. Here, browsers are not using their position to finish their push, so maybe the situation is acceptable for them.
On one hand you say browsers are to blame because they went too far too fast bypassing the OS DNS and on the other you say browsers are to blame because they didn't go far and fast enough bypassing the OS DHCP client.
Again are your arguments actually about DoH causing centralization or are you just talking about browsers causing positioning centralization irrespective of the technology?
Again are your arguments actually about DoH causing centralization or are you just talking about browsers causing positioning centralization irrespective of the technology?
> On one hand you say browsers are to blame because they went too far too fast bypassing the OS DNS
Yup, they shouldn't have do this.
> On one hand you say browsers are to blame because they went too far too fast bypassing the OS DNS
No. I'm saying, that once they did what they did, they should have finish the job. They left it unifished.
> Again are your arguments actually about DoH causing centralization or are you just talking about browsers causing positioning centralization irrespective of the technology?
My point is that the way DoH was implemented is causing centralization. DoH could be implemented without causing this effect.
Yup, they shouldn't have do this.
> On one hand you say browsers are to blame because they went too far too fast bypassing the OS DNS
No. I'm saying, that once they did what they did, they should have finish the job. They left it unifished.
> Again are your arguments actually about DoH causing centralization or are you just talking about browsers causing positioning centralization irrespective of the technology?
My point is that the way DoH was implemented is causing centralization. DoH could be implemented without causing this effect.
I think what the parent is saying is that unencrypted DNS queries you can intercept, with DoH you couldn't do that anymore.
Because I as a user have a hard time configuring my computer to use a different resolver.
There will always be a need for a shared global namespace, and DNS needs to improve its security and privacy as the world continues to rely on it. I don’t think DoH is the answer since it just shifts trust from ISPs to CDNs[1]. On the security end, there’s a new DNS protocol called Handshake (https://handshake.org) that’s trying to shift the root of trust from CAs to a distributed ledger. It’s still early but it shows promise with NextDNS.io and Vercel.com supporting it.
[1] CDNs are a lesser evil than ISPs but I still wouldn’t want to need to trust them to protect my privacy.
[1] CDNs are a lesser evil than ISPs but I still wouldn’t want to need to trust them to protect my privacy.
> CDNs are a lesser evil than ISPs
This keeps being repeated, and I simply do not understand it. Could you elaborate how you arrive at this conclusion that CDN > ISP?
My take:
An unsavory ISP is the only thing I can "vote against" as an end user. I can boycott it by switching elsewhere, I can pick from a ton of mobile providers, I can use a VPN to "subcontract" my connectivity experience to an order of magnitude more providers, or if I am really so inclined I can shuffle all of that by the likes of Tor.
There is NOTHING I can do as an individual to avoid a CDN, aside from never visiting content backed by that CDN.
This keeps being repeated, and I simply do not understand it. Could you elaborate how you arrive at this conclusion that CDN > ISP?
My take:
An unsavory ISP is the only thing I can "vote against" as an end user. I can boycott it by switching elsewhere, I can pick from a ton of mobile providers, I can use a VPN to "subcontract" my connectivity experience to an order of magnitude more providers, or if I am really so inclined I can shuffle all of that by the likes of Tor.
There is NOTHING I can do as an individual to avoid a CDN, aside from never visiting content backed by that CDN.
[deleted]
Every ISP I have access to performs DNS-based blocking; to the extent of intercepting ALL UDP DNS traffic (i.e. using other resolvers doesn't work). DoH gets around that.
And I think from the context of the parent, you can choose your CDN('s resolver) -- my version of Firefox (77 on macOS) has NextDNS among the default DoH providers.
And I think from the context of the parent, you can choose your CDN('s resolver) -- my version of Firefox (77 on macOS) has NextDNS among the default DoH providers.
The issue isn't whether you can choose your resolver for Firefox, it's that it balkanizes the namespace resolution mechanism.
Sure, Firefox is using CDN resolver #1, "optimized for the browser experience", while Spotify uses the CDN resolver #2, "optimized for music discovery".
The namespace will balkanize, and with that the control moves to the owners of the resolvers. That would be a natural evolution of the infrastructure purely due to literal "network effects".
If data can be gleaned from current DNS requests, what data can be gleaned from a browser sending metadata? Who controls those DoH servers?
At least the current DNS namespace, nominally, is devolved, particularly with the explosion of TLDs. That has other disadvantages, but there are advantages too.
Sure, Firefox is using CDN resolver #1, "optimized for the browser experience", while Spotify uses the CDN resolver #2, "optimized for music discovery".
The namespace will balkanize, and with that the control moves to the owners of the resolvers. That would be a natural evolution of the infrastructure purely due to literal "network effects".
If data can be gleaned from current DNS requests, what data can be gleaned from a browser sending metadata? Who controls those DoH servers?
At least the current DNS namespace, nominally, is devolved, particularly with the explosion of TLDs. That has other disadvantages, but there are advantages too.
NextDNS is great. I've been using it for the last few months to access Handshake sites[1] and there have been no issues, and it's important that there are more resolvers than just Cloudflare and Google on the market.
[1] You need to enable it in your NextDNS settings.
[1] You need to enable it in your NextDNS settings.
If you can switch ISP, good for you. On my road, there's only one, and it's owned by the government.
Even without switching ISPs you can just use a different recursive resolver by editing your libc resolver config file. This is more difficult when each application has its own config (or none at all.)
Without Do{H,T}, your ISP sees all your DNS queries anyway, and some will MitM them.
This is also my concern. ISPs are typically located in same country making them follow the laws of that country.
I belive authors of the DoH idea were doing it with good intentions but road to hell is paved with good intentions.
What we are doing with DoH is actually breaking decentralised internet infrastructure to centralized (or lets say, less centralized...for now) and this was never a good thing (historywise).
For test why is this bad you can try to block google and amazon ASNs and try to surf around the web. You will notice that the internet is quite different (a hint, yandex.ru was the only search engine I have found that still works)
For instance selling the information about user accessing some domain would be a big no-no in my country.
They are obliged by law to protect customers information except if ordered by court.
With DoH all bets are off. Surely it will give some privacy for users where ISPs are sticking their noses into customers data (like in USA), they wont be able to do it anymore but for me, I trust in our ISPs (or laws) while I surely dont trust google or cloudflare.
We will just give internet resolving into hands of multinational corporations, what could go wrong, right? (Just quick ideas: for $10 / day we offer redirection from yourdomain.com to sellingcrap.com or we resolve .ourinternaldomain only over DoH and not resolve to external ips to force you to use our DoH,...)
I belive authors of the DoH idea were doing it with good intentions but road to hell is paved with good intentions.
What we are doing with DoH is actually breaking decentralised internet infrastructure to centralized (or lets say, less centralized...for now) and this was never a good thing (historywise).
For test why is this bad you can try to block google and amazon ASNs and try to surf around the web. You will notice that the internet is quite different (a hint, yandex.ru was the only search engine I have found that still works)
For instance selling the information about user accessing some domain would be a big no-no in my country.
They are obliged by law to protect customers information except if ordered by court.
With DoH all bets are off. Surely it will give some privacy for users where ISPs are sticking their noses into customers data (like in USA), they wont be able to do it anymore but for me, I trust in our ISPs (or laws) while I surely dont trust google or cloudflare.
We will just give internet resolving into hands of multinational corporations, what could go wrong, right? (Just quick ideas: for $10 / day we offer redirection from yourdomain.com to sellingcrap.com or we resolve .ourinternaldomain only over DoH and not resolve to external ips to force you to use our DoH,...)
What about your ISPs employees? Do you trust a sysadmin pulling 40-50k a year (or less) to not sell your DNS resolver data?
Do you think your ISP has better controls and a security team than some of the big CDNs and cloud providers to detect and prevent this?
The reason I bring it up is because I know a number of ISPs whose sysadmins were on the take and selling bulk regular dumps of DNS resolver data under the table to other parties for years.
Do you think your ISP has better controls and a security team than some of the big CDNs and cloud providers to detect and prevent this?
The reason I bring it up is because I know a number of ISPs whose sysadmins were on the take and selling bulk regular dumps of DNS resolver data under the table to other parties for years.
>What about your ISPs employees? Do you trust a sysadmin pulling 40-50k a year (or less) to not sell your DNS resolver data?
Yes. What use do you have for that data? Especially if it's only one user. There is not much that you can do.
Yes. What use do you have for that data? Especially if it's only one user. There is not much that you can do.
That would be criminal offense - it would mean criminal investigation and quite probably a fine for ISP (negligence). It is just not worth the risk.
If we go into those waters they can also break into my house, smack me on my head, use rubberhose cryptoanalysis, decrypt my machines and copy data from there.
For 3rd party company outside of our juristiction there is nothing that protects my data, actually they will abuse them as part of their bussines model.
The data transfers are not free, if someone is setting up free DNS resolving (cloud storage, providing emails, operating system for phones,...) there is some hidden profit within (the good old: "if something is free you're the product")
For ISP I pay for their service and this is a huge difference (also regarding laws - a much broader set applies)
If we go into those waters they can also break into my house, smack me on my head, use rubberhose cryptoanalysis, decrypt my machines and copy data from there.
For 3rd party company outside of our juristiction there is nothing that protects my data, actually they will abuse them as part of their bussines model.
The data transfers are not free, if someone is setting up free DNS resolving (cloud storage, providing emails, operating system for phones,...) there is some hidden profit within (the good old: "if something is free you're the product")
For ISP I pay for their service and this is a huge difference (also regarding laws - a much broader set applies)
> The reason I bring it up is because I know a number of ISPs whose sysadmins were on the take and selling bulk regular dumps of DNS resolver data under the table to other parties for years.
Can you substantiate this claim? I've heard of ISPs in the USA who sell data, but what you're describing sounds a little bit far fetched.
Can you substantiate this claim? I've heard of ISPs in the USA who sell data, but what you're describing sounds a little bit far fetched.
When you say "under the table", do you mean unbeknown to the customer or the employer? The later will likely result in the employee being fired, fined and possible jailed. I would also suspect that a criminal do not file taxes for selling stolen data, so one can likely add tax fraud.
If you know such people you should consider reporting it to the police.
If you know such people you should consider reporting it to the police.
Your comment opened my eyes in a sense. DoH could be both huge net positive for people in country like Russia, where not law mandetes logging every internet request and indefinite storage of them.
At the same time it could actually hurt privacy of people already protected by law in developed countries.
At the same time it could actually hurt privacy of people already protected by law in developed countries.
Handshake sounds exactly like namecoin which has been here for a while. I guess its trying to be better by not requiring all nodes to be full nodes or something. I feel like that is not the reason why namecoin failed.
As an aside, anyone else notice how it seems like all blockchain projects are annoyingly full of marketing speak, and talk in circles for the tech part. How hard is it to clearly and concisely list the technical goals and properties your solution has?
As an aside, anyone else notice how it seems like all blockchain projects are annoyingly full of marketing speak, and talk in circles for the tech part. How hard is it to clearly and concisely list the technical goals and properties your solution has?
Handshake took inspiration from predecessors like Namecoin but it’s very different. First is scope: Namecoin puts domain names on its blockchain under the .bit TLD whereas Handshake targets TLDs. It does so because Handshake aims to improve the security of TLS by shifting trust from CAs to its blockchain. The CA model is weak bc only a single CA among the thousands of CAs that your computer trusts needs to get compromised in order for your security to get compromised. And the likelihood of a single CA failure increases over time. That’s the opposite of what you want in a robust system.
With Handshake, certs can be pinned directly on the blockchain, which becomes more secure as more nodes join the network and across time as more blocks get mined on top of the pinned cert. This shifts the system from diminishing security to accumulating security. That’s the main innovation behind Handshake.
There are other differences in the issuance model as well. Namecoin’s issuance destined it for failure from day one since names are registered for a flat fee without restriction. This meant that squatters and early adopters could lock up the namespace without paying the true market price of the name. Handshake uses an auction system for name registration and releases the namespace over time (the release date is determined by hashing the name % 52), which means that names are registered for their true market price and newcomers can still register good names. This difference is critical and already playing out successfully — the highest auction was for 200k HNS, which is equivalent to $20k USD and 7/12 of the namespace is still unreleased.
With Handshake, certs can be pinned directly on the blockchain, which becomes more secure as more nodes join the network and across time as more blocks get mined on top of the pinned cert. This shifts the system from diminishing security to accumulating security. That’s the main innovation behind Handshake.
There are other differences in the issuance model as well. Namecoin’s issuance destined it for failure from day one since names are registered for a flat fee without restriction. This meant that squatters and early adopters could lock up the namespace without paying the true market price of the name. Handshake uses an auction system for name registration and releases the namespace over time (the release date is determined by hashing the name % 52), which means that names are registered for their true market price and newcomers can still register good names. This difference is critical and already playing out successfully — the highest auction was for 200k HNS, which is equivalent to $20k USD and 7/12 of the namespace is still unreleased.
So let me get this straight:
The main innovation of handshake is they reinvented DANE on the blockchain? Don't get me wrong, DANE in DNS has some issues, but how is that an improvement from namecoin? Are you saying namecoin is incapable of storing the hash of a certificate in its name records? I'd also bet the cost of a 51% attack on handshake is significantly less than the cost of hacking a CA. [Edit: after posting this i realize im not sure the 51% attack is a relavent attack here, since "double spending" isn't going to help someone pull off a MITM]
The other inovation, is instead of scoping it so it doesnt conflict with existing system, instead handshake directly conflicts with existing DNS names. I fail to see why that is a good thing.
I will admit the auction system is an interesting solution to the cybersquatting problem. I dont think its what most people want out of a naming system (if own microsoft, i want my domain to be microsoft.com, not to wait 10 years for it to be released), but it is an interesting solution.
The main innovation of handshake is they reinvented DANE on the blockchain? Don't get me wrong, DANE in DNS has some issues, but how is that an improvement from namecoin? Are you saying namecoin is incapable of storing the hash of a certificate in its name records? I'd also bet the cost of a 51% attack on handshake is significantly less than the cost of hacking a CA. [Edit: after posting this i realize im not sure the 51% attack is a relavent attack here, since "double spending" isn't going to help someone pull off a MITM]
The other inovation, is instead of scoping it so it doesnt conflict with existing system, instead handshake directly conflicts with existing DNS names. I fail to see why that is a good thing.
I will admit the auction system is an interesting solution to the cybersquatting problem. I dont think its what most people want out of a naming system (if own microsoft, i want my domain to be microsoft.com, not to wait 10 years for it to be released), but it is an interesting solution.
If I buy a domain via auction on handshake for $20,000, who does that money go to?
It gets burned. The original Handshake developers seem very fond of both burning money and giving it away [1].
[1] https://handshake.org/grant-sponsors/
[1] https://handshake.org/grant-sponsors/
> How hard is it to clearly and concisely list the technical goals and properties your solution has?
Very? If you find https://handshake.org/ too marketing-y (I don't) perhaps you'll find the design notes more substantial: https://handshake.org/files/handshake.txt
Very? If you find https://handshake.org/ too marketing-y (I don't) perhaps you'll find the design notes more substantial: https://handshake.org/files/handshake.txt
you can also view it at http://handshake.txt if you are using a handshake resolver
Spoiler: it's a redirect!
Handshake does not seem to try to solve the same problem as DoH, but rather somewhat what DNSSEC is solving.
DoH's point is mostly to hide DNS traffic. DNSSEC's point is to validate a DNS record all the way to root.
The benefits on Handshake over existing solutions are unclear to me.
DoH's point is mostly to hide DNS traffic. DNSSEC's point is to validate a DNS record all the way to root.
The benefits on Handshake over existing solutions are unclear to me.
The root of trust for DNSSEC is a key that's stored and controlled by people, and needs to go through routine key signing ceremonies. This is fallible and even recently there have been issues with the key signing ceremony https://www.icann.org/news/blog/root-key-signing-key-ceremon.... One could argue that this system works "good enough" but ultimately I'd prefer that the root of trust for security on the internet to be more robust than relying on humans to avoid error. That's what Handshake is trying to do — instead of using a key in a physical vault as the root of trust, you use a distributed blockchain that's very difficult to break.
It's also relevant to note that 51% attacks to most payment/store-of-value blockchains like Bitcoin, but for Handshake 51% attacks don't really affect the security of the network because an attacker would need to get the private keys for a name in order to attack its certificate.
It's also relevant to note that 51% attacks to most payment/store-of-value blockchains like Bitcoin, but for Handshake 51% attacks don't really affect the security of the network because an attacker would need to get the private keys for a name in order to attack its certificate.
Handshake is more of a solution to a political/governance problem than a technical one.
IMO compared to google (or most companies running ads) my ISP has been extremely well behaved. They mostly act as a pipe.
Keep in mind some of these US companies that are willing to run resolvers think censoring the DNS over the content it points to is a good thing.
Keep in mind some of these US companies that are willing to run resolvers think censoring the DNS over the content it points to is a good thing.
[deleted]
s/HTML/HTTP/c in a few places.
What does the “c” flag do?
"Confirm". It prompts for verification before substituting, in vim:
https://www.linux.com/training-tutorials/vim-tips-basics-sea...
https://www.linux.com/training-tutorials/vim-tips-basics-sea...
oh gawd I just type the `c` out of habit now. that wasn't intentional at all.
Confirmed ;-)
I think it’s forcing case sensitive. I’ve never seen it though.
Ok, but there are more important reasons. Walled-garden directories is a symptom not a cause. For that matter, SNI and path-based load balancers are examples of the application-level address resolution overlay already in practice. Those techniques merely implement, not drive, balkanization.
Basically, application-layer DNS doesn’t pass the “but for” test. As in, it is not correct to say “but for application-layer DNS, Facebook/WeChat/Google couldn’t build walled gardens. With it they can.”