Hacker News new | ask | show | jobs
by zamadatix 1027 days ago
For those wondering what this is referring to it's the use of ".int" for the TLD of the examples. ".test" and ".example" are the only really good reserved TLDs for this (".local" isn't quite what people think it is).
3 comments

Example.com

People should just use example.com, it’s reserved and the most obvious to the end user that it’s for example purposes.

https://en.wikipedia.org/wiki/Example.com

Example.com is certainly acceptable as well but it does have a somewhat negative side effect of being an actual running, pinging, sometimes-service-responding host which means if people paste the documentation verbatim it may either actual execute or take longer than normal to timeout (ssh would fall into the latter). ".example" is reserved for the same purpose but does not have any registered domains, on top of being a few characters shorter for when you need more than 1 name in your documentation.
Doesn't work if you need to refer to more than one domain.

.example is also reserved for this exact purpose.

It does work when you use subdomains. And there’s also example.org and example.net.
> It does work when you use subdomains.

That's true but most people don't understand what subdomains are, so we're back to being (more) difficult for laypersons.

> And there’s also example.org and example.net

Well, that's a good point. There are options.

I think in the context of SSH, use of subdomains is very common and to be expected.

As far as laypersons are concerned, I would worry that they wouldn’t recognize foo.example to be a domain name, as opposed to www.example.com or blog.example.com.

I forgot we were talking about SSH :)

But in your example, you're comparing different structures. "www.foo.example" is somewhat more clear.

> ".local" isn't quite what people think it is

Whereas ".intranet", ".lan", and some others are what (some) people think ".local" is[1].

[1] https://www.rfc-editor.org/rfc/rfc6762#appendix-G

I am not sure what you are hinting at with your side comment about .local, but I came here to say that I pretty much love .local. Switched all my home machines to the systemd-resolved stub with enabled mDNS. Feels so much nicer then maintaining your own DNS or hosts files... Yes, there is some initial lookup delay, but thats totally fine for private use methinks.
>I am not sure what you are hinting at with your side comment about .local

They are probably referring to its special status and special handling.

https://en.wikipedia.org/wiki/.local

>The Internet Engineering Task Force (IETF) reserves the use of the domain name label .local as a special-use domain name for hostnames in local area networks that can be resolved via the Multicast DNS name resolution protocol.[2] Any DNS query for a name ending with the label local must be sent to the mDNS IPv4 link-local multicast address 224.0.0.251, or its IPv6 equivalent ff02::fb. A domain name ending in .local may be resolved concurrently via other mechanisms, for example, unicast DNS

Sadly it’s more complicated than that.

Back in the 1990s, Microsoft distributed a Netware-killer version of NT called Windows Small Business Server. It was aimed at companies that might at best have a dial-up internet service. SBS, being based on Active Directory and Exchange (etc usw) required a domain name, but back then you needed considerable arcane knowledge to register an Internet domain name, which most SBS users lacked.

So Microsoft recommended that their SBS users should pick a name under .local for their AD domain name. I will not relive the many hilarious fuckups this caused, especially when Exchange was trying to use POP3 for incoming email. [tedu’s comment upthread reminds me of an incident when I spotted a company that was clever enough not to use .local for their AD, but not clever enough to understand that corp.int is not an internal subdomain of corporation.com.]

(What MS should have done, instead of squatting on a name that might get created as a real TLD in the future, was tell their customers to make up a subdomain of a properly registered domain of MS’s own; if MS’s customers wanted to turn their fake domain name into a real internet presence, MS would have had a ready-made lever to turn their customers into subscribers. But that was 15ish years before MS realised Azure might be a good idea.)

OK, so part two of this story is the early years of Mac OS X when Apple needed a replacement for AppleTalk that worked with IP over Ethernet. The main gap that needed filling was zero-configuration service discovery, which AppleTalk had enjoyed forever and IP lacked. The solution was called Rendezvous or Bonjour (I forget which name replaced which) and multicast DNS was a foundational part of it. Apple did an incredibly effective job of getting other vendors (especially printer manufacturers) to adopt the new protocol.

HOWEVER, Apple needed to choose a domain name for mDNS so that names of devices on the LAN could be distinguished from names out on the internet. They chose .local because a LAN is a local area network.

Hence, hilarity ensued. So much confusion and failure to interoperate because two large corporations failed to appreciate the importance of a global shared namespace, and foolishly chose the same cute name to mean completely different things.

Possibly the saddest episode was when Apple were in the process of turning mDNS from a de facto standard (with multiple implementations across multiple vendors) into an IETF standard. MS tried to derail the effort by persuading the IETF to spin up a working group to develop LLMNR, link-local multicast name resolution, TOTALLY NOT mDNS HONESTLY. Surprising no one, there was zero interest in replacing a successful working deployed protocol with slightly differently shaped vapourware. Rough consensus and running code wins again.

The upshot of this is that the IETF has a lot of institutional trauma and scar tissue around the question of non-DNS domain names. (see also .onion and others)

I know at least one case of a Microsoft Consultant who suggested to use company.local for a new Exchange setup for roughly 5k employees. Unfortunately, his suggestion was actually implemented.
one thing i haven't been able to figure out with .local is that with multiple connections (wire to the lan, wifi to the internet, and vpn to the office network), the computer seemingly picks one of them at random for its .local address. i don't know how to fix that without setting each of them manually.
I switched to using .home.arpa[0] on my local network last year. Looked funny to my eyes at first, but it seems normal to me now.

[0] https://datatracker.ietf.org/doc/html/rfc8375

mDNS is the right way, the comment was directed towards the common mistake of thinking it's like .lan. or .home.arpa.