37

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

It turns out that ICANN recently enabled the .prod TLD. In addition, every request that goes to the .prod nameservers get resolved to 127.0.53.53 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

wfaulk
  • 6,828
  • 7
  • 45
  • 75
  • 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 05 '14 at 21:19
  • 14
    May I just take a moment to remind everyone that `.prod` is a frakking _stupid_ TLD. :( – Lightness Races in Orbit Sep 06 '14 at 03:37
  • Your question answered the question I was going to ask, by saying "ICANN recently enabled the TLD". Turns out I was using .haus for my LAN and started getting these :D Thanks for asking/answering :) – Arno Teigseth Nov 19 '14 at 18:08
  • 2
    @LightnessRacesinOrbit .prod is one of Google's many new TLDs. Blame them. – Michael Hampton May 08 '15 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. – Patrick Mevzek Aug 22 '18 at 20:04

3 Answers3

38

When you see internal domains suddenly resolve to 127.0.53.53 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.

Giacomo1968
  • 3,522
  • 25
  • 38
faker
  • 17,326
  • 2
  • 60
  • 69
  • You missed the extensive [guide](https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf) that ICANN published on this problem and how to mitigate it? – Michael Hampton Sep 05 '14 at 21:13
  • 6
    @MichaelHampton not really, I recommend chapter 5.3: `Train users and system administrators in using FQDNs` ;) – faker Sep 05 '14 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 05 '14 at 21:48
  • 2
    @wfaulk Like I've said, depends on use case. `~/.ssh/config` entries work if it's only a handful of servers. – faker Sep 05 '14 at 21:57
  • @wfaulk, That's what they invented GUI for. Use a ssh client that can store your list of servers. – developerwjk Sep 05 '14 at 22:06
  • 2
    @developerwjk: I hope that's a joke – wfaulk Sep 05 '14 at 22:19
  • 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. – Lightness Races in Orbit Sep 06 '14 at 03: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 06 '14 at 08:42
  • 3
    @LightnessRacesinOrbit: because GUIs have no monopoly in storing a list of entries; because if you're going to have preconfigured entries, `~/.ssh/.config` was already suggested; and because the whole concept of pre-entering dozens to hundreds of servers is absurd on its face – wfaulk Sep 09 '14 at 04:34
  • @wfaulk It speaks volumes that you're backing your argument by invoking the config file, when your own prior expression of its unsuitability was what started this line of discussion. – Lightness Races in Orbit Sep 09 '14 at 11:17
  • 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 09 '14 at 11:28
14

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

wfaulk
  • 6,828
  • 7
  • 45
  • 75
  • 1
    You're confusing the OS resolver library with BIND. `/etc/resolv.conf` is owned by the OS. :) – Andrew B Sep 05 '14 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 05 '14 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](https://sourceware.org/git/?p=glibc.git;a=tree;f=resolv;h=3a9c217458a02455231929f253846175244b2881;hb=HEAD). – Andrew B Sep 05 '14 at 20:45
  • 1
    Fair enough. Fixed to try to incorporate that it may not work while not referencing BIND. – wfaulk Sep 05 '14 at 20:59
1

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
Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42