Blog by PQR

Onlangs was ik bij een klant om een ontwerp te maken voor een nieuw te bouwen Exchange 2010 omgeving. Klant was zelf al bezig met een ontwerp voor Active Directory en wilde als AD DNS naam klant.local gebruiken. Nu had een andere consultant dat gehoord en hij raadde mijn klant af om met .local te gaan werken, beter konden ze .int kiezen voor intern gebruik. Toen dit in onze meeting terloops ter sprake kwam heb ik aan klant uitgelegd dat .local naar mijn mening een betere optie is dan .int.

In dit artikel wil ik ingaan op de gegeven argumenten en hier een reactie op geven.

“Helaas is er geen duidelijk document wat dit verbiedt, maar in dit document staat dat local een gereserveerde naam is: http://support.microsoft.com/kb/909264”

In knowledge base artikel 909364 staat beschreven aan welke eisen namen van AD objecten en domeinnamen moeten voldoen. Bij “DNS Domain Names” staat vermeldt dat je de lijst met Reserved Names in acht dient te nemen, en op die lijst staat inderdaad het woord ‘local’. Dat betekent dat een DNS domain met de naam ‘local’ niet toegestaan is. Een DNS domain met deze naam echter noemen we een Single-lable domain en is niet wat mijn klant voor ogen heeft. De DNS domain name klant.local staat niet op de lijst met Reserved Names dus kan volgens KB909264 gewoon toegepast worden.

“Overigens, Mac clients gebruiken .local als suffic voor broadcast packets”

Volgens mij is dit wat te algemeen geformuleerd en komt het niet helemaal overeen met de feitelijke situatie. Dit probleem speelt alleen in Mac OS X 10.2 en 10.3 en heeft betrekking op de Bonjour service. Bonjour is een service om andere Mac clients te vinden zonder gebruik te maken van DNS, helaas beschouwt Bonjour alle lookups voor .local als Bonjour lookups en gebruikt standaard geen DNS om deze te resolven.

Wanneer je nu nog computers hebt met Mac OS X 10.2 of 10.3 dan kun je deze zo configureren dat zij .local wel zullen resolven via DNS. Apple beschrijft dit hier: http://support.apple.com/kb/HT2385?viewlocale=en_US en Microsoft in http://support.microsoft.com/kb/836413/en-us.

“Microsoft ondersteunt het wel, maar wil niet dat klanten later in problemen komen”

Het standpunt van Microsoft is dat ze niet wil dat klanten .local gebruiken? Dat herken ik niet. In het document “The Domain Name System name recommendations for Small Business Server 2000 and Windows Small Business Server 2003” beschrijft Microsoft een aantal best practices om DNS in te richten voor kleine en middelgrote omgevingen. Als één van de opties noemt men: “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.”

Een stukje verderop in dit artikel wordt aangegeven dat bovenstaande optie de voorkeur heeft, bij de argumenten daarvoor nog eens uitgelegd waarom .local wordt aanbevolen:

“Most Small Business Server customers should use the first method. The following list describes some of the advantages when you use a separate and private domain name for the local Small Business Server network:

• The management of the local namespace is controlled by the Small Business Server Server. When you use a private FQDN for local DNS name resolution, the DNS server becomes the start of authority for the local domain. This result means that a query to external DNS root servers is not required for local resource name resolution.
• The security may be increased for your DNS server by not enabling zone transfers by means of the zone transfer properties of the forward lookup zone. Because dynamic registration of internal hosts can occur with the DNS server, if you disable the zone transfers from external clients, you can limit the exposure of internal host names to 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. However, by using the Web Publishing rules in Internet Security and Acceleration (ISA) Server, internal Web sites can be hosted externally and viewed by using resolvable domain names. This hosting still requires a registered domain name as well as the appropriate public DNS records that resolve to the external IP address of Small Business Server. Refer to "Configuring Publishing" in ISA Server Help for more information about Web Publishing rules.”

Lees het volledige artikel hier: https://mvp.support.microsoft.com/default.aspx?scid=kb;en-us;296250

“Microsoft adviseert om .local niet te gebruiken”

Het zijn vooral kleinere en middelgrote omgevingen waarbij klant wel wat advies kan gebruiken over de keuze van een DNS naam, of waarin klant de impact van split-DNS moeilijk kan overzien. Wanneer je bijvoorbeeld Small Business Server 2003 op een server installeert dan wordt je met een wizard door de installatie geholpen. Eén van de stappen is het kiezen van den DNS en NetBIOS naam voor het domein. In de wizard wordt standaard .local achter de bedrijfsnaam gezet en wordt bovendien toegelicht waarom dit aan te bevelen is. Zie dit screenshot:

Voor Small Business Server 2008 geldt het zelfde, daar kan gebruiker in de wizard zelfs alleen de NetBIOS naam opgeven waarna SBS Setup automatisch het TLD .local toevoegt om de DNS naam te creëren.

“Dus als je de mogelijkheid hebt om .int te gebruiken zou ik voor die mogelijkheid kiezen.”

Het idee rondom de keuze van een interne DNS domain name voor je AD is dat je wilt voorkomen dat hij ook op internet geregistreerd kan worden. Het .local TLD wordt niet op internet uitgegeven en aangezien het daardoor een de facto standaard is geworden voor intern gebruik, is het zeer onwaarschijnlijk dat dit ooit zal veranderen.

Het TLD .int daarentegen is wel in gebruik op internet. Deze TLD is in 1988 in gebruik genomen en wordt uitgegeven aan internationale organisaties die bij verdrag zijn opgericht, zoals bijvoorbeeld de Europese Centrale Bank, Internationaal Atoom Agentschap en de Wereld Gezondheids Organisatie. Hoewel niet te verwachten, is het theoretisch mogelijk dat er een .int domein wordt uitgegeven wat conflicteert met een .int domein voor intern gebruik. Daarom adviseer ik juist om .int niet te gebruiken.

Ten slotte…

Zoals altijd zijn er ook hier meerdere wegen die naar Rome leiden. Zo kan klant ook een domeinnaam kiezen met een TLD die wel op internet bestaat, in geval van deze Belgische klant bijvoorbeeld klantnetwerk.be. Wanneer klant deze naam vervolgens ook op internet registreert dan is hij zeker dat dit geen problemen gaat geven.

Mijn advies aan klant is in ieder geval om .local te handhaven, met inachtneming van de mogelijke impact voor oudere Mac OS clients. Heb jij een andere mening? Laat het dan even horen in de comments.