Special-Use Domain 'home.arpa.' | Hacker News Reader

Special-Use Domain 'home.arpa.'

tools.ietf.org

107 pointsokket72 comments

Just in case you're wondering, as I was ...

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

> While the name was originally the acronym for the Advanced Research Projects Agency (ARPA), the funding organization in the United States that developed one of the precursors of the Internet (ARPANET), it now stands for Address and Routing Parameter Area.

That's a brilliant trick to depoliticise an essential part of the DNS.

In my town Waterloo Lutheran University became Wilfrid Laurier University. I thoroughly enjoy backronyms.

Not a backroynym, but King County, Washington retroactively changed which person named "King" is its namesake.

There was a school called "J. Edgar Hoover School", which changed so it was named after Herbert Hoover

http://articles.chicagotribune.com/1994-06-26/news/940626022...

Shame that that article puts "cross-dressing" on par with "wire-tapping, Constitution-stomping, blackmailing, bully". We've come a long way, and still have a long way to go.

In case this issue on pages 7-8 is overlooked:

Because 'home.arpa.' is not globally scoped and cannot be secured using DNSSEC based on the root domain's trust anchor, there is no way to tell, using a standard DNS query, in which homenet scope an answer belongs. Consequently, users may experience surprising results with such names when roaming to different homenets.

To prevent this from happening, it could be useful for the resolver on the host to securely differentiate between different homenets and between identical names on different homenets. However, a mechanism for doing this has not yet been standardized and doing so is out of scope for this document. It is expected that this will be explored in future work.

In case people wonder why .home was not picked. One of the many issues here is that the current policy for the root DNS zone is that all new delegations from the root zone have to support DNSSEC. So they have to have DS records.

Given that the IETF specifically needed to "home" zone to be unsigned, that would result in lengthy process to change the policy for the root zone. The root zone is managed by ICANN who implement the IANA function. And then operationally managed by Verisign.

In the end using something under .arpa, solved a lot of issues.

It is quite possible that the IETF could have allocated .home because it is currently unused. But that would still require solving the technical issues.

At the same time, as long as there is wide spread use of .home, ICANN cannot really allocate that as a new gTLD.

So it should be sort of safe to continue to use that. But "homenet" compliant routers should come with home.arpa preconfigured.

Why not just reserve .home permanently so that it won't be allocated and tell people to use it? Does that somehow result in more bogus traffic to root and other DNS servers?

Between the lines, I read that ICANN doesn't give a f- about home users. Home users are not on the ICANN board (they've never heard of ICANN), don't give presentations at conferences or write papers, don't talk shop over lunch with ICANN members ... home users are invisible and have no voice. 'So here's this kludge that requires zero effort from us, is probably a little confusing for you[0] - we hope you like it because we're not doing anything more.'

The question is then who should reserve it?

The IETF can ask for domain names for technical reasons, i.e. as part of internet standards.

ICANN can allocate domains as gTLDs but doesn't have mandate/policy to reserve names without using them. Effectively .home is reserved because there is too much use to safely allocate it.

Finally, IETF can recognise .home as a special domain that is used locally. But that didn't work out because an insecure delegation is needed for DNSSEC.

Purely formally, ICANN has 'at large' structures that represent the interests of users.

I still sometimes see .arpa in my server logs. I don't know if it's a spoof, or a misconfiguration, or just cruft, but it's there.

(I still miss Australia being .oz, instead of .au.)

in-addr.arpa is the reverse zone.

That's the legacy reverse zone, the state of the art reverse zone is ip6.arpa.

Incredibly, .gb lingers on:

    $ getent hosts hermes.dra.hmg.gb
    146.80.9.16     hermes.dra.hmg.gb

I think .su is still a thing, but not being assigned anymore.

I thought it was restarted. Lots of new .su domains. But maybe they stopped again, not sure.

It's possible: https://www.nic.ru/en/catalog/domains/su/

reverse DNS for everything in public IP space uses the in-addr.arpa extension.

https://www.google.com/search?client=ubuntu&channel=fs&q=rev...

TIL about .oz.

In other words, they got a lot of money and then they sold the .home tld.

I think it has more to do with this:

