5 ms·

This whole scam was so disappointing, although par for ICANN's course. When we heard that they were opening up TLDs, I thought that finally limited TLDs would b

This whole scam was so disappointing, although par for ICANN's course. When we heard that they were opening up TLDs, I thought that finally limited TLDs would be abolished. But nope. ICANN turned the whole thing into another disgraceful money grab... taken to a new level. Now that it has flopped, we can just hope that someday we'll be able to end a domain name with any valid string.

cut3 2y ago
Ive always wondered why a tld cant just be anything after the last period
- DidYaWipe 2y ago
  As far as I know, there's no technical reason. I've seen people raise trademarks as an issue, but that's a red herring. There are already trademark-dispute resolution procedures in place.
- userbinator 2y ago
  Mainly to control the resource usage of the root servers, I believe. DNS is hierarchical, and I don't think devolving into a semi-flat namespace is a good idea at all.
  - 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 ago
      Not 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 ago
        If 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 ago
        Thanks 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 ago
        https://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/
  - lifthrasiir 2y ago
    Technically speaking, it is possible to use an approach similar to IDN to provide a flat namespace without actually making the root zone itself flat. Namely, an arbitrary TLD .abcdefgh can be translated to .xx--abc.def.gh--yy internally if .abcdefgh itself results in NXDOMAIN. Each level would then have less than 10^5 labels at worst.

cut3 2y ago

Ive always wondered why a tld cant just be anything after the last period

DidYaWipe 2y ago
As far as I know, there's no technical reason. I've seen people raise trademarks as an issue, but that's a red herring. There are already trademark-dispute resolution procedures in place.
userbinator 2y ago
Mainly to control the resource usage of the root servers, I believe. DNS is hierarchical, and I don't think devolving into a semi-flat namespace is a good idea at all.
- 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 ago
    Not 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 ago
      If 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 ago
        Thanks 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 ago
        https://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/
- lifthrasiir 2y ago
  Technically speaking, it is possible to use an approach similar to IDN to provide a flat namespace without actually making the root zone itself flat. Namely, an arbitrary TLD .abcdefgh can be translated to .xx--abc.def.gh--yy internally if .abcdefgh itself results in NXDOMAIN. Each level would then have less than 10^5 labels at worst.