Since the advent of systemd (and I have no idea why systemd has any involvement in this), Ethernet interfaces have, instead of names like eth0, new, weird names like enp0s3.

I think why systemd comes into this is that about the time Network Management because a systemd-managed service, it also began to use the new naming. So, /etc/network/interfaces has nothing to do with systemd, but it is Network Manager's configuration which is relevant when systectl is used to start, stop or restart networking.

NetworkManager stores configuration in /etc/network/interfaces and/or subdirectories if-down.d, if-post-down.d, if-pre-up.d, if-up.d and interfaces.d. I've had trouble getting what I put in the subdirectories to have an influence, but I think it's because I wasn't doing things right on the outside yet when I tried them. In any case, you must annotate /etc/network/interfaces with:

source-directory /etc/network/interfaces.d

or

source /etc/network/interfaces.d/*

...etc. to get subdirectory content brought up into the equation. In some earlier versions, source-directory doesn't seem to work.

Where is stuff stored?

Boot-up configuration for network interfaces, no matter how managed, is stored in /etc/network/interfaces (modernly, at least).

The DNS server list is stored in /etc/resolv.conf. That's another adventure in itself since there is also subdirectory fun since modern times surrounding that file. In some versions of Ubuntu/Mint, you'll get occasional complaints telling you that this "file" needs to be a symbolic link now to ../run/resolveconf/resolv.conf. (That equates to /run/resolvconf which is a different subdirectory from /etc/resolvconf. Go figure.)

Modern management of DHCP is done by dhclient. I know nothing about this yet.

The lastest and greatest...

The most modern network administration is not being done, starting with Ubuntu 18.04, by NetworkManager, but by something called Netplan which consumes YAML files on the path, /etc/netplan. This is the setting in which I first encountered this way of configuration.

Typically, Netplan YAML files are given names with a numeric prefix according to the format, nn-name.yaml, such that filenames with lower values of nn have their configuration applied earlier than others. You can create as many configuration files as you need. Here's a sample configuration; let's say it's in /etc/netplan/01-static-ip.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: no
      dhcp6: no
      addresses: [137.65.58.210/22]*
      gateway4: 137.65.59.254
      nameservers:
        addresses: [137.65.247.1,147.2.2.2,164.99.201.201]

^* For enhanced quad notation like xxx.xxx.xxx.xxx/nn, see Classless Inter-domain Routing (CIDR) elsewhere in these notes.)

It appears that Netplan already creates configuration for loopback, and you should not try to do it yourself (at least because unnecessary), /etc/netplan/00-loopback.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    lo:
      addresses: [127.0.0.1/32]

/etc/network # cat interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto enp0s3*
iface enp0s3 inet static
  address 137.65.58.211
  broadcast 137.65.58.255
  netmask 255.255.252.0
  gateway 137.65.59.254
  dns-nameservers 137.65.247.1,147.2.2.2,164.99.201.201

^* If you forget this line, as happened to me once upon a time, you'll experience not having this interface come back after reboot. You'll have to get it going by hand:

# ifip enp0s3

...which makes Network Manager check /etc/network/interfaces for details on how to bring it up.

After modifying this file, I can bounce networking for my host and then inspect what my host claims as its network configuration:

/etc/network # systemctl restart networking
/etc/network # ifconfig
enp0s3    Link encap:Ethernet  HWaddr 08:00:27:cb:f4:2e
          inet addr:137.65.58.211  Bcast:137.65.58.255  Mask:255.255.252.0
          inet6 addr: fe80::a00:27ff:fecb:f42e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1451 errors:0 dropped:61 overruns:0 frame:0
          TX packets:137 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:157578 (157.5 KB)  TX bytes:32229 (32.2 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:366 errors:0 dropped:0 overruns:0 frame:0
          TX packets:366 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:18256 (18.2 KB)  TX bytes:18256 (18.2 KB)

This is a scheme or compact representation of an IP address and its routing prefix, using a slash and a decimal number to represent the number of significant bits for the subnet mask. Let's remember these subnet mask types:

1. 255.xxx.xxx.xxx Class A
2. 255.255.xxx.xxx Class B
3. 255.255.255.xxx Class C

In an address like

137.65.58.211/22

One is meant to understand a subnet mask of 255.255.252.0 which uses a total of 8+8+6+0 bits.

In 255.255.255.255, all of the bits (32 or 11111111 to make 255) are used. 11111100 uses only 22 bits, hence, an address matching xxx.xxx.252.0.

There's probably a better way of explaining this, but it's how I think of it.

/etc/resolv.conf is the configuration for a host's Domain Name System's resolver. It's created by the system administrator as well as abused by many old programs and nasty VPNs. It consists of lines like:

search example.com local.lan
nameserver aaa.bbb.ccc.ddd
nameserver mmm.nnn.ooo.ppp
nameserver www.xxx.yyy.zzz

Many systems insist that this file be defined thus:

~ # ll /etc/resolv.conf
lrwxrwxrwx 1 root root 29 Sep 18 13:43 /etc/resolv.conf -> ../run/resolvconf/resolv.conf

It seems like...

~ # chattr +i /etc/resolv.conf
chattr: Inappropriate ioctl for device while reading flags on resolv.conf

...would defend it against pernicious treatment, but this is not possible for several reasons:

1. chattr does not work on symbolic links.
2. /run is a tmpfs (RAM disk) filesystem and it doesn't support extended attributes; if you try this, you'll get the error you see above.
3. The point of a virtual, private network (VPN) is to recreate a world behind a firewall for protection. In that world, different ways of reaching the Internet, via different nameservers, may be the only ways out and the nameservers you usually have in resolv.conf aren't reachable from that world.

More modern implementations, besides using the symbolic link noted above, also preconize a system of subdirectories to /etc/resolvconf/:

• resolv.conf.d
• update.d
• update-libc.d

...that allow more permanent settings to be specified (that will not be smoked by old-assumption applications and VPNs). For example, you might create, in resolv.conf.d, a file, base, with the settings you want to remember. Don't put a search line in, however, as it will not be retained. The canonical files to put into this subdirectory are:

• head
• base
• tail

...and they behave somewhat differently as to what happens to their content. For example, comments in head appear to survive into resolv.conf, while comments in the other two do not. Lines in base should be included in resolv.conf even when no interface is configured in /etc/network/interfaces. What is true of all, however, is that their content is never (or never to be) overwritten by anyone except an editor jockey.

If nothing else, you'll have a place to go to see what you used to have and want to restore to /etc/resolv.conf if it's ever hopelessly messed up. To restore,

~ # resolvconf -u

Some consider it more correct to indicate DNS settings in /etc/network/interfaces using dns-nameservers than to use nameserver in resolv.conf since it accompanies the device interface by which the service is likely to be reached.

However, none of this is especially fool-proof in my experience.

In a Linux VM, say a VirtualBox VM in bridged mode, there can be some perniciousness experienced when the host computer is running a VPN.

This is new-ish. This is how you configure DHCP for the host. This mechanism consists of

~ # tree /etc/dhcp/
/etc/dhcp
  ├── debug
  ├── dhclient.conf
  ├── dhclient-enter-hooks.d
  │    └── (stuff)
  └── dhclient-exit-hooks.d
       └── (stuff)

More on dhclient elsewhere at another time.

Tricks

Editing /etc/network/interfaces doesn't prevent resolv.conf from being overwritten; it simply specifies the name servers that should be written. A dhclient solution can keep pernicious (?) applications and VPNs from mucking with the contents of resolv.conf.

Create a new file, nodnsupdate, at /etc/dhcp/dhclient-enter-hooks.d/ with the following contents:

#!/bin/sh
make_resolv_conf()
{
  :
}

Make the file executable:

~ # chmod +x /etc/dhcp/dhclient-enter-hooks.d/nodnsupdate

When dhclient runs, whether at boot or when ifdown -a ; sudo ifup -a is done manually, dhclient loads this script. This script overrides an internal function called make_resolv_conf() that would normally overwrite resolv.conf. Instead it does nothing.