5 ms·
This isn't anymore "flat" that then TLD nameservers like com., net., etc. It's just one level down. ICANN could certainly afford to run servers for a "flat" TL
by avidiax 2y ago
This isn't anymore "flat" that then TLD nameservers like com., net., etc. It's just one level down.
ICANN could certainly afford to run servers for a "flat" TLD system.
The problem for ICANN is that it will sour relations with all the existing TLD registrars, and there are security problems with allowing any TLD. For example, I might be able to redirect traffic for a particular local network host name (e.g. "router", "fileserver", "raspberrypi", "linksys", etc.) to an external IP address of my choosing. Or I can make something that is normally a local file (e.g. "cmd.exe") and make it also a valid hostname.
- brookst 2y agoNot just ICANN, but how many technical systems are optimized for having a few hundred TLDs? Going to millions / billions seems like it’s likely to uncover a lot of implementation shortcuts. Not necessarily a reason not to do it, just a reason to be a little careful in rollout.
- DidYaWipe 2y ago"I might be able to redirect traffic for a particular local network host name (e.g. "router", "fileserver", "raspberrypi", "linksys", etc.) to an external IP address of my choosing" Interesting idea. Can you give an example of how that would actually happen? Also the cmd.exe one. So what if it's a valid hostname?
- avidiax 2y agoIf the search domain list is empty or contains "." or "", or the search algorithm is flawed (maybe an IoT device), trying to connect might lead to a bare TLD lookup. CMD.exe is either a program accepts either a filename or URL in the same context (VLC does this), or the user is confused about the URL/file distinction. The .ZIP TLD was concerning for this reason.
- DidYaWipe 2y agoThanks for the reply. Maybe I just don't know enough about all the scenarios. I don't know what "the domain search list" is or what user action would involve it. I was looking more for specific dangerous use cases; for example, "The user types such-and-such in the address bar, and instead of getting this he gets that." In other words, how is this a problem in actual practice.
- avidiax 2y agohttps://en.wikipedia.org/wiki/Search_domain https://en.wikipedia.org/wiki/Search_domain An example: The attacker posts a message to a forum, chatroom, etc. like: Download: 2024YourCompanySalaryData.zip When the user clicks "2024YourCompanySalaryData.zip", it is actually a domain name, and loads that website. This website then asks you to enter your corp credentials, or executes a 0-day on the victim's browser, etc. The forum doesn't need to allow file downloads (i.e. a real .zip might not even work), and even if it does, client or server side virus scanning doesn't have a .zip to inspect. The user is less wary of phishing, having never seen the .zip TLD. They assume they are downloading a file. https://blog.talosintelligence.com/zip-tld-information-leak/ https://blog.talosintelligence.com/zip-tld-information-leak/
- DidYaWipe 2y agoThanks. I don't really see how that's worse than today, where a bad actor can do exactly the same thing in a forum post. Typically the post shows the text you enter, but can go to any URL. In terms of the user going to a site instead of a zip file: If a user is willing to unpack and run a random file he downloaded and give it credentials to something... what's the difference? Not being argumentative, but this seems like a stretch.
- avidiax 2y agoThe difference is that many forums or chat programs will automatically linkify valid hostnames/URLs. Now "foo.zip" is a valid URL. You could have a forum or chat program that you think is quite safe, since it doesn't allow file uploads, and doesn't allow arbitrary link text, and this would upend that.