OK, so a bunch of years ago, Microsoft suggested that AD domains/hosts should end in ".corp".
But where does the .com part come in to the picture?
Does corp.net or corp.ninja have the same type of issue?
But where does the .com part come in to the picture?
Does corp.net or corp.ninja have the same type of issue?
But basically when the computer can't resolve ".corp" it assumes it isn't an FQDN and starts adding other stuff to try and get an FQDN that does resolve.
Meaning browsers? The answer there is stop doing stupid things with the URL. When I type “localhost” into Firefox I’m not expecting a google search.
If libc does that then that’s surprising and probably also wrong.
New Private Window -> http://example -> http://www.example.com/
Python 3.8.1 (tags/v3.8.1:1b293b6, Dec 18 2019, 23:11:46) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.gethostbyname("example")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
socket.gaierror: [Errno 11001] getaddrinfo failed
>>> socket.gethostbyname("example.com")
'93.184.216.34'We could go back to the days of manually typing "http://www.google.com/index.html" every single time instead of "google.com" but I don't think many would thank you.
Many companies I've worked for would (for example) have a search domain set for 'wherever.internal', so if you typed 'jira' then having failed to find the 'jira.' TLD, the local DNS resolver would then try to find 'jira.wherever.internal'. That way, you could correctly resolve hosts based on just their names and avoid extra typing.
The problem comes when machines move off the corporate network but keep their search domains. Now we're making public lookups, and the network infrastructure has no idea how to resolve the names you're looking for.
In an AD environment, the AD server is typically the DNS server and does know how to resolve the AD domain as a name. So the machine's lookup for 'corp' works. But move off the AD network and we're back to search domains. And apparently enough Windows machines have a '.com' in their search domains for there to be a lot of 'corp.com' lookups. Which cause the problems listed when they succeed.
If you put '.net' in your search domains then corp.net would have the same issue.
What I'm still not sure about is that I'd thought that you needed an _explicit_ search domain. Maybe there's enough AD servers set up to hand out '.com' as a literal search domain?
Some issues might have to do with the way DNS is resolved by the operating system (the Start > Run \\resource example in the article) and others by the way some applications (like web browsers) do fallbacks for unknown DNS records.
Tangential: I worked at one company that had lower environments end in .dev and they started running into issues when Google purchased (and now sells) .dev domains and one of their project dependencies was hosted in an open source project repo that ended in .dev .. it had fallen out of use at the company and they just trashed the hosted zone, but I imagine at other shops, there's still domain overlap in the wild.
.dev, .local, .home, .corp. I don’t know how many of those are tlds, as I’ve let all that knowledge leave me; but, there are some tlds that just should be permanently blocked from being real tlds.
The second is, since they're idiots, they'll hurt themselves on the things you didn't idiot proof.
The .int Top Level Domain has existed since the 1980s. Nevertheless plenty of people decided they'd use names ending in .int for "internal" stuff. Then they were astonished that this doesn't work as expected. We even had to smack CAs for issuing certificates for such "internal" names back when they were allowed to do that (today CAs trusted in the Web PKI are not allowed to issue for names that aren't part of the Internet DNS hierarchy with a narrow exception for the .onion pseudo TLD).
RFC 2606 had .test, .example, .invalid, and .localhost clearly established as the right TLDs to use in 1999. It's not ICANN's fault that random people then decided to use domains not in that list, even after being warned that those are the only TLDs guaranteed to never be used.
It's my understanding (could be very wrong) that ICANN did a survey of some sort to see what TLDS are currently being used by companies and was intending to not release TLDs that are in that list, for backwards compatibility, at least for some time.
And even if it isn't, ICANN should have known that some people weren't following the official rules, and should have adapted, to maintain compatibility. It's not that big of a list of TLDs they needed to avoid. Pragmatism is important, you know?
1. Stop having a parallel internal name hierarchy. This has always been a terrible idea, and effort to try to make it work less badly is unnecessary if you instead don't do it at all. IF you're EXA Metal Pole Europe and you own example.com then put the internal stuff in internal.example.com or whatever, don't put it in a "private" TLD named .example. If it's very important to you, you can use Split Horizon DNS to prevent outsiders looking up names in internal.example.com from your DNS servers.
2. Yes, measurements were made for potential TLDs and ICANN designated some potential TLDs as "High risk" and agreed not to try to delegate them (ie sell them). .corp and .home were on that list. Nevertheless you should not use these names.
browser.fixup.alternate.enabled = false
alternatively:
browser.fixup.dns_first_for_single_words = true
Why in God’s name would you design a system that redirects your requests like that? Are the security implications not painfully, frustratingly obvious?
Besides as far as painfully, frustratingly obvious security implications are concerned you have done much worse before for less end-user benefit like making your main word processing application the world's premier networked virus delivery platform.
lose it to whom though? other software that also doesn't behave the same way?
And, per earlier comments, this wasn't a browser thing - this is a lower level windows hostname resolver issue.
Microsoft prioritized user experience over security for the longest time of their existence and I think they had a little bit of success with it :)