On Mar 18, 2011, at 2:42 AM, Vilius Šumskas wrote:
> Thursday, March 17, 2011, 11:35:54 PM, you wrote:
>> On Mar 17, 2011, at 5:15 PM, Clint W. Heideman wrote:
>>> I have ran several networks using .local on Microsoft AD and "NEVER" had an issue, and I'm not that lucky. Currently my DNS and OpenDirectory are running just fine, it turned out that it wasn't DNS it is an issue with a Home Directory setup. Thanks for the help.
>> Consider it good that your specific problem is resolved. Just be
>> aware there is a problem with using .local as a DNS domain, it is
>> not a valid DNS name for a start. And .local is used outside of DNS according to other RFCs.
> Oh here we go again. Which RFC is that Dan?
.local is used for RFC3224, RFC2608, RFC2782, RFC3927, and RFC4862 by zeroconfig/bonjour/avahi/zcip/dhcpd for link-local addresses and for mDNS and that's used by Mac OS X, *BSD, Linux, Solaris, Windows, VMS, and most modern or Internet savvy OSen. It's implemented by numerous hardware vendors as well such as Roku, TiVo, Samsung, HP, Novell and Sun/Oracle and as part of just about every network printer vendor. It's used by DNS-SD as well and under Windows is implemented as SSDP. Its supported in CUPS as well. It's also found used in the ACN set of protocols.
.local is very explicitly covered in its IETF Draft, which is the same as an RFC. It's been in force since 13th July 2001 and the latest may be found at http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-14
> Multicast DNS Names
> This document specifies that the DNS top-level domain ".local."
> is a special domain with special semantics, namely that any fully-
> qualified name ending in ".local." is link-local, and names within
> this domain are meaningful only on the link where they originate.
> This is analogous to IPv4 addresses in the 169.254/16 prefix, which
> are link-local and meaningful only on the link where they originate.
> Any DNS query for a name ending with ".local." MUST be sent to the
> mDNS multicast address (220.127.116.11 or its IPv6 equivalent FF02::FB).
> The design rationale for using a fixed multicast address instead of
> selecting from a range of multicast addresses using a hash function
> is discussed in Appendix B.
If you've got printers on your network (wifi or wired) you probably already have .local being used on your network as well. So using .local will lead to name space collision if you have network printers and are useing .local as a DNS domain.
Using .local for DNS causes excessive DNS polution traffic on the global DNS system, and at the top level root servers it's seen as the third largest requested root for resolution - despite the fact that this isn't a valid GTLD and there should be no root queries for it. This suggests that there are lot of stupid sysadmins out there and a lot of those "using it for test" that don't have good control of their DNS. Look at
The root servers are seeing more than 1000 requests/sec, an that's a lot considering that they could have would have should have gotten filtered/resolved before that and that the requests are only forwarded DNS requests, implying that there are many, many, many requests downstream before the roots are hit. This indicates a huge problem with people using .local as a DNS zone when and as they shouldn't.
.local is likely to become a valid domain, valid in the sense that it will be valid like .example, in this case part of a list of popularly invalid domains ( .local, .belkin, .home, .lan, .invalid .domain, .localdomain, .wpad, .corp, .maps, .html, .router, .host, .mshome, .htm ), so that they may be rejected outright if seen in the while.
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden