Gebruiksaanwijzing /service van het product windows 2000 DNS van de fabrikant Microsoft
Ga naar pagina of 70
Operat i ng S ystem Windows 2000 DNS White Paper Abstract This paper describes the Microsoft® W ind o ws® 2000 oper ating system Domain Naming System (DNS), including design, implementation, and migration issues.
© 1999 Microsoft Corporation. All rights reserved. The informat ion contained in th is document represents the current view of M icrosoft Corporation on the issues d iscussed as of the date of publication.
WHIT E PAP E R ... .. .........................................................................1 CON TENTS ....... .......... ............ ............ .......... ............ .....................3 INT RODU CTI ON....... .............................
Dyn amic Up date ......... ............ ............ .......... ............ ............ ............................15 Prot ocol Desc riptio n........... .......... ............ ............ .......... ............ ............ ......16 Update Algorithm.
Internet Access Considerations.... ........ ........ ........ ........................................46 Characters in Names................ .. .. .. .. .. .. .. .... .. .. .. .. .. ........................................ 5 5 Comp uter N ames .......
.
The designers of the Microsoft ® Wi ndows® 2000 operating system chose the Domain Name System (DNS ) as the name service for the operating system. Wi ndows 2000 Server include s an IETF standard-based Domain Name System Server. Because it is RFC compliant it is fully com patible with any other RFC compliant DNS servers.
Name Services in Windows 2000 DNS is the name service of Wi ndows 2 000. It is by design a highly reliable, hierarchical, distributed, and scalable database. W in dows 2000 clients use DNS for name resolution and service location, in cluding locating domain co ntrollers for logon.
• Draft-skwan-gss- tsig-04.txt (GSS Algorithm for TSIG (GSS-TSIG) ) For more information on these documents, go to http:// www.i etf.org/ . In addition to the listed RFCs and Drafts the implementation of the ATMA DNS records is based on the “ATM Name System Specifica tion Version 1.
superceded by RFC 1034 (Domain Names–Concepts and Facilities), and RFC 1035 (Domain Names–Implemen tation and Specif ication). RFCs that describe DNS security, implementation, and administrative issue s later a ugmented these. The implementation of DNS—Berkeley Internet Name Domain (BIND)—was originally developed for the 4.
co m ed u gov mi l m ic r os oft m ydom a i n mi t Managed by N Regis tr ation A uthor it y Managed by Mic r osoft w h i teh o use ar my i nt/ n et/o r g Mic r os oft Di DNS and Interne t The Internet.
Description Class TTL Type Data Start of Authori t y Internet (IN) Default TTL is 60 minutes SOA Owner Name, Primary Na me Server DNS Name, Se rial Number, Refresh Interval, Retry Interval, Expire Tim.
• A need to delegate management of a DNS domain to a numb er of organizations or d epartments within an organization • A need to distribute the load of maintaining one large DNS database among mul.
The changes made to the primary zone file are then replicated to the secondary zone file. As mentioned above, a name server can host multiple zo ne s. A server can therefore be primary for one zone (it has the master copy of the zone file) a nd secondary for another zone (it gets a read-only copy of the zone file).
or a successfu l response. Resolvers typically make recursive queries. W ith a recursive query, the DNS server must contact any other DNS servers it needs to resolve the request. Whe n it receives a successf ul resp on se from the other DNS Server(s), it then sends a response to the client.
www.whitehouse.g ov: • Recu r sive quer y fo r www. whit ehou se. gov ( A RR) • Iterative query for www.whitehouse.gov (A RR) • Referral to the gov name ser ver (NS RRs, for go v); for simplicit.
• Incr emental Z o n e Tran sfer (I XFR) • Dynamic Upd ate an d Secur e Dynamic Update • Unicode Character Support • Enhanced Domain Locator • Enhanced Caching Resolver Service • Enhanced .
Each Active Directory service object has attributes associated with it that define particular characteristics of the object. The classes of objects in the Active Directory service database as well as each object’s attributes are defined in the Active Directory service schema.
Note: Only DNS servers running on domain controllers can load DS integrated zones. The Replication Model Since DNS zone information is now stored in Active Dir ectory service, whenever an update is made to a DNS server, it simply writes the data to Active Directory and continues performing its usual function s.
Note that only DNS server supports the Secure Dynamic Updates for the DS- integrate d zone s. Windows 2000 i mplem entation p rovides even finer g ranularity allowing per-name ACL specific a tion. More details we consider ACLs and specific Administrative groups later in “Controlling Update Access to Zones and Names.
The following diagram details the incremental transfer mechanism. Master DNS Server Slave DNS Server 1 Serial Number 1 1 Serial Num ber 10 Serial Number 8 I X F R S e r ia l N u m b e r 1 2 c h a n g .
protocols, rendered manual updating of DNS information insuf ficient and unusable. No human administrator can be expected to keep up with dynamic address assignments even in a medium size network environment. It was clear that automatic assignment of addresses had to be integrate d with dynamic DNS updates.
The dynamic update algorithm differs depending o n the type of client network adapter engaging in the dynamic update process. The following three scenarios will be examined: • DHCP client • Static.
client’s PTR RR. Also, the DHCP server will remove the corresponding A records if configured to ”Discard fo rward lookups when leases expire.” Statically Configu red Client A statically c onfigu.
algorithm defined in the Internet Draft “GSS Algorithm for TSIG (GSS-TSIG).” This algorithm is based on the Generic Security Service Application Program Interface (GSS-API) specified in RFC 2078.
In step 1, the client queries the local name server to discover which server is authoritative for the name it is attempting to update, and the local name server responds with the reference to th e authoritative server.
however, can be changed through the registry. Controlling Update A ccess to Zones and Names Active Directory controls access to the secure DNS zones and names in them through the ACLs. The ACL s can be specifie d for either an entire zone or modified for some specific names.
DNS Admins Group By default the DNS Admins group has full control of all zones and records in a Wi ndows 2000 domain in which it is specified. In order for a user to be able to enum erate zones i n a specific Windows 2000 do main, the user (o r a grou p the us er belongs to) must be enlisted in the DNS Admin group.
• Whi ch zones can be scavenged • Whi ch records must be scavenged if they become stale The DNS server uses an algorithm that ensures that it does not accidenta lly scavenge a record that must remain, provided that you configure all the parameters correctly.
Aging and Scavenging Parameters for Zones Zone Parameter Description Configuration Tool Notes No-refresh interval Time interval, after the last time a record’ s times tamp has been refresh e d, during which the server d oes not accept refreshes for the record.
The table below lists the server parameters that affect when records are scavenged. You set these parameters on the server. Aging and Scavenging Parameters f or Servers Server Parameter Description Co.
Record Life Span The Figure below shows the life span of a scavengeable record. When a record is created or refreshed on an Active Directory–integrated zone or on a standard primary zone for which scavenging is enabled, a record’s timestamp is written.
the record at that time. The time at which records are scavenged depends on several server paramete rs. Scavenging Algorithm The server can be configured to per form scavenging automatically, using a fixed frequency. In addition, you can manually trigger scavenging on a server to perform immediate scavenging.
Usually, the DHCP service requires th e longest refresh in terval of all services. If you are using the W indows 2000 DHCP service, you can use the default scavenging and aging values. If you are using another DHCP server, you might need to modify the defaults.
zone file. Administrators should exercise caution when transferring a zone containing UTF-8 names to a non-UTF–8-aware DNS server. The Domain Loca tor The Win dows 2000 Domain Locator, implemented in the Netlogon service, is a service that enables a clie nt (t he machine locating a Domain Controller (DC)) to locate a DC.
Collect the fo llowing inf o: DNS Domain Nam e, Domain G UID, Site N a m e . Did client find DNS Do main Name or Dom ain GU ID? Finish No Yes Call Window s NT 4 compa tible Locator Call IP/DNS compa t.
The description of th e Wi ndows NT 4 Compatible Domain Locator has been omitted, since it is irrele vant to the DNS and is described in “ Wi ndows 2000 Domain Contr oller Loc ator IP/DNS Compatible Locator The algorithm behind the IP/DNS Compatible Locator consists of two main parts.
_ldap. _tcp. <Sit eNam e>. _sites .<DnsDomainName>. Allows a client to find an LDAP server in the domain named by <DnsDomainNa me> and is in the site named by <SiteName>. For example, _ldap._tcp.redmond._sites.nt.microsoft.c om .
All DCs providing the Ke rberos service will register this name. This service is at least an RFC-1510 compliant Kerber os 5 KDC. The KDC is not necessarily a DC. All W indows NT Domain controllers running the Kerberos KDC service will register this name.
IP/DNS DC Locator Algorithm The IP/DNS DC Locator algorithm is executed in the context of the NetLogon service, (typically) running on the client. The algorithm, shown in the flowchart, works as follows: • Call DnsQuery specifying one of the criteria specif ic DNS host names.
Send a DNS query specifying one o f the criteria specific DNS host names Does the DNS query response contain at least one DC? Quit indicating the reason No Among all DCs returned in the DNS response i.
A client might have multiple network adapters and thus might have multiple IP addresses. That could theoretically put the client in multiple sites. The design above ignores this remote possib ility. Rather, it assumes that the client is in the site corresponding to the adapter, which was used to ping one of the DCs.
computer, the same rule is applicable to every adapter separately. This feature is enabled by default. It can be disabled through the Registry. Name Res olut ion A basic name r esolut ion reques t con sist s of a query fo r a give n type of a DNS record with a given DNS name.
resolution. The following summarizes the name resolution algorithm: • The query is issued to the lead server on the preferred adapter's server list. • If no response was received within a one second interva l, the query is issued to the lead server(s) on all lists, including the one on the preferred adapter.
• The query is processed as a fully-qualified query. • If the result is a positive response, the response is returned to the caller. • If the result is a timeout, then a timeout is returned to the caller. • If the result is a negative response, the next suffi x is appended and the algorithm is restarted at step 2.
• The response is returned t o the client. Name Resolution Scenarios This se ction prov ides n ame resoluti on s cenario s for a m ulti-homed machine using unqualified single-label and fully qualified queries. In this scenario the Global suffix search list is not specifie d.
• negat i ve res p on se • query t1 for bogu z.dns.microsoft.com. • negat i ve res p on se • query e1 for boguz.d ns.ntlab.microsof t. com. • negat i ve res p on se • quer y t1 for bogu z.dns. ntlab .micros oft.com. • negat i ve res p on se • query e1 for bogu z.
Registry key HKEY_Local_Ma chineSystemCurrentControlSetServ ices DNSCacheParameters . Disabling the Caching Resolver There are two wa ys to disable the caching resolver: • Manually disable the cach ing resolver service by typing “net stop dnscach e” at the command promp t.
hardware components can provide information and notification of events. WMI simplifies the instrumentation of various drivers and applications written for Wi ndows, provides detailed and extensible in.
Receiving Non-RFC Compliant Data If a W indows 2000 server supports a secondary zone and receives unknown resource records, th en it drops such records and continues zone replication.
Hardw are co mponents Sizing Number of pr ocessors Two Proces s or Intel Pentium II 400 MHz Amount of RA M 256 MB (me gabytes) Hard dis k drive s pa c e 4 GB (gigabyte s ) These measurements were based on the server computer running a DNS server and with no other services in use.
namespace and DNS architecture to support it, and then revising the ADS and DNS design if unforeseen, or undesirable consequences are uncovered. The Win dows 2000 Active Directory Namespace Design whi.
strongly discouraged, sin ce it may lead to the ambiguity in name resolution processes. In this section the focus is on the design of the private namespaces and the configuration of the DNS servers and zones. The specifics of two diff erent designs are presented by considering two companies using private namespaces of dif ferent structure.
The following DNS configuration and name resolution scenarios are considered in detail with overlapping intern al and external namespaces, since it is the most complicated case. It is assumed that the namespaces of both companies consist only of names within a NSI assigned d omain, that is, yyy.
zone, that is, zzz.com., must also contain the zones containing all ( internal and external) names of the merged companies. Now take a look at a private namespace design and the configuration of the DNS servers, zones and clients for the YYY Corporation.
Ex t ernal w orld / Glo bal N ez z z rk YYY c orporat ion ZZZ co r p o r a ti o n YYY c orporat ion ZZZ co r p o r a tio n VPN VPN Prox y Serv er Fi r e wa l l A D N S Serv er, F irew all, VPN or Prox y Serv er A D N S C lient fi r st.yyy.com. se co n d .
forwar ds the qu ery to th e DNS server c ontain ing the zzz.com. z one (St ep 2). Th is server finds a delegation to the third.zzz.com. in the zzz.co m. zone. It sends the query to that server (Step3) re ceives back the response (Step 4), passes it to the previous server (Step 5), which fina lly returns it to the client (Step 6).
(Step 8). The DNS serve r returns the response to the proxy server (Step 9). Finally, the proxy server uses the obtained IP address of www.someother.com. to contact it and provides the necessary information to the client (Step 10). A computer in the ZZZ Corporation needs to resolve a DNS query for www.
Now consider an interesting case of a corporate computer that needs to resolve an external name of a computer from its own co mpany. A computer in the YYY Corporation needs to open a web page on the www.yyy.co m. machine. Since it is a proxy client it sends a request to the proxy server (Step 1) after it finds that the name www.
A computer in the ZZZ Corporation needs to resolve a DNS query for www.zzz.com . It submits the query to the assigned DNS server (Step 1). If its cache contains th e necessary data, the server will respond to the client. Otherwise the server forwards the query to the DNS server containing the zzz.
First it finds that the name myn ame.zzz. com. is internal, based on the PAC file. Therefore, it submits a query to the assigned DNS s erver (Step 1). If the cache contains the necessary data, the server will respond to the client. Otherwise, the server will query a root server (Step 2 ).
a full DNS computer name, which is a concatenation of Host name and primary DNS suffix. The primary DNS suffix is part of the base machine configur ation and is not related to any networking components. Non- networked or non-TCP/IP-based machines do not have primary DNS suffix.
A c t ive D ir ect o r y D o mai n : M yC om p an y. co m Hos t na me : My Co m p u te r Pr im a ry D N S su f f ix – M yC o mp an y. co m F ull co mp u t er n ame : M yC o mp u t er.M yC o mp any.com Pub lic Net work 10B aseT In t ern al B acku p N et wo rk 100B aseT DNS Na me s: My Compute r .
If existing DNS tree is implemented by Windows NT 4.0 DNS, the solution is to upgrade the Windows NT 4.0 DNS servers to the Wind ows 2000 implementation of DNS. If a non-Microsoft DNS implementation is in place and it does not support SRV RRs and Dynamic Update, then the question is: can it be upgraded.
D o y ou hav e D N S De si g n /De p l o y W indows 2000 D N S T opology Ye s No Ove rla p Fi n i sh Wh a t i s yo u r DNS Na mi ng plat f orm & t opology ? W indow s N T 4 D N S in Plac e U pgrad.
secondary zones can be upgraded to DS integrated zones. At this point non- Microsoft DNS servers can be safely retired and removed from the network. Deploy in g DNS to Support Activ e Di rectory If you are designing a brand new network environment, the process of deploying Active Directory service/ Win dows 2000 DNS is relatively straightforward.
Using Automatic Configur ation The Win dows 2000 implementation of DNS of fers a DNS Server Configuration wizard, which greatly simplifies the DNS server installation and configuration process. For example, it o ffers an elegant way of priming the root hints for a new DNS server.
In the picture above, a WINS referral zone called wins.mydom ain.micr osoft.co m. has been created and pointed to the WIN S database. Assume that a Win dows NT 4.0-based client h as a name client1 . A W ind ows 2000-based client belongs to the mydom ain.
• Enhanced Caching Resolver Service • Enhanced DNS Manager To properly deploy DNS in the Win d ows 2000 -based environment, it is recommended to start with the ADS design and then support it with the appropriated DNS namespace. For ADS design refer to the Win dows 2000 Active Directory Namespace Design white p aper.
UCS-2 –Also known as Unicode is a character encoding protocol. UTF-8 –A cha racter en c od ing protoc ol, specified in RFC 20 4 4 WINS –Windows Nam e Sys tem (WINS) is the p re-D NS nam e syste m. It i s still supported in the Wi ndows 2000 in order to maintain interoperability between the differe nt generations of Wi ndows computers.
Een belangrijk punt na aankoop van elk apparaat Microsoft windows 2000 DNS (of zelfs voordat je het koopt) is om de handleiding te lezen. Dit moeten wij doen vanwege een paar simpele redenen:
Als u nog geen Microsoft windows 2000 DNS heb gekocht dan nu is een goed moment om kennis te maken met de basisgegevens van het product. Eerst kijk dan naar de eerste pagina\'s van de handleiding, die je hierboven vindt. Je moet daar de belangrijkste technische gegevens Microsoft windows 2000 DNS vinden. Op dit manier kan je controleren of het apparaat aan jouw behoeften voldoet. Op de volgende pagina's van de handleiding Microsoft windows 2000 DNS leer je over alle kenmerken van het product en krijg je informatie over de werking. De informatie die je over Microsoft windows 2000 DNS krijgt, zal je zeker helpen om een besluit over de aankoop te nemen.
In een situatie waarin je al een beziter van Microsoft windows 2000 DNS bent, maar toch heb je de instructies niet gelezen, moet je het doen voor de hierboven beschreven redenen. Je zult dan weten of je goed de alle beschikbare functies heb gebruikt, en of je fouten heb gemaakt die het leven van de Microsoft windows 2000 DNS kunnen verkorten.
Maar de belangrijkste taak van de handleiding is om de gebruiker bij het oplossen van problemen te helpen met Microsoft windows 2000 DNS . Bijna altijd, zal je daar het vinden Troubleshooting met de meest voorkomende storingen en defecten #MANUAl# samen met de instructies over hun opplosinge. Zelfs als je zelf niet kan om het probleem op te lossen, zal de instructie je de weg wijzen naar verdere andere procedure, bijv. door contact met de klantenservice of het dichtstbijzijnde servicecentrum.
