Difference between short and long names. How Erlang resolves them?

I am curious how Erlang resolves short and long node names?
In particular:

  1. Is it possible to connect two nodes with short names that run on separate machines?
  2. Is it possible to connect two nodes with long names that run on the same machine?

What I read is that short names are resolved using /etc/hosts and long names using DNS :thinking:

  1. Yes
  2. Yes

Short names are, as long names, resolved by the system/OS resolver, per the default Erlang VM configuration.

The system resolver in general appends some domain to the short name and tries to resolve that. The traditional ‘domain’ and ‘search’ items in /etc/resolv.conf control this behaviour.

/etc/hosts is in general tried first, by the system resolver, traditionally configured in /etc/nsswitch.conf. Names there are not associated with any domain, they are used verbatim.


Assuming that my /etc/hosts is empty, both machines are in the local network and they use short names, they should be able to find each other and establish the connection using DNS that runs on my home router, am I right? And this should happen automatically.

In case of long names, I would have to somehow manually configure my DNS running on my home router to map IP to FQDN which I am passing when starting Erlang node.

1 Like

Probably not automatically…

The DNS server that runs on your home router must resolve host names on the home network, for machines on the home network. I do not know this to be standard behaviour for an off the shelf home router.

Client machines always ask the DNS server to resolve fully qualified host names. So if you can configure the DNS server on the home network to think it is authoritative for the top level domain ‘localdomain’, and make it aware of which name which IP address has (it has to cooperate with the DHCP server, or the Windows way; the client informs the DNS server (that must allow this) what name it has). Then configure all clients to use the default domain ‘localdomain’ (DHCP can inform the client) which should make them append .localdomain to short host names when resolving.

With that it should work. :wink:

Long names on a home network has got roughly the same problems.

We use the ancient NIS (YP) in the Erlang/OTP lab. NIS is a method that can be used in /etc/resolv.conf. NIS likes short host names.
But I cannot recommend using NIS on a home network. It is more or less dead.

I guess Zeroconf or Avahi (mDNS) could be solutions here, but I do not know enough about them. If you find one I would be curious to know…


I have successfully used IP addresses in node names, e. g., I have used

erl -name marks-laptop@

where the IP address is assigned by my home router. I have never had to spin up anything special to get this to work. I normally run this in environments where IP addresses are dynamically assigned (at work and at home) for my personal devices. This avoids the associated lookups.

In fact, I have been able to use short names, too. If my laptop has a name, say laptop, and I run erl -sname foo then the Erlang prompt gives the node name as foo@laptop. My phone likewise is bar@localhost. These two nodes can talk to each other without my doing anything special. Perhaps my home router is already doing something, but I did’t configure it. I’m running a chat application right now.


Short name might not work out of the box when connecting MacOS machine with Linux machine as Mac uses mDNS. Your Linux machine have to support it which is probably easy to setup


Interesting. I confess I know little to nothing about the various configurations and defaults involved, and I didn’t expect short names to work.

My home network is whatever Verizon FiOS folks set up (with 2 wireless routers for upstairs and downstairs).

Empirically, I can reach my vintage MacBook Pro (2013, macOS 11.6) from my Android Pixel 5 phone under Termux and vice versa, but my PixelBook running Linux/Crostini can’t talk to the others (with short names).

As I indicated, long names with explicit IP addresses works for all of them quite reliably

1 Like