4 ms·

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

by cut3 2y ago

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/
        DidYaWipe 2y ago
        Thanks. 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.
- 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.

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

by cut3 2y ago

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

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/
        DidYaWipe 2y ago
        Thanks. 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.
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.