I have servers named like server.prod.example.com, and I regularly log into them as server.prod. Recently, these hostnames started resolving to

It turns out that ICANN recently enabled the .prod TLD. In addition, every request that goes to the .prod nameservers get resolved to instead of coming back as NXDOMAIN, which would allow resolution to continue to work properly. (I'm guessing the point behind this is to let people know that their stuff will break worse before those start resolving to something real.)

How can I avoid having to type in my domain name for every host like this?

Is this still biting you occasionally? I couldn't find a list of new TLDs and when they were added, so I set one up myself: https://twitter.com/newgtldannounce

  • 6
    This change by ICANN also serves as a good reminder that letting your applications use search paths is bad. While this question definitely has merit for when a user's input results in this behavior, it's best to have your applications use host file entries or dot suffixed FQDN's. Few realize that glibc won't move on to the next server until it has timed out on attempting every defined search suffix.
    – Andrew B
    Sep 5, 2014 at 21:19
  • 14
    May I just take a moment to remind everyone that .prod is a frakking stupid TLD. :( Sep 6, 2014 at 3:37
  • Your question answered the question I was going to ask, by saying "ICANN recently enabled the <whatever> TLD". Turns out I was using .haus for my LAN and started getting these :D Thanks for asking/answering :) Nov 19, 2014 at 18:08
  • 2
    @LightnessRacesinOrbit .prod is one of Google's many new TLDs. Blame them. May 8, 2015 at 23:51
  • @LightnessRacesinOrbit it may be stupid if you look at it that way, but at the same time it is in the same way not good to depend on search lists or use names not registered globally, as you will hit collisions. Aug 22, 2018 at 20:04

3 Answers 3


When you see internal domains suddenly resolve to you have a namecollision and ICANN is trying to tell you that you urgently need to fix your DNS configuration.
If it would return NXDOMAIN like you suggested, you are correct, it would continue to work - for now.

It would also leak your internally intended DNS query to outside parties.

Worse, in the future someone could register server.prod and cause you much more trouble.

See here for more information https://icann.org/namecollision or run:

$ dig -t TXT server.prod +short
"Your DNS configuration needs immediate attention see https://icann.org/namecollision"

As to how to resolve this: Depends on the use case, I probably would just add them to .ssh/config with the short names. Or start using the FQDNs really.

  • 6
    @MichaelHampton not really, I recommend chapter 5.3: Train users and system administrators in using FQDNs ;)
    – faker
    Sep 5, 2014 at 21:16
  • 3
    Yes, because I really want to, 20 times a day, type in ssh db.myreallylongdomainnamethatsomeassholefrommarketingpicked.com instead of ssh db.
    – wfaulk
    Sep 5, 2014 at 21:48
  • 3
    @wfaulk: Why would it be a "joke"? If you don't like excessive typing, why are you obsessively avoiding the best mechanism to allow interaction with a computer that avoids excessive typing? Some of you Unix nerds are just barmy. Sep 6, 2014 at 3:36
  • 4
    @Lightness Generally because we tend to gravitate toward bastion hosts. Our corporate overlords are less and less likely to let their workers run a Unix on their company issued devices as the years go by, and the man hours saved by having access to shell scripts from our point of access handily beats whatever a GUI has to offer. GUI and text consoles both have their share of bad habits associated with them. :P
    – Andrew B
    Sep 6, 2014 at 8:42
  • 4
    This is not the place to have a GUI vs CLI discussion. I proposed a solution, it may not be the best for everyone and that's all there is to say.
    – faker
    Sep 9, 2014 at 11:28

If you type in a hostname with no dots in it, DNS resolvers try to look up that hostname by first appending the configured search domains to it.

For most resolvers, if you use a hostname with at least one dot in it, the resolver first tries the hostname on its own, and falls back to appending the configured search domains.

Many resolvers have the ability to change their behavior so that they append the search domains for hostnames with dots. This is often through an option called "ndots" that tells the resolver how many dots the hostname must have before it tries to look up the hostname on its own first. In order to make server.prod work, add this line to your resolv.conf:

options ndots:2

If you want to also be able to resolve server.subzone.prod, you'll have to set the option to 3, etc.

If anyone knows how to make this work in MacOS X, please let me know; changing /etc/resolv.conf is documented not to work (and doesn't) and I can't figure out the right scutil incantations.

(Note: I'm hedging my bets here more than is probably warranted. I believe that the ndots option will work on 99% of (non-MacOSX) Unix systems.)

  • 1
    You're confusing the OS resolver library with BIND. /etc/resolv.conf is owned by the OS. :)
    – Andrew B
    Sep 5, 2014 at 20:26
  • Most, if not all, Unix OS resolvers are ripped straight from BIND's resolver libraries, if not outright using them directly. My point in calling out BIND is that it's possible that there's some OS out there that does use something different that won't respond to the "ndots" option.
    – wfaulk
    Sep 5, 2014 at 20:30
  • 2
    Such a statement is more likely to mislead people into thinking that the resolver implemented by the C standard library has a dependency on libraries provided by ISC. In the case of glibc, it most certainly does not.
    – Andrew B
    Sep 5, 2014 at 20:45
  • 1
    Fair enough. Fixed to try to incorporate that it may not work while not referencing BIND.
    – wfaulk
    Sep 5, 2014 at 20:59

Other answers gave you the technical solution for the problem. But noone replied to your:

I couldn't find a list of new TLDs and when they were added

So here it is.

You have various ways.

  1. Hit the IANA website at: https://www.iana.org/domains/root/db ; you will see the current list of delegated TLDs, that is the ones that resolve and are in the root zone. If you click any on them, at bottom you will get a date telling you when they appeared
  2. That exact same data is available over whois, for example in your case whois -h whois.iana.org prod | grep created will give you created: 2014-08-23
  3. There are various bots on Twitter/Mastodon that post when IANA content changes, see for example https://twitter.com/ianawhois or https://twitter.com/rootchanges
  4. The IANA data may be a little behind in update, so the canonical database for gTLDs, and to see at which stage they are (now it is a little moot since the 2012 ICANN round of introducing new gTLDs is mostly finished, but new rounds will arrive), is here: https://gtldresult.icann.org/application-result/applicationstatus ; you can search by TLD. All gTLDs are also mandated some specific starting period, so you will find data here: https://newgtlds.icann.org/en/program-status/sunrise-claims-periods you can export all data.
  5. You can also use ICANN data in JSON: https://www.icann.org/resources/registries/gtlds/v2/gtlds.json

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .