DNS-arkitektur i Windows Server

DNS är en hierarkisk distribuerad databas och en associerad uppsättning protokoll som definierar:

• En mekanism för att fråga och uppdatera databasen

• En mekanism för att replikera informationen i databasen mellan servrar

• Ett schema för databasen

DNS-värdnamn finns i en databas som kan distribueras mellan flera servrar, vilket minskar belastningen på en server och ger möjlighet att administrera det här namngivningssystemet per partition. DNS stöder hierarkiska namn och tillåter registrering av olika datatyper utöver värdnamn–to-IP adressmappning som används i HOSTS-filer. DNS-databasen distribueras så att den både kan skalas upp och skalas ut, vilket innebär att prestanda inte försämras när fler servrar läggs till.

Den ursprungliga DNS baserades på Request for Comment (RFC) 1035 (Domain Names–Implementation and Specification). Andra RFC-dokument beskriver DNS-säkerhet, implementering och administrativa frågor, vilka senare kompletterade de ursprungliga designspecifikationerna.

De RFC:er som används i Windows Server-operativsystemet är:

• Domännamn – begrepp och anläggningar RFC 1034
• Domännamn – implementering och specifikation RFC 1035
• DNS-tillägg som stöder IP-version 6 RFC 1886
• En mekanism för snabbmeddelande om zonändringar (DNS NOTIFY) RFC 1996
• Inkrementell zonöverföring i DNS RFC 1995
• Dynamiska uppdateringar i uppdatering av domännamnssystemet (DNS)RFC 2136
• Negativ cachelagring av DNS-frågor (DNS NCACHE) RFC 2308
• Resursposter för DNS-säkerhetstilläggen RFC 4034
• Protokolländringar för DNS-säkerhetstilläggen RFC 4035
• En DNS RR för att ange platsen för tjänster (DNS SRV) RFC 2052

DNS-domännamn

DNS implementeras som en hierarkisk och distribuerad databas som innehåller olika typer av data, inklusive värdnamn och domännamn. Namnen i en DNS-databas utgör en hierarkisk trädstruktur som kallas domännamnområdet. Domännamn består av enskilda etiketter avgränsade med punkter, till exempel: mydomain.contoso.com.

Ett fullständigt kvalificerat domännamn (FQDN) identifierar unikt värdens position i det hierarkiska DNS-trädet. FQDN anger en lista med namn avgränsade med punkter i sökvägen från den refererade värddatorn till roten. Följande bild visar ett exempel på ett DNS-träd med en värd som heter mydomain inom domänen contoso.com. FQDN för värden skulle vara mydomain.contoso.com.

Förstå DNS-domännamnområdet

DNS-domännamnområdet, som visas i föregående bild, baseras på begreppet träd med namngivna domäner. Varje nivå i trädet kan representera en gren eller ett löv. En gren är en nivå där mer än ett namn används för att identifiera en samling namngivna resurser. Ett löv representerar ett enda namn som används en gång på den nivån för att ange en specifik resurs.

DNS-domännamnshierarki

DNS-klienter och -servrar använder frågor som metod för att matcha namn i trädet med specifika typer av resursinformation. Den här informationen tillhandahålls av DNS-servrar i frågesvar till DNS-klienter som sedan extraherar informationen och skickar den till ett program som begär att matcha det efterfrågade namnet. I processen för att matcha ett namn fungerar DNS-servrar ofta som DNS-klienter och frågar andra servrar för att helt lösa ett frågat namn.

Contoso tilldelas till exempel auktoritet av Internet-rotservrarna för sin egen del av DNS-domänens namnträdsstruktur på Internet, det vill säga contoso.com. För att matcha ett namn utanför contoso.com namnområde måste Contoso DNS-servrar köra frågor mot andra DNS-servrar, till exempel rotservrarna.

Så här organiseras DNS-domännamnområdet

Dns-domännamn som används i trädet är tekniskt sett en domän. Men de flesta DNS-diskussioner identifierar namn på ett av fem sätt, baserat på nivån och hur ett namn används ofta. Dns-domännamnet som är registrerat på Contoso (contoso.com) kallas till exempel en domän på andra nivån. Namnet har två delar (kallas etiketter) som anger att det finns två nivåer under roten eller toppen av trädet. De flesta DNS-domännamn har två eller flera etiketter, som var och en anger en ny nivå i trädet. Punkter används i namn för att separera etiketter.

