4 ms·

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

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 6y ago
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.
- pc86 6y ago
  So what breaks if you use "*.[lastname].local" for your home network?
  - vetinari 6y ago
    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 6y ago
      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.
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
- CSSer 6y ago
  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.

vetinari 6y ago

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.

pc86 6y ago
So what breaks if you use "*.[lastname].local" for your home network?
- vetinari 6y ago
  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 6y ago
    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.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
CSSer 6y ago
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.