There’re also variations to manage your Kubernetes clusters: https://www.youtube.com/watch?v=-koCol2anko

D-link and others register a domain name that resolves to 192.168.1.1 or equivalent. For the general user this is probably a big user experience win anyway.

If they register a single domain name, doesn’t it means the device on your local network has the private key for the corresponding certificate, which means it is compromised?

From a generic vendor POV, none of that is very reasonable.

1. Some places have no guaranteed Internet access. On some of them it is even prohibited (e.g. industrial applications) and considered a vulnerability.

2. The typical procurement/delivery/service subcontracting structure in large industrial projects (think oil rigs, power plants, mines, tunnels) makes maintaining your own DNS/CA ineffective and impractical. It requires getting everyone, from e.g. government subcontractors drafting requirements for the bidding round through foreign contractors hired 4 levels down in the bigcorp management hierarchy to actual device vendors to understand, implement and maintain this infrastructure. Typically it’s thousands of configurable devices sourced from dozens of vendors, with vastly different configuration/provisioning implementations - and most of them don’t have elaborate setup options like say Cisco IOS systems do. How do you provision your cert to an arbitrary vendor’s PLC or industrial endpoint switch? What if you have two thousands of them? The setup would take longer than configuring them in the first place, and further maintenance (these certs should expire, don’t they?) is a nightmare. So inevitably, solutions for these projects converge to lowest common denominator, which is more often than not is simple airgapped L3/L2 network split into a bunch of subnets and no trust chain whatsoever.