6 ms·

You may wish to read [RFC2826] which the Internet Architecture Board of years past wrote on why a unified name space is important for the Internet. [RFC2826]:

You may wish to read [RFC2826] which the Internet Architecture Board of years past wrote on why a unified name space is important for the Internet. [RFC2826]: https://www.rfc-editor.org/rfc/rfc2826 https://www.rfc-editor.org/rfc/rfc2826

zrm 3y ago
That isn't necessarily incompatible with alternate domain name systems. If OpenNIC is registering names under .pirate and ICANN is aware of this then it can simply refrain from using .pirate as a TLD and you still have a unified namespace. It just happens by consensus rather than central authority. If they would get along a little better then you might even have the ICANN root servers direct queries for those TLDs to the OpenNIC servers. It's not obvious what benefit is achieved by not doing this.
- hardaker 3y ago
  You may wish to read [RFC9476], which provides a solution for anchoring alternate name spaces in a way that provides both a signalling point for establishing that you've left the DNS and a way to prevent collisions with the DNS itself. [RFC9476]: https://www.rfc-editor.org/rfc/rfc9476.html https://www.rfc-editor.org/rfc/rfc9476.html
  - zrm 3y ago
    This doesn't help much to prevent collisions though, does it? An alternate namespace is obviously not going to use a TLD that already exists in the DNS, but it's much more likely to use one that exists in a different alternate namespace they've never heard of, since those will be more obscure and more likely to be missed. Putting them both under .alt does nothing to prevent this. What you're really doing is reserving all of the as yet unallocated namespace to the DNS, privileging it over any alternatives which then have to use longer names. What you need is a mechanism for alternate namespaces to register their use of a particular subset of the global namespace against both other alternate namespaces and the DNS, at which point you wouldn't need to put them all under .alt. They also immediately damaged that subset of the namespace: > DNS stub and recursive resolvers do not need to look them up in the DNS context. Now some DNS stub resolver implementers or administrators will read this and reject any queries under .alt, making it unsuitable for any namespace you would like intermediary resolvers to look up in an upstream server that supports them.
    - hardaker 3y ago
      > This doesn't help much to prevent collisions though, does it? It helps alternate name spaces not collide with the DNS. Without a registration system, it doesn't help alternate names spaces from colliding with each other (see .wallet for an example of this happening at the TLD space). There was a very large, um, "discussion" about whether or not there should be a registration system for alternate spaces when many of the alternate spaces were being specifically designed because they hated registration systems in the first place. EG, putting a centralized registration on top of decentralized architectures seems, um, weird at best. Supposedly the GNU naming system is creating a registration system that is optional to use. I don't know details about it and whether it's up and running yet. The real value (entirely IMHO) with .alt as a separation is that it allows people to figure out when they're communicate about why person A can't access the resources that person B has referred them to, is that when it ends in .alt it points toward "oh, I need to look somewhere else than the DNS" vs when it's under a TLD you'd have to know which are alternate spaces and which are not (for each person too -- see the gnu DNS also). >> DNS stub and recursive resolvers do not need to look them up in the DNS context. > Now some DNS stub resolver implementers or administrators will read this and reject any queries under .alt So.... let's say they don't reject them and you send a alternate name space query to a resolver that doesn't understand that alternate name space? You're still going to end up with a failed lookup, and thus just leaking alternate space queries to the DNS that can never resolve. This will look just like a rejection, but with a longer delay. Alternate name spaces need alternate resolution mechanisms (by design), so software that wants to support both will need to figure out where that split point is so they can switch from one resolution system to another when needed. The real thing is: why are alternate spaces even caring whether or not they look like the DNS and have a TLD? If you want to truly revolutionize naming, then do something revolutionary and discard the current letters/numbers/etc separated by dots and create something entirely new and stop trying to look like the existing system. But that's an even harder problem because it also requires rewriting a lot of UI code. So most intentionally want to conflict with the DNS because it "helps them", theoretically, get more market space by hopefully believing that applications will suddenly be able to use an alternate naming space -- all without the user knowing they're in one?
      - 3y ago

zrm 3y ago

That isn't necessarily incompatible with alternate domain name systems. If OpenNIC is registering names under .pirate and ICANN is aware of this then it can simply refrain from using .pirate as a TLD and you still have a unified namespace. It just happens by consensus rather than central authority. If they would get along a little better then you might even have the ICANN root servers direct queries for those TLDs to the OpenNIC servers. It's not obvious what benefit is achieved by not doing this.

hardaker 3y ago
You may wish to read [RFC9476], which provides a solution for anchoring alternate name spaces in a way that provides both a signalling point for establishing that you've left the DNS and a way to prevent collisions with the DNS itself. [RFC9476]: https://www.rfc-editor.org/rfc/rfc9476.html https://www.rfc-editor.org/rfc/rfc9476.html
- zrm 3y ago
  This doesn't help much to prevent collisions though, does it? An alternate namespace is obviously not going to use a TLD that already exists in the DNS, but it's much more likely to use one that exists in a different alternate namespace they've never heard of, since those will be more obscure and more likely to be missed. Putting them both under .alt does nothing to prevent this. What you're really doing is reserving all of the as yet unallocated namespace to the DNS, privileging it over any alternatives which then have to use longer names. What you need is a mechanism for alternate namespaces to register their use of a particular subset of the global namespace against both other alternate namespaces and the DNS, at which point you wouldn't need to put them all under .alt. They also immediately damaged that subset of the namespace: > DNS stub and recursive resolvers do not need to look them up in the DNS context. Now some DNS stub resolver implementers or administrators will read this and reject any queries under .alt, making it unsuitable for any namespace you would like intermediary resolvers to look up in an upstream server that supports them.
  - hardaker 3y ago
    > This doesn't help much to prevent collisions though, does it? It helps alternate name spaces not collide with the DNS. Without a registration system, it doesn't help alternate names spaces from colliding with each other (see .wallet for an example of this happening at the TLD space). There was a very large, um, "discussion" about whether or not there should be a registration system for alternate spaces when many of the alternate spaces were being specifically designed because they hated registration systems in the first place. EG, putting a centralized registration on top of decentralized architectures seems, um, weird at best. Supposedly the GNU naming system is creating a registration system that is optional to use. I don't know details about it and whether it's up and running yet. The real value (entirely IMHO) with .alt as a separation is that it allows people to figure out when they're communicate about why person A can't access the resources that person B has referred them to, is that when it ends in .alt it points toward "oh, I need to look somewhere else than the DNS" vs when it's under a TLD you'd have to know which are alternate spaces and which are not (for each person too -- see the gnu DNS also). >> DNS stub and recursive resolvers do not need to look them up in the DNS context. > Now some DNS stub resolver implementers or administrators will read this and reject any queries under .alt So.... let's say they don't reject them and you send a alternate name space query to a resolver that doesn't understand that alternate name space? You're still going to end up with a failed lookup, and thus just leaking alternate space queries to the DNS that can never resolve. This will look just like a rejection, but with a longer delay. Alternate name spaces need alternate resolution mechanisms (by design), so software that wants to support both will need to figure out where that split point is so they can switch from one resolution system to another when needed. The real thing is: why are alternate spaces even caring whether or not they look like the DNS and have a TLD? If you want to truly revolutionize naming, then do something revolutionary and discard the current letters/numbers/etc separated by dots and create something entirely new and stop trying to look like the existing system. But that's an even harder problem because it also requires rewriting a lot of UI code. So most intentionally want to conflict with the DNS because it "helps them", theoretically, get more market space by hopefully believing that applications will suddenly be able to use an alternate naming space -- all without the user knowing they're in one?
    - 3y ago