I have to chime in here now and call the article what it is: wrong at least in regards to misinformation about ".local". > DNS clients may defer the resolution

I have to chime in here now and call the article what it is: wrong at least in regards to misinformation about ".local". > DNS clients may defer the resolution of .local spTLDs to the system’s mDNS resolvers instead of its DNS resolver. This is not true. First off: You can always misconfigure your DNS resolver, but usually they can be used in parallel. Multicast DNS usually is only used when your router is too stupid to manage the hostname; and if multicast DNS is active on every host, then it's a setting that fixes even that broken router. Also, "hostname.local" will never conflict with DNS based service discovery [1] of resolving a host via multicast DNS. And even if so, you can just use one of the other reserved multicast addresses and be done with it. As long as you don't use e.g. "._tcp." or "._udp." inside your hostname, you never have domain name conflicts. I think there's also a huge misconception about what DNS-based service discovery is. In DNS-SD, there are questions to a service identifier with a PTR inside, and the response contains A,AAAA,SRV and TXT entries to describe everything you need to know to make a connection to the correct host, ip, port and version of the service. Airprint, airplay, airscan and others additionally use their service name as a prefix in regards to the IANA-registered service names [2] so printers, scanners and other Multicast-DNS compatible hardware never conflicts with the existing network. /ragecomment Personally, I would actually embrace the use of .local, because it allows you to build a self-discovery service that is unrelated to DHCP and unrelated to ARP mechanisms, and works peer-to-peer; as long as the IPs are in the same NAT or, with IPv6/UDP6, have at least one discoverable scope. In DNS-SD, you literally just have to be able to reach other IPs, and you have a working handshake mechanism to discover other devices without having to know their hostnames, IPs, or anything. It's pretty amazing once you realize its network automation potential. Source: Me, building a web browser that uses peer-to-peer TLS encryption on "username._stealth._tcp.tholian.network" and "username._stealth._tcp.tholian.local" [3] [1] https://www.ietf.org/rfc/rfc6763.txt https://www.ietf.org/rfc/rfc6763.txt [2] http://dns-sd.org/ServiceTypes.html http://dns-sd.org/ServiceTypes.html [3] https://github.com/tholian-network/stealth https://github.com/tholian-network/stealth