I följande tabell beskrivs de fem kategorierna av DNS-domännamn efter deras funktion i namnområdet, tillsammans med ett exempel på varje namntyp.

Namntyp	Beskrivning	Exempel
Rotdomän	Överst i trädet, som representerar en namnlös nivå; Det visas ibland som två tomma citattecken (""), som anger ett null-värde. När det används i ett DNS-domännamn anges det av en avslutande punkt (.) för att ange att namnet finns på rotnivån eller den högsta nivån i domänhierarkin. I det här fallet anses DNS-domännamnet vara fullständigt och pekar på en exakt plats i namnträdet. Namn som anges på det här sättet är FQDN. En enskild punkt (.) eller en period som används i slutet av ett namn, till exempel example.contoso.com.	En enskild punkt (.) eller en period som används i slutet av ett namn, till exempel example.contoso.com.
Toppnivådomän (TLD)	Ett namn som används för att ange ett land eller en region eller vilken typ av organisation som använder ett namn.	.com, som anger ett namn som är registrerat i ett företag för kommersiellt bruk på Internet.
Domän på andra nivån	Namn med variabel längd som registrerats till en individ eller organisation för användning på internet. Dessa namn baseras alltid på en lämplig toppnivådomän, beroende på vilken typ av organisation eller geografisk plats där ett namn används.	contoso.com. är det andra domännamnet som registrerats i Contoso av Internet DNS-domännamnsregistratorn.
Underdomän	Andra namn som en organisation kan skapa som härleds från det registrerade domännamnet på andra nivån. Underdomäner innehåller namn som lagts till för att utöka DNS-trädet med namn i en organisation och dela upp det i avdelningar eller geografiska platser.	example.contoso.com. är en underdomän som tilldelats av Contoso för användning i dokumentationsexempelnamn.
Värd- eller resursnamn	Namn som representerar ett löv i DNS-trädet med namn och identifierar en specifik resurs. Vanligtvis identifierar den vänstra etiketten för ett DNS-domännamn en specifik dator i nätverket. Om ett namn på den här nivån till exempel används i en värdresurspost (A) används det för att leta upp DATORNs IP-adress baserat på dess värdnamn.	host-a.example.contoso.com. Den första etiketten (host-a) är DNS-värdnamnet för en specifik dator i nätverket.

DNS- och Internetdomäner

Internetregistreringsmyndigheter hanterar domännamnssystemet. Registreringsmyndigheterna ansvarar för att underhålla toppnivådomäner som tilldelats per organisation och efter land/region. Dessa domännamn följer den internationella standarden för landskoder (ISO 3166). Det finns hundratals domännamn på den översta nivån som är tillgängliga för allmänheten. I följande tabell visas några vanliga TLD:er, samt tvåbokstavsförkortningar som används för länder och regioner.

DNS-domännamn	Typ av organisation
.Com	Kommersiella organisationer
.edu	Utbildningsinstitutioner
.Org	Ideella organisationer
.nät	Nätverk (internets stamnät)
.gov (på engelska)	Icke-militära statliga organisationer
.mil	Militära myndigheters organisationer
.Arpa	Omvänd DNS
.Xx	Landskoder med två bokstäver (till exempel .us, .au, .ca., .fr)

DNS-resursposter

DNS-resursposter innehåller den information som en zon har om de resurser (till exempel värdar) som zonen innehåller. En typisk resursuppteckning består av:

• Namn (värd) för resursrekordet.
• Information om hur länge resursposten kan finnas kvar i cacheminnet.
• Resursposttyp, till exempel en värdresurspost (A).
• Data som är specifika för posttypen, till exempel värdarnas IPv4-adress.

Du kan lägga till resursposter direkt, eller så kan de läggas till automatiskt när Windows-baserade DHCP-aktiverade klienter (Dynamic Host Configuration Protocol) ansluter till ett nätverk med dynamisk uppdatering.

Typer av resursposter

Vanliga resursrekord är:

