81–90 of 117 posts
Is there an actual case to be made for pointing localhost to anything other than the loopback device?
I would not trust DNS resolution libraries embedded in applications that cannot easily be changed or removed. Especially if they ignore /etc/hosts or point users toward third party caches.
Think of your own cache as a HOSTS file that accepts wildcards.
How would this affect Chrome on Android, which allows you to redirect localhost requests from a phone to access localhost on the computer it's tethered to?
It should be unaffected by the suggestion in this document.
Earlier quoted context omitted.
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.
> 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.
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.
Earlier quoted context omitted.
Like the linked wikipedia article says, .local is used by mDNS(zeroconf/bonjour/avahi/etc.), so you might see weird stuff if you use it for a "normal" DNS environment. AFAICT current "best practice" for private networks is to use a private subdomain of your real domain. Say, .internal.example.com.
Google registered the .dev gTLD for their internal use. So I've been doing the same, hijacking all requests for the .dev gTLD and serving up my own zones.
Earlier quoted context omitted.
Before the gTLDs were expanded it was easy: just choose an unused word. These days I tend to see either subdomains of the main public domain, or a public domain registered solely for internal use.
The proper way to do it, though it does mean that things such as using ssl for wildcard domains at an arbitrary level become difficult and potentially expensive.
Earlier quoted context omitted.
> So let's say I've assigned 10.1.1.1/32 to a device loopback interface, I'm announcing it in my IGP, and I've bound a particular service to listen on 10.1.1.1:1234. Should the local resolver library be allowed to return 10.1.1.1 for servicename.localhost? Under this draft's (re)definition of loopback addresses, definitely not. So now we've lost that symbolic way to configure a service consumer to connect locally. Yo…
Ah, I think you've assumed that the assignment of 10.1.1.1/32 to lo in that example is to replace 127.0.0.1/8. It's in-addition-to. The most common case is multi-homed routers that wish to announce a management address into the IGP, but I've also used it for stuff from proxy farms to making containerized/virtualized microservices a bit more portable, and I'm far from the most sophisticated user. There's people out th…
Earlier quoted context omitted.
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.
> 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.