> 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.
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.
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 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.
> 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.
>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:
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.
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.
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.
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].
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).
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.
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
> 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.
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.
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.
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.
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.
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.
.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.
$ 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.
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.
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.
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.)
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.
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.
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.