In the early days of Active Directory, Microsoft’s de facto standard was to use the .local namespace for AD domains. “De facto” because I don’t think there was any specific documentation or formal statement saying this but all of their examples and labs used it so a lot of organizations setting up Active Directory did so also.
Not sure exactly when, although I’m sure that it’s been many (many) years, but they do now explicitly state not to use .local or any nonregistered domain name for that matter: see Active Directory Domain Naming Considerations (thanks to Rich Milburn for finding this page).
Today, I just found another reason not to use .local: The Apple Bonjour suite of services and supporting protocols use .local for their name resolution. Thus by default, if you try to access an endpoint registered with a .local name suffix on an OSX or iOS device, name resolution will fail. If you don’t know this, the outcome can be quite perplexing because you’ll be able to access the endpoint by its IP Address and nslookup will work properly but accessing the resource by its .local name will fail with a name resolution error. This behavior along with a fairly simple work-around (at least for OSX devices) is described in the Apple knowledge base article If you’re unable to resolve or bind to domains that end in .local.
So what does this have to do with System Center Configuration Manager (ConfigMgr)? Not much unless you are trying to manage your OSX systems using ConfigMgr which is how I stumbled into it. As a side note, if you truly want to manage OSX with ConfigMgr, then check out Parallels Mac Management for Microsoft SCCM; it puts the native OSX management in ConfigMgr to shame but integrates, looks, and acts as if it were built in.
[ms_panel title=”NSLOOKUP does not test client name resolution” title_color=”#f5f5f5″ border_color=”#00274c” title_background_color=”#00274c” border_radius=”2″ class=”” id=””]Note that nslookup does not test name resolution on a system. Using nslookup simply queries a DNS server directly and thus only proves that the name is properly registered in DNS. Client name resolution involves more than simply querying a DNS server. The best way to typically test client name resolution is with the good old and drop-dead simple ping command.[/ms_panel]
I use tst.lab in my virtual AD lab. Hope that one is okay.
Depends upon your definition of “OK”. For a lab, it should work fine assuming you’ve configured your DNS properly. Labs should always try to mimic production as much as possible though. Registering a real domain doesn’t cost much so I would highly recommend doing this, even for a lab.
If I recall correctly, in Windows Server 2000 using your internet domain name as your AD domain caused issues with internal DNS. I think you’d even get a warning if you tried to use a .com as the internal domain name. That’s why everyone started using .local. I use .local for my labs because it’s so prevalent in peoples production environments. I guess I’ll switch to .com after reading your post though.