Talk:.local
This is the talk page for discussing improvements to the .local article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||
|
Part of mDNS?
[edit]It would be more accurate to describe .local as part of multicast DNS. Bonjour is not a protocol per se, but an implementation of a set of protocols including mDNS. -Ahruman 08:35, 28 June 2006 (UTC)
Other local TLDs
[edit]".localhost or .test could be used as an alternative to .local." -- that sounds a bit vague. Somebody might create a TLD with that names sometime, right? What alternatives to .local would officially be sanctioned? Multi io (talk) 20:10, 10 June 2009 (UTC)
- I removed this advice from the article, since WP is not a place to give technical advice, only document. But vague it was not really, the suggested domains are officially reserved, which is stated in those articles, I believe. There are no officially sanctioned names for local networking, it's up to you to maintain your network and assure reachability of public domains for your users without conflict. Kbrose (talk) 20:48, 10 June 2009 (UTC)
- As you said there are no official TLDs for local networks (the way RFC1918 IP address ranges are used for local private networks). The ICANN has badly dropped the ball on this. There's clearly plenty of demand for a local net TLD. There have been proposals/requests for TLDs to be reserved for such use, but we just keep getting technically useless "Yet Another DotCom TLDs". Anon_person 04:06, 21 January 2010 (UTC) —Preceding unsigned comment added by 211.24.230.50 (talk)
- Hell yes, I know several people who used .local as the modern variation of .uucp. Then some shithead from Apple who didn't have an ounce of imagination came along and now half the devices get themselves messed up because of it. This time around I want one that's officially sanctioned but there isn't one. The closest I can get is to use a user assigned country code 90.195.73.153 (talk) 16:19, 15 August 2010 (UTC)
- Well, perhaps local should have been reserved initially, like localhost and test, but how is anyone going to get consensus today which domain name is appropriate to be reserved. At the time there was good reason to reserve the existing ones, when no one could foresee the success of the Internet. Frankly, this is a non-issue, in private you are free to create any domain name you want, and the zillions of networks that do so don't seem to have a problem finding a fitting name. In addition, anyone can register an official domain cheaply in any of the existing TLDs. Where is the problem here? Comparing this to the reserved IP addresses is an invalid comparison, it is a completely different issue. Private IP addresses are an integral part of the addressing infrastructure, much unlike domain names. Kbrose (talk) 18:47, 15 August 2010 (UTC)
- Er? What?
- Domain names and IP addresses are exactly the same at the most primitive view. They are both organised systems for labelling machines, the endpoints of an IP connection. IP addresses are very much physical addresses; domain names are human addresses. There could easily be one system for both sorts of addresses but separating the two levels has lots advantages.
- The reason that local private IP addresses were specifically assigned wasn't because they are useful, all the reasons you give against a local private domain addresses also applied to IP addresses. The reason that RFC1597 was written was pragmatic. People were already assigning random addresses to internal hosts that never needed to connect directly to the internet because of any of a multitude of reasons. The problem was that these addresses were leaking and causing issues on the internet itself because there was a good chance that they were already in use by someone else. The same problem doesn't happen with domain names because the available address space in the TLD is almost unused; there are only a couple of hundred TLDs and most of those are two letter. So collisions never occur or are completely predictable ... until that guy at Apple. Here I was happily doing exactly what you suggested, I even looked up the domain that other people used so there wouldn't be any unexpected troubles down the line.
- So because it wasn't officially reserved the guy at Apple decided to use the obvious private DNS domain that was being used for a private DNS namespace in a IETF working draft and by all of Microsoft's documentation in Apple's non-DNS protocol. And here I though that because the 800lb gorilla was sitting on it everybody else would be smart enough to avoid it. What fun!
- So it now appears that a ".local" DNS domain is required for exactly the same reason that the IP address ranges were needed ... Some idiots are just too stupid to do it right and need to be persuaded with a stick.
- How, easy, the IETF makes the working draft into a full RFC. My preference would be "without changes". I don't suppose it'll happen, maybe I'll just use xD 90.195.73.153 (talk) 08:36, 15 September 2010 (UTC)
- I can only agree with this.
- We call this "hijacking". And now in Linux the systemd people are pushing for this and have already succeeded in rendering .local domains unavailable because the nsswitch system blocks it on standard installs. This is pure one second configuration and it does not have to be this way. mDNS being queried after DNS might leak onto the internet but the entire system still keeps working. .local queries are only relevant in the context of a LAN, and every LAN has a router, and every router could easily block .local leakage, and most routers provide DNS proxying by default anyway, so could easily be set up (factory wise) to block this leakage as well. There is no valid reason why .local must get hijacked by an mDNS daemon/library. It is not our job to fix the internet. Add to that fact that mDNS has a timeout of about 4 seconds, whereas DNS is almost instant. So putting mDNS in front of DNS would make no sense either. As an "extra" it should never take first place.
- This article is written by a zeroconf supporter. Like the article on GiB vs GB, it avoids contradictory facts and does not mention issues/concerns about this zeroconf.
- For instance, what you write above, that .local was a draft for the IETF, is not even mentioned here. In this way perceptions are skewed and opinions are formed, history is rewritten. I mean this is not a neutral point of view article.
- The same way the Binary prefix article forgets to mention how vital powers of 2 are in the organisation of data structures, and that basically every data structure out there is organized around sizes like 4096 and so on. Does not mention it. Does mention that "In most other contexts, the industry uses the multipliers kilo, mega, giga, etc., in a manner consistent with their meaning in the International System of Units (SI), namely as powers of 1000." which is just a blantant lie.
- Which is again skewing the truth in order to push a certain agenda.
Fair use rationale for Image:Apple Bonjour Logo.png
[edit]Image:Apple Bonjour Logo.png is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in Wikipedia articles constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.
Please go to the image description page and edit it to include a fair use rationale.
If there is other other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images uploaded after 4 May, 2006, and lacking such an explanation will be deleted one week after they have been uploaded, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.BetacommandBot 19:51, 31 May 2007 (UTC)
External links modified
[edit]Hello fellow Wikipedians,
I have just modified 2 external links on .local. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
- Corrected formatting/usage for http://www.circleid.com/posts/20090618_most_popular_invalid_tlds_should_be_reserved/
- Added archive https://web.archive.org/web/20150909131011/https://www.dns.icann.org/lroot/stats.1.html to http://www.dns.icann.org/lroot/stats.1.html
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}
).
An editor has reviewed this edit and fixed any errors that were found.
- If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
- If you found an error with any archives or the URLs themselves, you can fix them with this tool.
Cheers.—InternetArchiveBot (Report bug) 04:04, 8 September 2016 (UTC)
External links modified
[edit]Hello fellow Wikipedians,
I have just modified one external link on .local. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
- Added archive https://web.archive.org/web/20150909131011/https://www.dns.icann.org/lroot/stats.1.html to http://www.dns.icann.org/lroot/stats.1.html
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}
).
This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}}
(last update: 5 June 2024).
- If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
- If you found an error with any archives or the URLs themselves, you can fix them with this tool.
Cheers.—InternetArchiveBot (Report bug) 02:49, 2 December 2016 (UTC)
Mention problems with Android
[edit]As I understand it, Android doesn't resolve foo.local host names as part of the standard look-up provided to apps so they don't work unless the app explicitly codes NSD, Network Service Discovery, calls. Given the number of people shown by Google to be struggling with this, it would be good if someone knowledgeable summarised the state of mDNS on Android. -- Ralph Corderoy (talk) 15:10, 23 July 2020 (UTC)
"Has since been designated" - has it?
[edit]Is it really accurate to say "However, local has since been designated for use in link-local networking by RFC 6762"? As of 2020-12, RFC 6762 is shown as a PROPOSED STANDARD. If it was never actually accepted/ratified, technically it hasn't designated anything. AdamW (talk) 17:32, 16 December 2020 (UTC)
should local link devices use DNS servers
[edit]The text says; "In this way .local requests are being prevented from leaking to the internet, but also block legitimate .local requests for configured DNS servers." I do not believe local devices should request addresses from DNS servers. Once they get an IP from a DHCP server and have joined a network then they can use DNS.
I agree.
[edit]There are no "legitimate" requests that I am aware of. The point is to keep traffic local.
.internal
[edit]perhaps there should be mentioned ".internal", proposed by ICANN on 2024-01-24, by W. Kumari from Google 2017-07-02 (and maybe by others), see