5 ms·

I agree with you. There should exist a standardized tld for internal networks that we can use and be sure that no one else has control over. Buying a domain and

I agree with you. There should exist a standardized tld for internal networks that we can use and be sure that no one else has control over. Buying a domain and use a subdomain of that one is not a good workaround. .internal would be nice and is not used by now. I may go write an rfc now :) related discussion: http://serverfault.com/questions/17255/top-level-domain-domain-suffix-for-private-network http://serverfault.com/questions/17255/top-level-domain-doma...

yrro 10y ago
What happens as soon as two different organizations want to connect their networks together and they both turn otu to be using the same hijacked TLD? Use a real domain name instead.
- y0ghur7_xxx 10y ago
  > What happens as soon as two different organizations want to connect their networks together and they both turn otu to be using the same hijacked TLD? Why "hijacked" TLD? It would be a standard TLD. If two orgs merge, and they both happen to use the same hostnames for some things, like say git.internal, they just refactor those hosts, or merge them since they merge.
  - parenthephobia 10y ago
    It is not usually as easy as you suggest to just merge or refactor conflicting domains. Even if you're lucky, and it is git.internal - rather than source.internal with VSS on one and ClearCase on the other - there may be conflicting repository names. These'll be configured on developer's PCs, CI servers, automated deployment scripts. And that's just one domain name. That's potentially a lot of work to connect two organizations: who may well not be connecting because of a merger - they may simply be contractors. If ABC Corp and XZY Corp had their local stuff on internal.abc.com and internal.xyz.com, then all their old domains - and urls - keep working after they connect their networks. Whether and when to merge their services together becomes a decision based on the merits of each merge, rather than something that is forced because they choose a bad naming scheme.
  - yrro 10y ago
    Why go through all the pain of renaming hosts if you can avoid it by using a real domain name in the first place?
  - icedchai 10y ago
    How is this simpler than just using real domain names? I use an int.company.com domain for my internal hosts and have for 20+ years.
- ekimekim 10y ago
  Surely it's not that hard to come up with a unique, memorable internal TLD? eg. the company name - "git.facebook", "foo.microsoft", "monitoring.dev.google"
Pxtl 10y ago
I thought .local was a de-facto standard for this?
- shellac 10y ago
  .local is used for link-local domains, for resolution by multicast DNS ('zeroconf'). See https://tools.ietf.org/html/rfc6762 https://tools.ietf.org/html/rfc6762. Microsoft used to suggest using it for local networks, but now advise against it.

yrro 10y ago

What happens as soon as two different organizations want to connect their networks together and they both turn otu to be using the same hijacked TLD? Use a real domain name instead.

y0ghur7_xxx 10y ago
> What happens as soon as two different organizations want to connect their networks together and they both turn otu to be using the same hijacked TLD? Why "hijacked" TLD? It would be a standard TLD. If two orgs merge, and they both happen to use the same hostnames for some things, like say git.internal, they just refactor those hosts, or merge them since they merge.
- parenthephobia 10y ago
  It is not usually as easy as you suggest to just merge or refactor conflicting domains. Even if you're lucky, and it is git.internal - rather than source.internal with VSS on one and ClearCase on the other - there may be conflicting repository names. These'll be configured on developer's PCs, CI servers, automated deployment scripts. And that's just one domain name. That's potentially a lot of work to connect two organizations: who may well not be connecting because of a merger - they may simply be contractors. If ABC Corp and XZY Corp had their local stuff on internal.abc.com and internal.xyz.com, then all their old domains - and urls - keep working after they connect their networks. Whether and when to merge their services together becomes a decision based on the merits of each merge, rather than something that is forced because they choose a bad naming scheme.
- yrro 10y ago
  Why go through all the pain of renaming hosts if you can avoid it by using a real domain name in the first place?
- icedchai 10y ago
  How is this simpler than just using real domain names? I use an int.company.com domain for my internal hosts and have for 20+ years.
ekimekim 10y ago
Surely it's not that hard to come up with a unique, memorable internal TLD? eg. the company name - "git.facebook", "foo.microsoft", "monitoring.dev.google"

Pxtl 10y ago

I thought .local was a de-facto standard for this?

shellac 10y ago
.local is used for link-local domains, for resolution by multicast DNS ('zeroconf'). See https://tools.ietf.org/html/rfc6762 https://tools.ietf.org/html/rfc6762. Microsoft used to suggest using it for local networks, but now advise against it.