> There is an existing process for allocating names under '.arpa.' [RFC3172]. No such process is available for requesting a similar delegation in the root at the request of the IETF, which does not administer that zone.

Not the case.

> In response to the report, ICANN labeled the .home and .corp strings as "high risk" and proposed that neither of the strings be delegated until it could be proven that risk is low. These two strings are currently severely delayed and some community members guess they may never be delegated.

https://icannwiki.org/.home

I'm always surprised .internal never took off. x.home.arpa doesn't quite sound right for the office lan.

If the company owns a public domain name, it has an entire subtree of names that it controls and can use, employing split horizon DNS service, for the office LAN.

That’s because home.arpa isn’t intended for the office LAN - it’s for residential use.

So am I reading that right? A significant number of people are using .home and .corp as the TLD for their local or internal network domains, so ICANN decided to (possibly indefinitely) delay delegation of those TLDs?

Yes, for these particular suffixes the problem is considered insurmountably bad, they're basically poisonous.

For a while Microsoft was telling companies to use .corp internally, these days their advice warns against this, but good luck getting a huge company to change anything in less than a lifetime.

When I say these names are poisonous I mean that in two senses

1. A tremendous number of people can't resolve your name in this suffix. Many of them won't know why, and can't really be expected to "fix" the problem.

2. Name servers for these suffixes receive a tremendous amount of "bogus" traffic that leaked from people who used these names but didn't properly seal them off from the Internet. Serving this traffic costs money.

Now, we recently saw for 1.1.1.1 that something so badly abused as to be poisonous can be reclaimed anyway if the people using it go in with their eyes open. I'd liken this to the practice of marking low value areas known to have some unexploded munitions buried as unsafe for humans and letting people run sheep, goats or cattle on that land on the understanding that (1) under no circumstances are people to enter and (2) sometimes an animal will explode, that's too bad, but hey the land was rent-free and would otherwise be useless. But just selling off land with unexploded munitions for building a new housing estate is clearly negligent.

> Now, we recently saw for 1.1.1.1 that something so badly abused as to be poisonous can be reclaimed anyway if the people using it go in with their eyes open

I kinda missed that part of the story. ref?

In this blog post under the section Enter 1.1.1.1: https://blog.cloudflare.com/announcing-1111/

See also this short talk by Louis Poinsignon from a few days ago:

Internet Noise (Announcing 1.1.1.0/24) https://ripe76.ripe.net/archives/video/31/

I just setup a brand new LAN for a client and used ".corp" for the internal DNS TLD.

https://tools.ietf.org/id/draft-chapin-rfc2606bis-00.html

>Recommendation (2) of SAC 045 calls for the community to develop principles for "prohibiting the delegation of additional strings to those already identified in RFC2606 [RFC2606]." As the first step in that process, based on the data reported by SAC 045, this document adds to the list of names that may not be used for top-level domains the following labels:

>.local, .localdomain, .domain, .lan, .home, .host, .corp

Now it seems like those TLD may be sold in the future? 1&1 is even "pre-registering" those TLDs.

Presumably this client insisted upon this silly idea over your objections?

Because if this was _your_ idea then if I were the client I'd feel like I hired somebody who was totally incompetent when I find out this arbitrary name they picked for me is a dumpster fire.

You're quoting an _expired_ _draft_ document as if that's some sort of standard.

You should not have done that.

* http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html

Wow, I think I need a shower to wash off the arrogance that came from just reading that page. I'd agree in premise, but officially, not even ICANN owns them; they only manage them. You shouldn't use them because of plenty of reasons. But you're totally allowed to, sysadmins everywhere will just hate you.

Note that the document the parent cites is a draft standard that was due to expire in December 2011. Also, it recommends reserving .local, which subsequently was assigned to Multicast DNS.[0] I'm not a DNS expert, but I don't know if I'd count on it.

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

Back in 2000, there was an IETF Internet-Draft entitled DNS Top Level Domain For Private Networks[0] that recommended using .pri:

"A reserved top level domain name, '.pri', would allow a private domain name to be chosen safely with no risk of conflict with current or future registered domain names. A private DNS server is configured as authoritative for the '.pri' domain, and delegates the private subdomains as appropriate."

It sadly was never picked up[1].