Resursposttyp	Beskrivning
Värdposter (A, AAAA)	Mappar ett värdnamn till en IP-adress.
Aliasposter (CNAME)	Vidarebefordra ett aliasdomännamn eller underdomän till ett annat primärt eller kanoniskt namn. Resursposter för alias (CNAME) kallas också kanoniska resursposter för namn. Med dessa poster kan du använda mer än ett DNS-namn för att peka på en enda värd.
E-postutbytesposter (MX)	Anger namnet på en dator som utbyter eller vidarebefordrar e-post. E-postprogram använder MX-resursposten (mail exchanger) för att hitta en e-postserver baserat på ett DNS-domännamn i måladressen för e-postmottagaren av ett meddelande. Om det finns flera MX-resursposter (e-postväxlingsposter) försöker DNS-klienttjänsten kontakta e-postservrar i prioritetsordning, från lägst värde (högsta prioritet) till högst värde (lägsta prioritet).
Pekarregister (PTR)	Används av omvända DNS-sökningar för att mappa en IP-adress till domänen. Pekarresursposter (PTR) stöder omvänd sökning, baserat på zoner som är skapade och rotade i in-addr.arpa-domänen. Du måste ha rätt zon för omvänd sökning på DNS-servern för att skapa en PTR-post som mappar en IP-adress till ett specifikt värdnamn.
Tjänstplatsposter (SRV)	Anger värd, port och protokoll för en tjänst. Resursposter för tjänstplats (SRV) krävs när klienter använder DNS för att hitta platstjänster, till exempel Active Directory-domänkontrollanter.
Namnserverpost (NS)	Anger auktoritativa namnservrar för en domän.
Textpostering (TXT)	Aktiverar publicering av text i en DNS-post. Med textrader kan du lägga till textinformation som returneras vid förfrågningar mot DNS. TXT-poster används ofta för att autentisera ägarskapet för DNS-zoner.
Delegeringsnamn (DNAME)-post	Tillhandahåller ett alias för en domän, till exempel en CNAME-post, men innehåller alla underdomäner.
Start av myndighetspost (SOA)	Innehåller auktoritativ information om en DNS-zon. SOA-posten innehåller primär namnserver, kontakt med DNS-zonadministratör, uppdateringsinformation och annan information.

Time-to-Live för resursregister

TTL-värdet (Time-to-Live) i en resurspost anger en tidsperiod som används av andra DNS-servrar för att fastställa hur lång tid det tar att cachelagrar information för en post innan den upphör att gälla och tar bort den. Till exempel ärver de flesta resursposter som skapats av DNS Server-tjänsten den lägsta (standard) TTL på en timme från starten av resursposten för utfärdare (SOA), vilket förhindrar utökad cachelagring av andra DNS-servrar.

En DNS-klientlösare cachelagrar de svar som den tar emot när den löser DNS-frågor. Dessa cachelagrade svar kan sedan användas för att besvara senare frågor för samma information. Cachelagrade data har dock en begränsad livslängd som anges i TTL-parametern som returneras med svarsdata. TTL ser till att DNS-servern inte behåller information så länge att den blir inaktuell. TTL för cacheminnet kan anges på DNS-databasen (för varje enskild resurspost genom att ange TTL-fältet för posten och per zon via det minsta TTL-fältet för SOA-posten) och på DNS-klientlösarens sida genom att ange den maximala TTL som matcharen tillåter att resursposterna cachelagrar.

Det finns två konkurrerande faktorer att tänka på när du anger TTL. Den första är noggrannheten i den cachelagrade informationen, och den andra är användningen av DNS-servrarna och mängden nätverkstrafik. Om TTL är kort minskar sannolikheten för att ha gammal information avsevärt, men det ökar användningen av DNS-servrar och nätverkstrafik, eftersom DNS-klienten måste fråga DNS-servrar om utgångna data nästa gång den begärs. Om TTL är lång kan cachelagrade svar bli inaktuella, vilket innebär att matcharen kan ge falska svar på frågor. Samtidigt minskar en lång TTL användningen av DNS-servrar och minskar nätverkstrafiken eftersom DNS-klienten svarar på frågor med sina cachelagrade data.

Om en fråga besvaras med en post från cachen skickas även TTL för posten med svaret. På så sätt vet resolvers som får svaret hur länge posterna är giltiga. Upplösarna respekterar TTL från den svarande servern och återställer den inte baserat på sin egen TTL. Så poster upphör verkligen att gälla i stället för att existera i evighet när de flyttas från DNS-server till DNS-server med en uppdaterad TTL.

Noter

