Do you know the IP addresses of your servers? You shouldn't know them. That reveals a lack of automation at a pretty low level of your infrastructure.

IP addresses change all the time in cloud environments and container orchestration systems. Even if they didn't change, you get better systems if you pretend they might. It doesn't matter if you use containers or not -- if you assume IP addresses could change at any time, you end up with infrastructure that is tied to your service graph rather than your hardware.

What about when the host is your domains dns server, and you need to ssh to it to fix a broken dns configuration. But because dns is broken the hostname you would use isn’t resolving anymore.

If a public domain, there needs to be NS records pointing at it from the registry, and they need to either have glue records giving the IP and/or at least one ought to be on a domain your name server itself is not the authoritative dns for.

If a private domain and/or the server is only reachable from private IPs, then its IP should be in an asset management system somewhere (it should be if it is public too); be that a full blown orchestration system, if cloud servers or containers, or some form of asset register - even if only a spreadsheet - if it is physical servers in your own data centers.

If properly automated, that asset register should drive configuration deployment - you shouldn't ssh to it to fix a broken dns configuration, you should run your deployment with a fixed config.

I get that this is an idealized setup and that a lot of the time things intervenes and it's quicker and easier to do things manually then and there. Been there, done that, but in the long run it pays to invest the time in then cleaning that up (up to and including wiping clean setups that have been manually updated to verify that the automated setups are correct and complete).

dude I'm not setting a DNS to access my NAS or my raspberry pi

If a computer's host name is "giggidy", then when it requests a DHCP lease, it sends that name to the DHCP server. If your DHCP server is hooked up to a mini DNS server, then the DNS server will resolve "giggidy" or "giggidy.whatever" to the IP it was assigned. This is how dnsmasq works, and a lot of consumer internet routers, too.

The router's IP and a nameserver IP are the only ones you should have to remember in the event of problems, and both of those can be short and simple.

I don't see anything in my network that responds to ping $hostname or ping $hostname.whatever

Then pick a memorable address, something like <prefix>::3 rather than <prefix>:ec47:87af:c904:98d7:de0b.

If you refuse to pick a memorable address and refuse to use the tool which is designed to let you handle unmemorable addresses, then you don't get to complain about how hard your addresses are to remember.

This. If you look at my domain name (no nasty things, please):

    $ drill AAAA mayeul.net
    ;; ANSWER SECTION:
    mayeul.net. 900 IN AAAA 2a01:cb14:cce:1200::11

This isn't really hard to remember: I have the same prefix on the other computers on that network. Then 2a01:c000::/19 is my ISP's prefix [1]. The only part I picked was the :11, which is similar to the local IPv4 address I use on the same machine (10.12.186.11). I don't know the prefix by heart, but then I also get the v4 one wrong. I can get back the prefix from a DNS query most of the time, though. And I could create dummy subdomains to remember more address prefixes, if ever needed.

If you need an IP address in multiple places on the same host, it would be better to use /etc/hosts anyways, or use a DNS server, as it makes changing configuration way easier.

I've been playing around with the idea of giving each of my services a dedicated IPv6, so that I can seamlessly switch them from one machine to another.

The very nice part is that I get more IP addresses than I will ever need. Probably. Unless I am into nanobots. I could take an IP address and reroute it over a tunnel, or even assign an address block the size of the whole IPv4 internet and make my server tunnel that to the right target. Waste IP addresses ranges just to get a convenient prefix (::f00d:7ea ::f00d:cafe for the teapot & coffee machine, for instance, or ::1:???? for pro stuff and ::6666:??? for personal things. I don't know). There are so many possibilities, I'm barely scratching the surface.

Now, a couple minor complains I have:

- I don't have IPv6 at work

- My ISP doesn't have IPv6-enabled DNS

- My ISP-provided router sometimes reset IPv6 firewall rules, which is annoying.

[1]: https://www.ultratools.com/tools/ipv6InfoResult?ipAddress=2a...

> This isn't really hard to remember:

cmon, how many bits of information are there in your example vs remembering the last three digits of 192.168.1.xxx.

Like, ~4 bits? It's the last two digits in 2a01:cb14:cce:1200::xx.

Compare these two:

  2a01:cb14:cce:1200::xx
  203.0.113.42+192.168.1.xxx

Which is shorter? It's not the pair of v4 addresses.

where does this comparison come from ? currently I only have to know 192.168.1.xxx

If I were not to use a DNS, I would have to know by heart my IPv4 address (32 bits) to SSH on the router, then hop on the right host (32 bits local address). I guess you could shorten that to 32+8 if you were to use a super common prefix, but I tend not to do that to facilitate routing when bridging networks with a VPN, so it is more like +32 or +24 (10.x.x.x instead of 192.168.x.x).

The full address I wrote above is 72 to 80 bits, depending on how you count (if the ::11 counts as 8 or 16). So that's more, but not much. And The common part is always 32 bit more than the common ipv4 part.

An easier alternative to hoping on the router would be to assign a port to each computer behind the NAT. That makes 32bit for the IPv4, and 16 for the port. Contrast 64+16 in my IPv6 case (I actually have a /56, but that's no help for remembering it). 1 computer on the network means that you have to know 66% more bits with IPv6. Bump that to 10, and it's just 16%. This is because there is always a common part, and that common part is two times the length with IPv6, so that makes it a constant offset.

When configuring a network, I typically do not know the prefix by heart, so I make sure to have that written on a paper sheet that I take with me.

Plot twist: I do not know my IPv4 by heart. I actually know the IPv6 one better, as I have a dynamic IPv4 at home. And I intensively use DNS/mdns. IPv6 actually makes it easier to use DNS for local network machines, I think, as I feel it is more worth it to fill the DNS entries with it, in case I want to later open some ports in the firewall for the www to access.

It's the full addressing of the host... but you're right, I guess it was a bit of a non-sequitor. The only parts you have to actually know are the xx/xxx, which is roughly the same amount of bits. They could even both be, say, "42", so you're remembering the same thing for both.

Why not? I've been running internal DNS for almost 25 years. Setting up BIND, even in 1995, wasn't rocket science. If it's too complex, try dnsmasq.

but I don't want to run anything, just look on my modem's page (and have something simple enough that I won't need to look it up every time)

Almost every single web service in existence works or would work fine on a single server. We don't all need the cloud.

We are not going into the cloud for this reason.

We go into the cloud because the cloud provided you infrastructure as a service which is a huge benefit for small and big companies.