Is it bad practice to listen on 0.0.0.0? Why?

Question

Say I want to deploy a software that acts as a server and I want to avoid scenarios where interfaces are replaced, IP addresses are changed, etc.

The nature of the environment in which this software is deployed on is a bit dynamic, the computer may be taken to different networks.

I decide then to deploy it configuring the address 0.0.0.0 to bind to the service configured port and job done.

Will network administrators frown upon it? (I got the impression they would). If yes, why?

Hope this is not an opinion based question and there are facts to support answers.

Solution 1

I decide then to deploy it configuring the address 0.0.0.0 to bind to the service configured port and job done.

Will network administrators frown upon it?

It would be bad practice if it's not necessary.

For some networks it may be necessary. And you won't know. It's not your decision to make.

Give the network administrators the option on what IP to bind it on.

Added note to clarify

It's not for you to make the decision of what IP to bind onto and not give the network admin the option to change it (which is what it sounds like you're talking about). It's fine for you to offer a default.

Solution 2

Tradeoffs between (1) good support for dynamic network configuration, (2) security and firewall rule stability and (3) code complexity (e.g. when network configuration event handling is needed) have already been mentioned. I’d like to point out a completely different issue though:

Yes, listening on address 0.0.0.0 is bad practice. Because it explicitly limits the listening daemon to IPv4 for no good reason.

Depending on where the 0.0.0.0 “museum address” occurs (hardwired in code or set in configuration), it yields either broken software or at least broken server setups, unusable on IPv6-only networks and causing connection delays and other malfunction on dual-stack networks (due to the need for IPv4 fallback).

To listen on “all available IP addresses” (when needed and when appropriate), simply listen on ::, which really covers all IP addresses, common IPv6 as well as IPv4-mapped IPv6 for legacy IPv4 support (if needed).

In most cases, system libraries make dual-stack support the easiest and default option that works out-of-the-box, unless an explicit effort is made to prevent one of the IP versions from functioning (such as listening on 0.0.0.0).

As for getaddrinfo(), AI_V4MAPPED | AI_ALL will rerurn both address types in a unified (IPv6) format and one and the same (IPv6) socket type can be used for both of them. This is especially relevant for the client side.

As for socket() and related calls, a single IPv6 socket will serve both IPv6 and IPv4 (unless IPV6_V6ONLY is set, and it is not set by default). This is especially relevant for the server side.

A known limitation of default (i.e. dual-stack) IPv6 sockets is port space sharing between IPv6 and IPv4. Separate sockets are needed to listen on different ports for IPv6 and IPv4. However, in most common cases, IPv6 sockets listening on :: behave in a predictable, backward-compatible way.

Solution 3

That depends on what interfaces are available on the machine. If you only have one active interface at a time that is reachable from outside, it makes no difference.

If you have more active interfaces e.g. in the subnets 10.0.0.0/24 and 10.0.1.0/24 and you want only people from the 10.0.0.0/24 subnet to be able to connect, you have to either restart your service every time you get a new ip or bind to 0.0.0.0 and block traffic using a firewall.

One could argue that in the second case if you bind to 0.0.0.0 you introduce an extra point of possible failure(the firewall), but I would say the risk is negligible.

Comments

[Frank Thomas]

I don;t think there is an objective answer to the question, but I would not have any issue with it, provided that I had the option to bind to a specific interface if there were reason for me to do so. In the situation you describe, a less explicit binding is definitely in order.

[barlop]

Give the network administrators the option on what IP to bind it on.

[Frank Thomas]

can't say I agree. many core linux services bind to 0.0.0.0 by default, and it is absolutely, 100% the developer/packager's job to ensure that a valid and widely-accepted default is provided for all configuation settings, until such time as an admin chooses to override it (eg its not only the dev's decision to make, its their responsibility to make it).

[barlop]

@FrankThomas it's the dev's responsibility to decide on a default(it's impossible for it to be anybody elses), but it's not the dev's responsibility to decide without giving the network admin the option.

[johnildergleidisson]

@barlop Why would it be a bad practice if not necessary? Is it just based on the fact that one would allocate the port on all interfaces and not make it available for other potential services? I'd assume that having different services in same ports for different interfaces would possible lead to confusion (at least for me) later on for diagnosing problems.

[johnildergleidisson]

I appreciate the answer although I understand the technicality. The discussion I'm raising is as to why it would be a bad practice, generally?

[tastytea]

Oh, I understood it wrong, sorry. I agree to Frank Thomas and barlop on that matter.

[barlop]

@JoaoMilasch A reason for binding a server to the LAN even when there is a firewall that can restrict connections Is If the firewall wasn't doing the job of restricting access to the server, then those that shouldn't, could connect. So it's a second line of defense.

[barlop]

@JoaoMilasch and it's not to enable them to run different/more servers on the same port number but different interfaces, purely to save ports. There are so many port numbers 65535, that such a stunt would not be necessary and would be confusing to many and would no doubt thus be considered bad practice. If a system had lots of network cards and each was expected to be running a different server then running those different servers probably wouldn't be bad practice - it wouldn't be confusing if it was expected or documented.Though it might be a mad practice, if there's no reason for it!.