I allmänhet konfigurerar du aldrig TTL till noll. Skillnaden mellan en inställning på 0 eller 60 är minimal för postens noggrannhet, men när TTL är inställt på 0 påverkas DNS-serverns prestanda avsevärt eftersom DNS-servern ständigt frågar efter utgångna data.

Zoner och delegering

En DNS-databas kan partitioneras i flera zoner. En zon är en del av DNS-databasen som innehåller resursposterna med ägarnamnen som tillhör den sammanhängande delen av DNS-namnområdet. Zonfiler underhålls på DNS-servrar. En enskild DNS-server kan konfigureras som värd för noll, en eller flera zoner.

Varje zon är fäst vid ett specifikt domännamn som kallas zonens rotdomän. En zon innehåller information om alla namn som slutar med zonens rotdomännamn. En DNS-server anses auktoritativ för ett namn om den läser in zonen som innehåller det namnet. Den första posten i en zonfil är en SOA-resurspost (Start of Authority). SOA-resursposten identifierar en primär DNS-namnserver för zonen som den bästa informationskällan för data i den zonen. SOA fungerar också som en entitet som bearbetar uppdateringarna för zonen.

Ett namn i en zon kan också delegeras till en annan zon som finns på en annan DNS-server. Delegering är en process för att tilldela ansvaret för en del av ett DNS-namnområde till en DNS-server som ägs av en separat entitet. Den här separata entiteten kan vara en annan organisation, avdelning eller arbetsgrupp inom företaget. En sådan delegering representeras av NS-resursposten som anger den delegerade zonen och DNS-namnet på den server som är auktoritativ för den zonen. Delegering över flera zoner var en del av det ursprungliga designmålet för DNS.

Mer information om typer och replikering av DNS-zoner finns i DNS-zoner.

Orsaker till att delegera ett DNS-namnområde är:

• Ett behov av att delegera hantering av en DNS-domän till många organisationer eller avdelningar inom en organisation.

• Ett behov av att distribuera belastningen för att underhålla en stor DNS-databas mellan flera DNS-servrar för att förbättra prestanda för namnmatchning och skapa en DNS-feltolerant miljö.

• Behovet att möjliggöra en värds organisationstillhörighet genom att se till att värden inkluderas i lämpliga domäner. Namnserverns resursposter (NS) underlättar delegeringen genom att identifiera DNS-servrar för varje zon och NS-resursposterna visas i alla zoner. När en DNS-server behöver gå över en delegering för att lösa ett namn, refererar den till NS-resursposterna för DNS-servrar i målzonen.

Följande bild visar hur hanteringen av contoso.com domän delegeras mellan två zoner, contoso.com och mydomain.contoso.com.

Noter

Om det finns flera NS-poster för en delegerad zon som identifierar flera DNS-servrar som är tillgängliga för frågor kan Windows Server DNS Server-tjänsten välja närmaste DNS-server baserat på tur och returintervall som mäts över tid för varje DNS-server.

DNS-tjänstarkitektur

Följande diagram illustrerar DNS-klienttjänstarkitekturen i dess namnmatchning och uppdateringsåtgärder i Windows-klienten och Windows Server. Namnmatchningsarkitektur visas med hjälp av ett klientprogram och uppdateringar representeras av DHCP-klienten.

Följande diagram illustrerar DNS Server-tjänstarkitekturen med dess administrationsverktyg och WMI-gränssnittet (Windows Management Instrumentation) i Windows Server.

I följande avsnitt beskrivs DNS-frågeprocessen och hur DNS-uppdateringar hanteras.

DNS-frågor

DNS-frågor kan skickas från en DNS-klient (resolver) till en DNS-server eller mellan två DNS-servrar.

En DNS-fråga är bara en begäran om DNS-resursposter av en angiven resursposttyp med ett angivet DNS-namn. En DNS-fråga kan till exempel begära alla resursposter av typen A (värd) med ett angivet DNS-namn.

Det finns två typer av DNS-frågor som kan skickas till en DNS-server:

