101–110 of 174 posts
What about .localhost? Asking for a friend.
That is actually another special-use domain name that is supposed to be resolved by the local stub resolver to 127.0.0.1 and ::1. It’s not suitable for use on your local network, however.
OpenWRT: *glances aside nervously*
> Do not use undelegated domain names like .lan, .home, .homenet, .network, nor should you make up your own domain name. ...why? My DNS server, my rules, no? Why should I feel obligated to follow ICANN? Obviously, I'll need to make changes if someone ever registers the domain with ICANN (and I want to access the ICANN version), but other than that...
I'm with ya. I use `.zz`. It's short, easy to type, and in order for that to be assigned out, we'd need an entirely new country to be created (one that decided the other bazillion free CCTLDs are not to their liking). And like you say, I only run into a problem if I decide I want to access things from said country. Would I do this in any professional setting? Absolutely not. For my own stuff at home? The risk is pret…
It's (probably not) optimal, but it works. It was pretty much the same approach i used with PiHole/AdGuard Home.
Edit: To allow multiple hostnames i use a wildcard certificate from LetsEncrypt, though once i'm connected through VPN it doesn't matter much as it will resolve the internal hostname just fine.
> Do not use undelegated domain names like .lan OpenWRT: *glances aside nervously*
What method are people using to configure this oin their own network? The router supplied by my ISP doesn't support using a custom DNS server like a pihole, unfortunately. I don't consider using /etc/hosts a longterm worthwhile solution. I'd love to find another useful way of setting this up.
I was lucky enough to ask my ISP to set their box to bridge mode and have my request granted, then attached my own router.
> 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
> Do not use undelegated domain names like .lan OpenWRT: *glances aside nervously*
.lan should be OK, it has no it’s own RFC, but it is a reserved domain nevertheless: https://datatracker.ietf.org/doc/html/rfc6762#appendix-G
> domains at all, but should network operators decide to do this, the
> following top-level domains have been used on private internal
> networks without the problems caused by trying to reuse ".local." for
> this purpose:
This is hardly ‘reserved’. It just describes existing practice without in any way designating it as safe, recommended or future-proof.