[davestephens]

Few things to do:

- specify a LAN IP for your ingress controller so it doesn't change.

- Use ddwrt/dnsmasq to point *.k8s.myhomenetwork.local to said IP

Once that's configured, you just configure the ingress hostname on services as you would "normally".

[vetinari]

Also - do not use .local tld. It is a reserved one (RFC6762), for mDNS/Bonjour:

> This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6 addresses in the FE80::/10 prefix, which are link-local and meaningful only on the link where they originate.

Microsoft used to recommend .local TLD for AD deployment as a best practice, and nowadays there are companies stuck with this decision. Do not make the same mistake; unlike companies, you probably want your zeroconf stuff to work.

[CSSer]

Iirc, the last time I looked into this, .test is the recommended TLD to use because it’s reserved for non-production use I.e. it will never be bought or sold.

[pc86]

So what breaks if you use "*.[lastname].local" for your home network?

[vetinari]

On zeroconf aware systems, it is still expected to be resolved via multicast; service discovery works by looking up srv/ptr/txt records on __$service.__$protocol.$hostname.local.

How it will behave will depend on your specific stack. Zeroconf aware (Macs, iOS devices, Linux with Avahi - i.e. most modern distributions) one will use multicast, zeroconf unaware (Windows) will use your DNS resolver. Devices (printers, etc) are a toss of a coin.

[chupasaurus]

I'd like to note that a default behavior of Avahi in Debian/Ubuntu/RH/SUSE prevents resolving *.local via unicast DNS to avoid this collision.