• Rekursiv: En rekursiv fråga tvingar en DNS-server att svara på en begäran med antingen ett fel eller ett lyckat svar. DNS-klienter (resolvers) gör vanligtvis rekursiva förfrågningar. Med en rekursiv fråga måste DNS-servern kontakta alla andra DNS-servrar som behövs för att lösa begäran. När den får ett lyckat svar från den andra DNS-servern (eller servrarna) skickar den sedan ett svar till DNS-klienten. Den rekursiva frågan är den typiska frågetyp som används av en matchare som kör frågor mot en DNS-server och av en DNS-server som kör frågor mot vidarebefordraren, vilket är en annan DNS-server som konfigurerats för att hantera begäranden som vidarebefordras till den.

  När en DNS-server bearbetar en rekursiv fråga och frågan inte kan matchas från lokala data (filer i den lokala zonen eller cacheminnet för tidigare frågor) måste den rekursiva frågan eskaleras till en ROT-DNS-server. Varje standardbaserad implementering av DNS innehåller en cache-fil (eller ledtrådar till rotservrar) som innehåller poster för rot-DNS-servrarna i Internet-domänerna. (Om DNS-servern har konfigurerats med en vidarebefordrare används vidarebefordraren innan en rotserver används.)

• Iterativ: En iterativ fråga är en fråga där DNS-servern förväntas svara med den bästa lokala information den har, baserat på vad DNS-servern vet från filer i den lokala zonen eller från cachelagring. Det här svaret kallas även för en hänvisning om DNS-servern inte är auktoritativ för namnet. Om en DNS-server inte har någon lokal information som kan besvara frågan skickar den helt enkelt ett negativt svar. En DNS-server gör den här typen av fråga när den försöker hitta namn utanför sin lokala domän (eller domäner) (när den inte har konfigurerats med en vidarebefordrare). Den kan behöva fråga till externa DNS-servrar i ett försök att lösa namnet.

Följande bild visar ett exempel på båda typerna av frågor.

Diagrammet visar hur flera frågor användes för att fastställa IP-adressen för www.contoso.com. Frågesekvensen beskrivs på följande sätt:

1. Rekursiv fråga för www.contoso.com (ett A-resursuppslag).

2. Iterativ fråga för www.contoso.com (en resurspost).

3. Hänvisning till .com namnserver (NS-resursposter för .com); För enkelhetens skull har iterativa A-frågor från DNS-servern för att matcha IP-adresserna för värdnamnen för namnservern som returneras av andra DNS-servrar utelämnats.

4. Iterativ fråga för www.contoso.com (en resurspost).

5. Hänvisning till contoso.com-namnserver (NS-resurspost för contoso.com).

6. Iterativ fråga för www.contoso.com (en resurspost).

7. Svar på den iterativa frågan från contoso.com-servern (IP-adress www.contoso.com).

8. Svar på den ursprungliga rekursiva frågan från den lokala DNS-servern till resolvern (www.contoso.com IP-adressen).

Uppdatera DNS

Resursposter ändras ofta när datorer, servrar och enheter läggs till eller tas bort från nätverket. Implementeringen av DNS i Windows Server stöder både statiska och dynamiska uppdateringar av DNS-databasen.

Resursposter kan läggas till i en befintlig zon med hjälp av kommandot Add-DNSServerResourceRecord PowerShell. Vissa vanliga resursposttyper har andra PowerShell-kommandon där du inte behöver ange resursposttypen. Du kan också lägga till resursposter med hjälp av DNS Manager-konsolen. Se Hantera DNS-resursposter för vägledning om hur du arbetar med resursposter, inklusive att skapa och ändra befintliga resursposter av alla typer.

Stöd för Unicode-tecken

När DNS introducerades som en del av RFC 1035 begränsades namnen till att använda versaler och gemener (A-Z, a-z), siffror (0–9) och bindestreck (-). Dessutom kan det första tecknet i DNS-namnet vara ett tal och namn måste kodas och representeras med hjälp av US-ASCII-baserade tecken. För användning av DNS i internationella inställningar skapar det här kravet betydande begränsningar där utökade teckenuppsättningar används för lokala namngivningsstandarder. Windows Server DNS-tjänsten ger förbättrat stöd utöver RFC 1035-specifikation, för UTF-8 tecken.

Vad är UTF-8?

UTF-8 är den rekommenderade teckenuppsättningen för protokoll som utvecklas utöver användningen av ASCII. UTF-8-protokollet ger stöd för utökade ASCII-tecken och översättning av UCS-2, en 16-bitars Unicode-teckenuppsättning som omfattar de flesta av världens skrivsystem. UTF-8 möjliggör ett mycket större namnintervall än vad som kan uppnås med hjälp av ASCII eller utökad ASCII-kodning för teckendata.

