Millions of the Pentagon’s dormant IP addresses sprang to life on January 20

Re:Millions of the Pentagon’s dormant IP addresses sprang to... by XorNot on Saturday April 24, 2021 @07:49PM (#26929204)

The main reason (I've done this at a bank previously) is when you need to ensure you don't overlap with other internal IP (RFC1918 was represented everywhere and routeable internally) and when you're trying to dodge 99% of your engineer's default Docker configs to reduce support request load.

In that case there's never any chance it'll be needed by people using the public internet there, and never any chance it'll be used suddenly by a deployed internal service somewhere else from an outside vendor.

[ Parent | on HN ]

Re:Millions of the Pentagon’s dormant IP addresses sprang to... by trulyme on Sunday April 25, 2021 @03:23AM (#26930966)

Default Docker configs are atrocious. Most devs/devops don't even know that when it creates a network, it takes a /16 ip range out of 172.[17-31].0.0/16 or 192.168.[0-240].20/20 by default. It is just a matter of time before a restart makes it collide with an existing network range. It does skip networks defined on local interfaces at least, but this only means that devs don't learn about this landmine on their own machines, nuking production instead.

The default should reserve a single ip range and simply fail (with a nice message) if more are needed.

[ Parent | on HN ]