6 ms·

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.n

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?

tempestn 7y ago
Sounds like when you enter a name without a TLD, some aspect of Windows assumes you're looking for a .com.
- djsumdog 7y ago
  Not just Windows itself, but a lot of software and tooling. If I'm working on my website, I have an entry in my hosts file so battlepenguin goes to a local web server. But I have to type it in with the leading http:// http:// and end with a slash, or else Firefox might automatically add a .com to the end and suddenly it's going to my production/live site and not my local copy. 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.
  - t-writescode 7y ago
    Formerly in the industry. I remember when .dev came out and I was in shock that ICANN thought that would be a good idea. They should have known better. .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.
    - tialaramex 7y ago
      People are idiots. The first idiot thing you can expect is that they'll deny they are idiots and will insist that you shouldn't idiot-proof things. 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).
    - crooked-v 7y ago
      > I remember when .dev came out and I was in shock that ICANN thought that would be a good idea. 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.
      - t-writescode 7y ago
        The ones I'm thinking of are mostly for internal environments. 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?
        tialaramex 7y ago
        Two things: 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.
  - the8472 7y ago
    > or else Firefox might automatically add a .com to the end and suddenly it's going to my production/live site and not my local copy. browser.fixup.alternate.enabled = false alternatively: browser.fixup.dns_first_for_single_words = true
  - xvector 7y ago
    Could someone tell me in what world this sort of assumption could have ever made sense? Why in God’s name would you design a system that redirects your requests like that? Are the security implications not painfully, frustratingly obvious?
    - patrec 7y ago
      Imagine a world without search engines and omni bars. This newfangled world wide web thing comes along and looks like it might become popular, but it's totally new to most people, who happen to be 99% of your customers. If they type `cnn` in the bar, chances are they want to go to cnn.com, so you make it so and don't lose most of your market share. 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.
      - manquer 7y ago
        .dev is making a lot of money for example , it is not easy to argue that they/google lose money because others didn’t read the spec.
      - lowercased 7y ago
        > so you make it so and don't lose most of your market share. 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.
    - pizzapill 7y ago
      This is the doing of a company that gave us Internet Explorer 6 & Office Macros. 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 :)
- noizejoy 7y ago
  To the best of my recollection, before the address field ended up doing double duty for web searches, the defaulting to .com happened across several browsers (never thought it was just Windows, though). — So for a while, I ended up getting .com domains, even when I had and wanted country domains, and redirected the .com to the country specific domain.
acranox 7y ago
This gets covered in one of my favorite conference talks. "Defcon 21 - DNS May Be Hazardous to Your Health" https://www.youtube.com/watch?v=9Sgaq6OYLX8&t=900s https://www.youtube.com/watch?v=9Sgaq6OYLX8&t=900s (skip to 15:00 if you just want the answer to your question. but the rest of the talk is brilliant) 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.
- delusional 7y ago
  It's the same reason you can't navigate to a bunch of TLDs even though the owners have configured it to serve something.
- swiley 7y ago
  > when the computer 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.
  - snazz 7y ago
    I'm pretty sure both the Win32 libc and applications do this. Try typing "http://example" http://example" into Firefox. You'll get example.com.
    - phit_ 7y ago
      mh, can't reproduce on Windows 10 and Firefox 73 get a "Server not found" page as expected
      - wink 7y ago
        Win 10 and Firefox 72.0.2 here. New Private Window -> http://example http://example -> http://www.example.com/ http://www.example.com/
      - bscphil 7y ago
andrewaylett 7y ago
DNS Search Domains are the reason: they're a mechanism for resolving a hostname to a fully-qualified name. 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?

tempestn 7y ago

Sounds like when you enter a name without a TLD, some aspect of Windows assumes you're looking for a .com.

djsumdog 7y ago
Not just Windows itself, but a lot of software and tooling. If I'm working on my website, I have an entry in my hosts file so battlepenguin goes to a local web server. But I have to type it in with the leading http:// http:// and end with a slash, or else Firefox might automatically add a .com to the end and suddenly it's going to my production/live site and not my local copy. 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.
- t-writescode 7y ago
  Formerly in the industry. I remember when .dev came out and I was in shock that ICANN thought that would be a good idea. They should have known better. .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.
  - tialaramex 7y ago
    People are idiots. The first idiot thing you can expect is that they'll deny they are idiots and will insist that you shouldn't idiot-proof things. 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).
  - crooked-v 7y ago
    > I remember when .dev came out and I was in shock that ICANN thought that would be a good idea. 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.
    - t-writescode 7y ago
      The ones I'm thinking of are mostly for internal environments. 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?
      - tialaramex 7y ago
        Two things: 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.
- the8472 7y ago
  > or else Firefox might automatically add a .com to the end and suddenly it's going to my production/live site and not my local copy. browser.fixup.alternate.enabled = false alternatively: browser.fixup.dns_first_for_single_words = true
- xvector 7y ago
  Could someone tell me in what world this sort of assumption could have ever made sense? Why in God’s name would you design a system that redirects your requests like that? Are the security implications not painfully, frustratingly obvious?
  - patrec 7y ago
    Imagine a world without search engines and omni bars. This newfangled world wide web thing comes along and looks like it might become popular, but it's totally new to most people, who happen to be 99% of your customers. If they type `cnn` in the bar, chances are they want to go to cnn.com, so you make it so and don't lose most of your market share. 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.
    - manquer 7y ago
      .dev is making a lot of money for example , it is not easy to argue that they/google lose money because others didn’t read the spec.
    - lowercased 7y ago
      > so you make it so and don't lose most of your market share. 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.
  - pizzapill 7y ago
    This is the doing of a company that gave us Internet Explorer 6 & Office Macros. 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 :)
noizejoy 7y ago
To the best of my recollection, before the address field ended up doing double duty for web searches, the defaulting to .com happened across several browsers (never thought it was just Windows, though). — So for a while, I ended up getting .com domains, even when I had and wanted country domains, and redirected the .com to the country specific domain.

acranox 7y ago

This gets covered in one of my favorite conference talks. "Defcon 21 - DNS May Be Hazardous to Your Health" https://www.youtube.com/watch?v=9Sgaq6OYLX8&t=900s https://www.youtube.com/watch?v=9Sgaq6OYLX8&t=900s (skip to 15:00 if you just want the answer to your question. but the rest of the talk is brilliant) 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.

delusional 7y ago
It's the same reason you can't navigate to a bunch of TLDs even though the owners have configured it to serve something.
swiley 7y ago
> when the computer 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.
- snazz 7y ago
  I'm pretty sure both the Win32 libc and applications do this. Try typing "http://example" http://example" into Firefox. You'll get example.com.
  - phit_ 7y ago
    mh, can't reproduce on Windows 10 and Firefox 73 get a "Server not found" page as expected
    - wink 7y ago
      Win 10 and Firefox 72.0.2 here. New Private Window -> http://example http://example -> http://www.example.com/ http://www.example.com/
    - bscphil 7y ago

andrewaylett 7y ago

DNS Search Domains are the reason: they're a mechanism for resolving a hostname to a fully-qualified name. 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?