Datorer som kör Windows Server 2008 är UTF-8-medvetna. Det innebär att när UTF-8-kodade tecken tas emot eller används som data av servern kan servern läsa in och lagra dessa data i sina zoner. Även om Windows-baserade DNS-servrar är UTF-8-medvetna förblir de kompatibla med andra DNS-servrar som använder traditionell US-ASCII datakodning och aktuella DNS-standarder.

Så implementerar DNS-tjänsten UTF-8

För att tillhandahålla standardkompatibilitet och samverkan med andra DNS-implementeringar använder DNS-tjänsten en enhetlig neddelning av mottagna teckendata. I den här processen konverterar DNS-tjänsten alla versaler som används i standarddata US-ASCII till gemener som motsvarar av följande skäl:

• För att upprätthålla kompatibilitet med aktuella och befintliga DNS-standarder.
• För att tillhandahålla samverkan med DNS-serverimplementeringar som inte känner igen eller stöder UTF-8-kodning.

För att förstå varför enhetlig nedsättning valdes måste flera relaterade punkter först beaktas från de nuvarande reviderade Internetstandarderna för DNS. Flera viktiga punkter i standarderna gäller direkt för hur teckendata ska hanteras mellan DNS-servrar och andra servrar och klienter. Viktiga punkter är:

• Valfri binär sträng kan användas i ett DNS-namn. (RFC 2181)
• DNS-servrar måste kunna jämföra namn på ett skiftlägesokänsligt sätt. (RFC 1035)
• Det ursprungliga fallet för teckendata bör bevaras när det är möjligt när data anges i systemet. (RFC 1035)

Eftersom skiftlägesokänslighet är en nödvändig del av DNS-kärnstandarden och skiftlägesbevarande är en valfri rekommendation, valdes enhetlig nedskiftning för att tillhandahålla en effektiv standardkompatibel lösning. Genom att ta bort UTF-8-kodade namn före överföring kan andra DNS-servrar (som inte är UTF-8-medvetna) ta emot och utföra lyckade binära jämförelser av data och få önskat resultat.

Överväganden för samverkan med UTF-8

DNS Server-tjänsten kan ställas in för att tillåta eller blockera användningen av UTF-8-tecken för varje server. Vissa DNS-servrar som inte stöder UTF-8 kan acceptera zoner med UTF-8-namn, men kan ha problem med att spara eller läsa in dessa namn igen. Var försiktig när du överför zoner med UTF-8-namn till servrar som inte stöder UTF-8.

Vissa protokoll begränsar de tecken som tillåts i ett namn. Dessutom bör namn som är avsedda att vara globalt synliga (RFC 1958) innehålla ASCII-endast tecken, enligt rekommendationerna i RFC 1123.

Att använda UTF-8 för att transformera Unicode-tecken är osynligt för användarna. Du kan dock se UTF-8-kodade tecken om du använder Network Monitor eller ett liknande verktyg för att analysera DNS-trafik.

Förutom DNS-serverstöd för UTF-8-kodningsformatet använder klientlösaren standardformatet UTF-8-teckenkodning.

Namn som är kodade i UTF-8-format får inte överskrida de storleksgränser som anges i RFC 2181, som anger högst 63 oktetter per etikett och 255 oktetter per namn. Teckenantalet är inte tillräckligt för att fastställa storlek eftersom vissa UTF-8-tecken överskrider en oktett i längd.

UTF-8-kodningsprotokollet anpassas till användning med befintliga DNS-protokollimplementeringar som förväntar sig US-ASCII tecken eftersom representationen av US-ASCII tecken i UTF-8 är identisk, byte för byte, till den US-ASCII representationen. DNS-klient- eller serverimplementeringar som inte känner igen UTF-8-tecken kodar alltid namn i US-ASCII format. DNS Server-tjänsten kan tolka dessa namn korrekt.

DNS-tjänsten kan konfigurera namnkontroll för att tillåta eller begränsa användningen av UTF-8-tecken i DNS-data.

Som standard används namnkontroll i flerabyte UTF-8, vilket ger störst tolerans när DNS-tjänsten bearbetar tecken. Namnkontroll med flerabyte UTF-8 är den föredragna namnkontrollmetoden för de flesta privatägda DNS-servrar som inte tillhandahåller namntjänst för Internetvärdar.