[tialaramex]

> Also had my old workplace on .dev until those bastards at Google stole it and added the entire tld to the hsts preload list!!

They didn't steal it. You'd hijacked it, and your hijacking failed. Go big or go home. The IETF hijacked the OID arc 1.3.6.1 and they succeeded because everybody accepted their control of that arc and it's now used everywhere, but if you hijack some namespace and then only use it on a few dozen machines nobody has heard of, that's not going to stick.

More seriously, what you've done is probably a bad idea. https://myprinter.lan/ seems unique to you, and then your new partner moves in, why doesn't the printer work? Oh right, his printer is also named myprinter.lan because you don't have globally unique namespaces.

This happens on a bigger scale at a business or other organisations of course, but it's annoying even in one household. Here's a metaphorical nickel kid, get yourself a domain in the public DNS hierarchy.

[cookiengineer]

Maybe it's time to ditch the printer you won't need for ecological reasons then?

Jokes aside, isn't this what .local and .localdomain are specified for?

Why not use nickname.local as your namespace?... it's probably unique enough at least on this planet.

Of course another way would be to register one gTLD for each person on the planet, which seems to be the trend as of late /s

[denkmoon]

Using .local conflicts with mdns

[jlgaddis]

> Using .local conflicts with mdns

It's completely acceptable to use .local. in such a manner, however.

The "conflict resolution" process is outlined in the RFC [0] and is, well, pretty simple:

> ... the computer (or its human user) MUST cease using the name, and SHOULD attempt to allocate a new unique name for use on that link.

You can even set up your own DNS servers to be authoritative for the ".local." domain (zone), if you really want to.

RFC6762 states that "any DNS query for a name ending with '.local.' MUST be sent to" 224.0.0.251 (or ff02::fb) -- but it also explicitly allows sending them to your regular ol' (unicast) DNS servers, too. It's up to you to figure out how to manage that, of course.

Now, that said... to avoid any potential issues, I'd only ever use .local for its intended purpose. There's just too much potential for "weirdness" to occur. Personally, however, I completely avoid any use of either (.local and Multicast DNS) regardless.

--

On a side note, ".localdomain" mentioned in the grandparent comment should actually be "localhost."

--

[0]: https://tools.ietf.org/html/rfc6762

[denkmoon]

Being the admin of my network, I control these things. I don't have a partner adding random devices without oversight.

I have plenty of public domains. .lan is short and easy, hence my preference for it.

Ideally there would be one or two private tlds codified just as there are private ip ranges (my hypothetical partner could also add random devices with conflicting IP, businesses have problems with conflicting IP/subnets often, these are just problems that need to be solved through proper organisation, so I fail to see why dns is somehow different).

[jlgaddis]

> Ideally there would be one or two private tlds codified just as there are private ip ranges ...

There are several, in fact.

RFC8375 [0] states:

> This document registers the domain 'home.arpa.' as a special-use domain name [RFC6761] [1] ... 'home.arpa.' is intended to be the correct domain for uses like the one described for '.home' in [RFC7788] [2]: local name service in residential homenets.

In addition to "home.arpa.", there are several other domain names listed in IANA's "Special-Use Domain Names" registry [3] that "users are free to use ... as they would any other domain names" -- even if they are technically intended/reserved for other uses.

For as long as I can remember, I've used a subdomain of one of my registered domain names for everything in my home network. That has the advantage of, if and/or when desired, allowing me to do some "fancy tricks" (involving some combintion of DNS, VPN, and/or reverse proxying) to make specific internal/private resources available from the Internet.

--

[0]: https://tools.ietf.org/html/rfc8375

[1]: https://tools.ietf.org/html/rfc6761

[2]: https://tools.ietf.org/html/rfc7788

[3]: https://www.iana.org/assignments/special-use-domain-names/sp...