Over the years, Microsoft has recommended and in some instances even forced[2] the use of .local, which they now advise against[3].

[0] http://tools.ietf.org/html/draft-coffeystrain-privatednstld-...

[1] https://datatracker.ietf.org/doc/draft-coffeystrain-privated...

[2] https://www.microsoftpressstore.com/articles/article.aspx?p=...

[3] http://technet.microsoft.com/en-us/library/cc738121%28WS.10%...

Though the interesting answer to why Microsoft now has to advise against .local is that RFC 6762 reserved it as a special-case for Multicast DNS (mDNS fka Bonjour and a bunch of other names).

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

.local actually has two conflicts.

* http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html

This is good for small stuff but most people should just register their own domain name.

It's so cheap now and such a benefit to have a publicly-accessible and publicly-reserved address. There's no need to make your DNS records publicly-accessible although it's often convenient and rarely a risk.

This is for residential networks - that is by definition small stuff. Registering a domain and running DNS is overkill for most residential networks, and well beyond the skill level and time commitment warranted for home use.

So, my home LAN does indeed use .home.

Is this going to fuck that up?

Nope. This merely specifies that home.arpa is reserved for uses such as yours. It would probably be a good idea to switch to using home.arpa in case .home is ever allocated in the future, though that doesn't seem likely right now.

You have been spied upon. Our bad, we will ignore legit citizens at home.arpa

No, this RFC is not going to fuck that up. But some other might. Hijacking random domains is not a great idea, especially when domains cost only few bucks.

Wait...are you suggesting going to a domain registrar when I want to give my printer a hostname?

Well... maybe. You would just register the domain once (maybe `mycoolawesomehome.net`), and then you have the authority to arbitrarily decide that your printer's hostname should be `thebestprinterever.mycoolawesomehome.net`.

But now you can just use `mycoolawesome.home.arpa` without registering it.

If you are the family IT bod you could register familyname.co.tld (.uk for me) or .org.uk or whatever. Then allocate each family branch their own subdomain. In the UK you are looking at around £20 per year for a .co.uk and not much more from say 1-2-3 for hosting/DNS.

Now you can get Lets Encrypt certs for routers and all sorts! Use a Dynamic DNS service if external IPs are not static.

My family may be a little unusual in that even my Dad's TV has a hostname, and so has my brother's cooker! I put in pfSense, multiple VLANs, Unifi APs and all the other good stuff. A fully meshed IPSEC VPN link up with split horizon DNS. pfSense has an ACME client and a full toybox of networking goodness. Each site config is mostly replicated to the others for backup. The office monitoring system (Icinga) has a few extra systems on it.

That lot took a couple of man days to set up. It looks after itself mostly now and just works. I've saved myself many, many hours of hassle by putting in the work ahead of time and specifying decent gear. Its probably not for everyone.

Your home network DNS can be authoritative for any domain / TLD.

You pretty much have four options:

* Use .home.arpa

* Use .test from RFC2606.

* Use mDNS, which basically every printer supports, and use .local.

* Get yourself a personal domain. I highly recommend it. All my internal stuff is under home.mydomain.tld.

You could use home.arpa or mshome.net.

I've seen .local and .lan DNS suffixes and assumed that they were specified in a standard somewhere. Perhaps not.

I don't think they're standard. The RFC references "Special-Use Domain Names" [1] which contains a list of special use domains.

I'm confused about ".local" though. It's reserved for Multicast DNS? [2]

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

[2]: https://tools.ietf.org/html/rfc6762#page-67

Multicast DNS is the special use.

.local has always been confusing

Resolving a .local domain name works like this.

  $ dig -p 5353 raspberrypi.local @224.0.0.251
   
  ; <<>> DiG 9.8.3-P1 <<>> -p 5353 raspberrypi.local @224.0.0.251
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21640
  ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
   
  ;; QUESTION SECTION:
  ;raspberrypi.local.		IN	A
   
  ;; ANSWER SECTION:
  raspberrypi.local.	10	IN	A	192.168.1.175

A DNS query packet is to the multicast address 224.0.0.251 and UDP port 5353. All devices on your network that are listening on that address will see the query (e.g. Linux systems with avahi-daemon or Macs running mDNSResponder). The device whose name is raspberryi will respond. RFC6762 should have all the details.

This is the best explanation of how mDNS works that I've ever seen. Thank you!

mDNS is cool and all, but I wish they would've picked a slightly-more-specific TLD. ".local" is the natural suffix for LANs, and making computers confused about whether they should resolve that via multicast or standard DNS techniques wasn't very nice. Something like ".mdns" or ".zeroconf" would've been a lot better.

mDNS is roughly the equivalent of going door-to-door in the LAN and asking anybody if they've heard of "Greg", so it I don't think it is that confusing that it gets .local, especially given the circumstances that lead to relying on mDNS in that most LANs don't have authoritative DNS servers.

It's not that the name doesn't make sense, it's just that it collides with a very common TLD for LANs. It shouldn't be squatting on a name humans want to use. Computers are unlikely to do the correct thing when you ping a .local on a network that uses that suffix, because they have to decide how to handle the potential name collision (which is still somewhat frequent, more than 15 years later).

It's the other way around, though? .local's usage on LANs prior to the RFC was squatting on a non-reserved TLD. The RFC finally reserved the TLD for an appropriate usage. The name applies equally to both usages, the usages can live side-by-side, and the RFC is even kind enough to support that (though as you point out frequently don't always work as expected), even though it didn't need to take into account backwards compatibility with "squatters".

.local is used ad-hoc by mDNS (Apple). Last time the issue of naming local-area devices came up on ##networking, the consensus was to purchase a domain name in order to name local network devices without interfering with global name resolution standards, which seems ridiculous.

I think you can use .localhost freely.

.localhost is the loopback IP on most resolvers, though.

"localhost" by itself is, but second-level domains (ex.: laptop.localhost) aren't, at least not anywhere I've tried it.

In a well-configured machine second-level domains for .localhost are also supposed to loopback, per the RFC.

(It's useful as a development tool as you can Virtual Host project1.localhost and project2.localhost to different in development sites if your OS and server support it, which tend to be in similar ways to how they generally support Virtual Hosts.)

RFC6761 says:

6.3. Domain Name Reservation Considerations for "localhost."

   The domain "localhost." and any names falling within ".localhost."
   are special in the following ways:

   1.  Users are free to use localhost names as they would any other
       domain names.  Users may assume that IPv4 and IPv6 address
       queries for localhost names will always resolve to the respective
       IP loopback address.

[...]

   3.  Name resolution APIs and libraries SHOULD recognize localhost
       names as special and SHOULD always return the IP loopback address
       for address queries and negative responses for all other query
       types.  Name resolution APIs SHOULD NOT send queries for
       localhost names to their configured caching DNS server(s).

And goes on to specify how resolvers, authoratitive DNS servers, registrars, etc. should behave.

This is implemented on my machine at least by systemd_resolved, see https://github.com/systemd/systemd/blob/master/src/resolve/r... which returns ::1/127.0.0.1 for any record for which which is_localhost is true (defined in https://github.com/systemd/systemd/blob/master/src/basic/hos...).

That's the Microsoft recommendation. I think they're suggesting to use either split-view DNS (i.e., have DNS respond with internal vs external results depending on the source address of the requestor) or use a subdomain for internal hosts (e.g., corp.example.com). I don't think they mean to just buy a public domain and only use it internally.

I hope ...

.lan is non-standard, likely fabricated by your router. .local is RFC6762.

.local is used by zeroconf/rendezvous/bonjour/whatever it is called today, and so its explicit use as a LAN TLD is discouraged. If you try to set it in pfSense, for example, it warns you not to.

Another wide-spread non-standarized TLD is .box. It is used by Fritz!Box home routers (https://en.wikipedia.org/wiki/Fritz!Box). They are shipped with a really good operating system and handle the resolution of .box very seamless, integrating all the names of registering DHCP devices (i.e. you can resolve your-iphone.box in your LAN). The TLD stems from the "pun" http://fritz.box.

That's a shame, I liked the previous .home

There's a good chance that .home will be reserved forever simply because it and a lot of other names have widespread internal use.

https://tools.ietf.org/id/draft-chapin-rfc2606bis-00.html

Reply on news.ycombinator.com