> I don't know why people thought they could start using random TLD's on their own, there was always the risk they could be delegated officially.
For a long time, the set of non-country TLDs was mostly static, and country TLDs were always exactly two characters. The risk was always there, but it looked like it was only a theoretical risk, until recently the floodgates opened and nearly every TLD became fair game.
"Recently" being relative of course. The big gTLD expansion was first announced in 2008 when the application process for new gTLDs started being worked on.
There's been plenty of time to fix things, but as usual, people will delay and only fix things when they break. Hence ICANN's Controlled Interruption process.
Those of us who used augmented DNS roots knew of this problem long before 2008. In the various augmented root systems, there were a lot more non-country top-level domains a lot (i.e. years) earlier, and people had already registered ones that conflicted with private-use top-level domains beloved of wrongheaded system administrators and developers. AlterNIC had corp., for example.
So "recently" is even more relative than that. (-:
People still use .local in this day and age, I’m so freaking tired of editing my avahi-daemon config to not spend 10 seconds resolving internal resources.
Using .local is just asking for trouble -- avahi/bonjour/mdns have used that pseudo-TLD for ages. Using that locally is a great recipe for things breaking.
In fact, Apple officially registered it for this purpose in order to avoid this kind of conflict. These conflicts with manually-assigned .local names were already happening since the beginning of Apple's zeroconf work, and other people were frustrated with them (you can see on Wikipedia that Microsoft had previously advocated manual use of .local in its documentation). But the designation has been official since 2013.
Edit: This was all described in another part of this thread already, sorry for the pure duplication.
I looked through that trying to find why the parent commenter shouldn't use .local as they described, and it sounds like their use case is exactly what the RFC recommends. Can you explain why it's a bad idea?
If they're relying on a DNS server for resolution, they might not get the behavior they expect on an RFC compliant system.
Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB).
And an issue most sysadmins would be familiar with unfortunately.
For years, Microsoft's own guidelines suggested using .local for internal AD domains. Then one day, Apple started using it on mDNS, and Microsoft advice was suddenly "never use .local".
But renaming an AD domain is painful and in many scenarios not supported at all, and people with domains more than a few years old are regularly pointed at Microsoft's recommendations and forced to explain the situation.
Ugh, our AD domain at work isn't even that old but was set up by some local consulting company and of course they used .local.
It causes all sorts of grief when shared SMB drives won't resolve on linux, or you can't tell at first blush whether the DNS server is working properly or you just happen to have mDNS correctly resolving something for you on one machine (but not on another).
As far back as I can remember the domain creation wizard has yelled at you for using a non-delegated zone, .local was a stupid default they put into SBS and unfortunately it led them into a mess of saying “yes, this is OK” and “no, don’t do this” at the same time...
And on BSD/Linux (with avahi). And on Phones. Actually, I think ONLY windows does not use this, though the mDNS implementation (bonjour) for windows uses that too.
Right up until they can't. Better to use things that are guaranteed to work, not just things that work now by happenstance but are not guaranteed to continue working in the future.
One big usability issue with .test domains is that it doesn't work well with Chrome's address bar. If I type "my.test", it tries to do a Google search for it. "my.dev" on the other hand tries to connect to my local http service. This is a stupid problem to complain about, but typing out the full "http://my.test" every time just becomes annoying.
The annoying part about using .test, .localhost, .invalid, etc. is that Chrome still treats "my-project.localhost" as a search instead of doing a DNS lookup. Need to add a trailing slash or specify the protocol, which honestly is just annoying enough that I'd rather risk collisions and use a TLD Chrome recognizes like .dev.
You're free to do whatever you want on your local network. If you have collisions with resources on the global Internet, however, and you local network is connected to the Internet, them you're setting yourself up for problems. Hence why it's a best practice to not do that.
Except for things like this issue, where you'd be affected when using Chrome or Firefox - even if your local network were completely disconnected from the internet.
Chrome and Firefox are primarily designed for use on the World Wide Web. If you're going to use a locally modified network you may need to use locally modified browsers as well, just as you'll need your locally configured DNS.
> If you're going to use a locally modified network
Except (correct me if I'm wrong), this is not a "modified network", it can be another disconnected network that's just as "correct" in the standard conformance aspect as the Internet. It's more like Chrome is "modified" to support one network better than others - or rather, to possibly break on other networks.
In fact, it seems to me like the very idea of HSTS preload list isn't friendly with UAs working on multiple separate networks.
But yeah, you're right that this is what they are designed for after all. (I'm also probably slightly biased, since some of our test environments use .dev domain in our LAN.)
Chrome is primarily an Internet browser though, not a random network browser. It wouldn't be a good idea to prioritize random network browsing at the expense of useful security features to secure browsing on the Internet.
There is no "DNS police" entity to force them, but just using a random domain will cause issues if that domain ever gets registered.
First, you will begin leaking internal data by means of DNS requests, server connections, maybe even internal emails - e.g. when a client attempts to connect to the intranet outside of VPN.
Second, you obviously won't be able to communicate with the new owners of that domain.
Chrome as a browser doesn't follow internal name assignments. Running in a sandbox won't fix the issue that Chrome will redirect perceived TLDs to HTTPS.
Rewriting/expanding the statement using my words, this is what they said: "I don't know why people (developers) thought they could start using random TLDs for local/testing purposes".
Yes, Google got the TLD and controls it now. The GP isn't criticizing Google (although I still think "we bought a TLD for internal use" is worth debating), they criticize people like the blog author for using 'random' (i.e. "not meant for that purpose") TLDs in their development process.
You shouldn't be locally rebinding domain names that exist on the global Internet. That is a recipe for disaster, as it makes your test suite and potentially even application logic dependent on your /etc/resolv.conf. It can cause spectacularly difficult-to-debug issues down the road as well as leaks of potentially confidential data (this is what ICANN's Controlled Interruption process was designed to mitigate). And you just can't expect other developers to have to change their DNS config just for tests to pass.
The best practice for at least the past decade has been to either use subdomains of globally resolving domains that you own, or use one of the four testing TLDs specified in RFC 2606 that are guaranteed to never be delegated: https://tools.ietf.org/html/rfc2606
> The best practice for at least the past decade has been to either use subdomains of globally resolving domains that you own, or use one of the four testing TLDs specified in RFC 2606 that are guaranteed to never be delegated: https://tools.ietf.org/html/rfc2606
Unfortunately, not one of those four is designed for the use case of "private domain, for use in production", which is pretty common for companies to use.
.test is for "testing of current or new DNS related code"
.example is for "documentation or examples"
.invalid is for "online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid"
.localhost is for the loopback (and using it otherwise breaks existing code)
Nothing prevents the first three from being used for this purpose, but at best it's semantically awkward and jarring. What sysadmin wants services running on an internal VPN to use the TLD ".test" or ".example"?
I provided the answer in my previous comment that you quoted: "use subdomains of globally resolving domains", or alternatively, just use global domain names, e.g. company.com for external services and companyprod.com for internal services. Google uses a combination of all of the above.
Domain names that only resolve internally are a security anti-pattern. You should have full authentication on all services, and not rely on simply being able to reach a service in order to grant access. See e.g. DNS rebinding as one attack vector that can really ruin your day if you don't do this.
There was a post a few days ago about a systemd resolv feature that resulted in (almost) permanently switching to the secondary DNS when the primary failed. The primary is an internal DNS resolving private domains. The secondary could be 8.8.8.8. It's easy to see what can go wrong if the private domain is somebody's else domain on the public internet. A kind of honeypot for any kind of web request.
Indeed. I wrote a Frequently Given Answer about it in 2003, years before systemd and years before the 2008 events mentioned elsewhere in this discussion. Because people were seeing exactly that.
I also wrote a Frequently Given Answer describing some more of the mistakes that people have made over and over in this, that one should learn from and not repeat.
I like the facts presented in your second link, but unfortunately the tone that it is written in means that it is unlikely to be received well by anyone it is linked to. Have you considered revising it?
What's so bad about service.company-internal.com? (or service.internal.company.com, but some people understandably prefer having them totally separated) You don't have to actually resolve the internal names publicly.
> What's so bad about service.company-internal.com? (or service.internal.company.com, but some people understandably prefer having them totally separated) You don't have to actually resolve the internal names publicly.
No, but you do actually have to reserve the public domain, which can be inconvenient or undesirable for all sorts of reasons.
> Not doing so is way worse though. You could be leaking all sorts of internal requests to a malicious attacker who does register that domain name.
It is, but again, it doesn't help that none of the reserved TLDs actually address the primary use case here for a lot of companies. We can both agree that the companies should be registering their private domains, but clearly most aren't, and there's no reason they shouldn't have a free, reserved-for-private use space that does address it.
I'd also say that, while having TLDs for testing usage is acceptable, there should never be any designed for production use as that would seemingly endorse the idea. The best practice (to use domains/subdomains that you own) should always be followed, and just because people do the wrong thing doesn't mean ICANN or the IETF should go out of their way to make the wrong thing easier to do.
DNS was always a system for fetching information from SRI's NIC official master database. It was never supposed to be itself a source of truth for everything related to a domain.
I don't know why people thought they could start using random TLD's on their own, there was always the risk they could be delegated officially.
https://www.iana.org/assignments/special-use-domain-names/sp...