Subject: [mdnsext] .local vs msftdomain.local

From: Alf Watt <[email-masked]>
Date: Wed, 1 May 2013 20:14:37 +0000

Much to my personal and professional embarrassment our internal IT
department here uses 'machine.ourdomain.local' as a private unicast domain
name as recommended some time ago by microsoft[1]. In particular KB 296250
[2] makes the following suggestions regarding private domain names:

"Make the name a private domain name that is used for name resolution on
the internal Small Business Server network. This name is usually
configured with the first-level domain of .local. At the present time, the
.local domain name is not registered on the Internet."

"The natural separation of internal and external networks occurs because
of the use of a separate internal namespace. A client query generated from
the Internet for www.contoso.local does not return any valid domain
information because .local, at the present time, is not a registered
domain name."

"Name resolution problems that are created by using a publicly registered
domain name can be avoided by planning the private namespace around a
.local first-level domain so that, in this example, Contoso.com and
Contoso.local are both available to internal clients, but Contoso.com is
only available to external internet clients. "

Any suggestions from the group on how to combat this misconfiguration?
Particularly, how do we get MSFT to renounce their previous tech-notes and
update their suggested practices around this?

Thanks,
Alf

[1] http://en.wikipedia.org/wiki/.local#Microsoft_recommendations
[2] http://support.microsoft.com/kb/296250

---

From: David Farmer <[email-masked]>
Date: Thu, 02 May 2013 14:19:25 -0500

At least for Active Directory best practices Microsoft gives 
contradictory advice on the issue.  See;

http://technet.microsoft.com/en-us/library/bb727085.aspx

The problem is this leaves users having to decide which advice to 
believe.  I have no idea how to get Microsoft to clarify the issue.

-----

1. Identify your organization's DNS owner and determine what registered 
DNS names you have available on the network that will host Active Directory.

Keep in mind that the names available on this network may be distinct 
from the names that your company exposes on the Internet. For example, 
the name your organization uses on the Internet might be 
contosopharma.com and the name used on your internal corporate network 
might be contoso.com. In this case the name that you select is contoso.com
If you do not have a registered domain name, you should register a name 
with an Internet DNS registration authority.
Note: As a best practice use DNS names registered with an Internet 
authority in the Active Directory namespace. Only registered names are 
guaranteed to be globally unique. If another organization later 
registers the same DNS domain name, or if your organization merges with, 
acquires, or is acquired by other company that uses the same DNS names 
then the two infrastructures can never interact with one another.
Add a prefix that is not currently in use to the registered DNS name to 
create a new subordinate name. For example, if your DNS root name were 
contoso.com then you should create an Active Directory forest root 
domain name such as concorp.contoso.com, where the namespace 
concorp.contoso.com is not already in use on the network. This new 
branch of the namespace will be dedicated to Active Directory and 
Windows 2000 and can easily be integrated with the existing DNS 
implementation. The rules for selecting a prefix are listed in Table 9.

On 5/1/13 15:14 , Alf Watt wrote:
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
>

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================