
Special-Use Domain 'home.arpa.' - okket
https://tools.ietf.org/html/rfc8375
======
jawns
Just in case you're wondering, as I was ...

[https://en.wikipedia.org/wiki/.arpa](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.

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

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

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

~~~
empyrical
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...](http://articles.chicagotribune.com/1994-06-26/news/9406260229_1_pta-
honored-president)

~~~
gowld
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.

------
forapurpose
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._

~~~
phicoh
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.

~~~
forapurpose
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.'

~~~
phicoh
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.

------
reaperducer
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.)

~~~
adw
in-addr.arpa is the reverse zone.

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

------
staunch
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.

~~~
djrogers
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.

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

~~~
NSAID
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](https://icannwiki.org/.home)

~~~
nemothekid
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](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.

~~~
JdeBP
You should not have done that.

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

~~~
grayhatter
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.

------
LeoPanthera
So, my home LAN does indeed use .home.

Is this going to fuck that up?

~~~
organsnyder
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.

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

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

~~~
cpburns2009
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...](https://www.iana.org/assignments/special-use-domain-
names/special-use-domain-names.xhtml)

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

~~~
djsumdog
.local has always been confusing

~~~
sigjuice
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.

~~~
cookiecaper
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.

~~~
WorldMaker
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.

~~~
cookiecaper
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).

~~~
WorldMaker
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".

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

~~~
Spivak
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](https://tools.ietf.org/id/draft-chapin-rfc2606bis-00.html)

