what is DNS & Active diretory ?

what is DNS & Active diretory ?..

Answer / maitreya.barmanray

Q1 :::: WHAT IS DNS & ACTIVE DIRETORY ??

Ans: DNS:
On the Internet, the Domain Name System (DNS)
associates various sorts of information with so-called
domain names; most importantly, it serves as the "phone
book" for the Internet: it translates human-readable
computer hostnames, e.g. en.wikipedia.org, into the IP
addresses that networking equipment needs for delivering
information. It also stores other information such as the
list of mail exchange servers that accept e-mail for a
given domain. In providing a worldwide keyword-based
redirection service, DNS is an essential component of
contemporary Internet use.
The most basic use of DNS is to translate hostnames to IP
addresses. It is in very simple terms like a phone book.
For example, if you want to know the internet address of
en.wikipedia.org, DNS can be used to tell you it's
66.230.200.100. DNS also has other important uses.
Pre-eminently, the DNS makes it possible to assign Internet
destinations to the human organization or concern they
represent, independently of the physical routing hierarchy
represented by the numerical IP address. Because of this,
hyperlinks and Internet contact information can remain the
same, whatever the current IP routing arrangements may be,
and can take a human-readable form (such
as "wikipedia.org") which is rather easier to remember than
an IP address (such as 66.230.200.100). People take
advantage of this when they recite meaningful URLs and e-
mail addresses without caring how the machine will actually
locate them.
The DNS also distributes the responsibility for assigning
domain names and mapping them to IP networks by allowing an
authoritative server for each domain to keep track of its
own changes, avoiding the need for a central registrar to
be continually consulted and updated.
How the DNS works in theory

Domain names, arranged in a tree, cut into zones, each
served by a nameserver.
The domain name space consists of a tree of domain names.
Each node or leaf in the tree has one or more resource
records, which hold information associated with the domain
name. The tree sub-divides into zones. A zone consists of a
collection of connected nodes authoritatively served by an
authoritative DNS nameserver. (Note that a single
nameserver can host several zones.)
When a system administrator wants to let another
administrator control a part of the domain name space
within his or her zone of authority, he or she can delegate
control to the other administrator. This splits a part of
the old zone off into a new zone, which comes under the
authority of the second administrator's nameservers. The
old zone becomes no longer authoritative for what comes
under the authority of the new zone.
A resolver looks up the information associated with nodes.
A resolver knows how to communicate with name servers by
sending DNS requests, and heeding DNS responses. Resolving
usually entails iterating through several name servers to
find the needed information.
Some resolvers function simplistically and can only
communicate with a single name server. These simple
resolvers rely on a recursing name server to perform the
work of finding information for them.
Understanding the parts of a domain name
A domain name usually consists of two or more parts
(technically labels), separated by dots. For example
wikipedia.org.
? The rightmost label conveys the top-level domain
(for example, the address en.wikipedia.org has the top-
level domain org).
? Each label to the left specifies a subdivision or
subdomain of the domain above it. Note that "subdomain"
expresses relative dependence, not absolute dependence: for
example, wikipedia.org comprises a subdomain of the org
domain, and en.wikipedia.org comprises a subdomain of the
domain wikipedia.org. In theory, this subdivision can go
down to 127 levels deep, and each label can contain up to
63 characters,[1] as long as the whole domain name does not
exceed a total length of 255 characters. But in practice
some domain registries have shorter limits than that.
? A hostname refers to a domain name that has one or
more associated IP addresses. For example, the
en.wikipedia.org and wikipedia.org domains are both
hostnames, but the org domain is not.
The DNS consists of a hierarchical set of DNS servers. Each
domain or subdomain has one or more authoritative DNS
servers that publish information about that domain and the
name servers of any domains "beneath" it. The hierarchy of
authoritative DNS servers matches the hierarchy of domains.
At the top of the hierarchy stand the root nameservers: the
servers to query when looking up (resolving) a top-level
domain name (TLD).
Iterative and recursive queries:
? An Iterative query is one where the DNS server may
provide a partial answer to the query (or give an error).
DNS servers must support non-recursive queries.
? A recursive query is one where the DNS server will
fully answer the query (or give an error). DNS servers are
not required to support recursive queries and both the
resolver (or another DNS acting recursively on behalf of
another resolver) negotiate use of recursive service using
bits in the query headers.
The address resolution mechanism
(This description deliberately uses the fictional .example
TLD in accordance with the DNS guidelines themselves.)
In theory a full host name may have several name segments,
(e.g ahost.ofasubnet.ofabiggernet.inadomain.example). In
practice, in the experience of the majority of public users
of Internet services, full host names will frequently
consist of just three segments (ahost.inadomain.example,
and most often www.inadomain.example).
For querying purposes, software interprets the name segment
by segment, from right to left, using an iterative search
procedure. At each step along the way, the program queries
a corresponding DNS server to provide a pointer to the next
server which it should consult.

A DNS recurser consults three nameservers to resolve the
address www.wikipedia.org.
As originally envisaged, the process was as simple as:
1. the local system is pre-configured with the known
addresses of the root servers in a file of root hints,
which need to be updated periodically by the local
administrator from a reliable source to be kept up to date
with the changes which occur over time.
2. query one of the root servers to find the server
authoritative for the next level down (so in the case of
our simple hostname, a root server would be asked for the
address of a server with detailed knowledge of the example
top level domain).
3. querying this second server for the address of a
DNS server with detailed knowledge of the second-level
domain (inadomain.example in our example).
4. repeating the previous step to progress down the
name, until the final step which would, rather than
generating the address of the next DNS server, return the
final address sought.
The diagram illustrates this process for the real host
www.wikipedia.org.
The mechanism in this simple form has a difficulty: it
places a huge operating burden on the root servers, with
each and every search for an address starting by querying
one of them. Being as critical as they are to the overall
function of the system such heavy use would create an
insurmountable bottleneck for trillions of queries placed
every day. The section DNS in practice describes how this
is addressed.
Circular dependencies and glue records
Name servers in delegations appear listed by name, rather
than by IP address. This means that a resolving name server
must issue another DNS request to find out the IP address
of the server to which it has been referred. Since this can
introduce a circular dependency if the nameserver referred
to is under the domain that it is authoritative of, it is
occasionally necessary for the nameserver providing the
delegation to also provide the IP address of the next
nameserver. This record is called a glue record.
For example, assume that the sub-domain en.wikipedia.org
contains further sub-domains (such as
something.en.wikipedia.org) and that the authoritative
nameserver for these lives at ns1.en.wikipedia.org. A
computer trying to resolve something.en.wikipedia.org will
thus first have to resolve ns1.en.wikipedia.org. Since ns1
is also under the en.wikipedia.org subdomain, resolving
ns1.en.wikipedia.org requires resolving
ns1.en.wikipedia.org which is exactly the circular
dependency mentioned above. The dependency is broken by the
glue record in the nameserver of wikipedia.org that
provides the IP address of ns1.en.wikipedia.org directly to
the requestor, enabling it to bootstrap the process by
figuring out where ns1.en.wikipedia.org is located.
DNS in practice
When an application (such as a web browser) tries to find
the IP address of a domain name, it doesn't necessarily
follow all of the steps outlined in the Theory section
above. We will first look at the concept of caching, and
then outline the operation of DNS in "the real world."
Caching and time to live
Because of the huge volume of requests generated by a
system like the DNS, the designers wished to provide a
mechanism to reduce the load on individual DNS servers. To
this end, the DNS resolution process allows for caching
(ie. the local recording and subsequent consultation of the
results of a DNS query) for a given period of time after a
successful answer. How long a resolver caches a DNS
response (ie. how long a DNS response remains valid) is
determined by a value called the time to live (TTL). The
TTL is set by the administrator of the DNS server handing
out the response. The period of validity may vary from just
seconds to days or even weeks.
Example
After having found a list of addresses of servers capable
of answering queries about (eg.) the .example TLD, the
local resolver will not make a query for .example again
until the validity of the currently known list expires. The
same applies for all subdomains. Once a response goes into
cache, the resolver will consult its cached (stored)
answer; only when the TTL expires (or when an administrator
manually flushes the response from the resolver's memory)
will the resolver contact the DNS server for the same
information. Hence having successfully resolved an address
of ahost.inadomain.example, it is not necessary to repeat
the process for some time, since the IP address now known
will be deemed reliable for the period set by the TTL, and
resolution of anotherhost.anotherdomain.example can
commence with already knowing which servers can answer
queries for the .example domain. Caching significantly
reduces the rate at which the most critical name servers
have to respond to queries, adding the extra benefit that
subsequent resolutions are not delayed by network transit
times for the queries and responses.
The benefits of caching are amplified when using busy (but
not congested) DNS servers: If a DNS server is frequently
queried for many addresses, there is an increased
probability that a DNS response to at least part of a DNS
query will already exist in that server's cache and will
not yet have exceeded its time to live. Most domestic and
small-business clients "hand off" address resolution to
their ISP's DNS servers to perform the look-up process,
thus allowing for the greatest benefit from those same ISPs
having busy local caches serving a wide variety of queries
and a large number of users.
Generally, the Start of Authority (SOA) record specifies
the time to live. The SOA record has the parameters:
? Serial ? the zone serial number, incremented when
the zone file is modified, so the slave and secondary name
servers know when the zone has been changed and should be
reloaded.
? Refresh ? the number of seconds between update
requests from secondary and slave name servers.
? Retry ? the number of seconds the secondary or
slave will wait before retrying when the last attempt has
failed.
? Expire ? the number of seconds a master or slave
will wait before considering the data stale if it cannot
reach the primary name server.
? Minimum ? previously used to determine the minimum
TTL, this offers negative caching.
(Newer versions of BIND (named) will accept the
suffixes 'M','H','D' or 'W', indicating a time-interval of
minutes, hours, days and weeks respectively.)
Caching time
As a noteworthy consequence of this distributed and caching
architecture, changes to the DNS do not always take effect
immediately and globally. This is best explained with an
example: If an administrator has set a TTL of 6 hours for
the host www.wikipedia.org, and then changes the IP address
to which www.wikipedia.org resolves at 12:01pm, the
administrator must consider that a person who cached a
response with the old IP address at 12:00pm will not
consult the DNS server again until 6:00pm. The period
between 12:01pm and 6:00pm in this example is called
caching time, which is best defined as a period of time
that begins when you make a change to a DNS record and ends
after the maximum amount of time specified by the TTL
expires. This essentially leads to an important logistical
consideration when making changes to the DNS: not everyone
is necessarily seeing the same thing you're seeing. RFC
1537 helps to convey basic rules for how to set the TTL.
Note that the term "propagation", although very widely used
in this context, does not describe the effects of caching
well. Specifically, it implies that [1] when you make a DNS
change, it somehow spreads to all other DNS servers
(instead, other DNS servers check in with yours as needed),
and [2] that you do not have control over the amount of
time the record is cached (you control the TTL values for
all DNS records in your domain, except your NS records and
any authoritative DNS servers that use your domain name).
Some resolvers may override TTL values, as the protocol
supports caching for up to 68 years or no caching at all.
Negative caching (the non-existence of records) is
determined by name servers authoritative for a zone which
MUST include the SOA record when reporting no data of the
requested type exists. The MINIMUM field of the SOA record
and the TTL of the SOA itself is used to establish the TTL
for the negative answer. RFC 2308
Many people incorrectly refer to a mysterious 48 hour or 72
hour propagation time when you make a DNS change. When one
changes the NS records for one's domain or the IP addresses
for hostnames of authoritative DNS servers using one's
domain (if any), there can be a lengthy period of time
before all DNS servers use the new information. This is
because those records are handled by the zone parent DNS
servers (for example, the .com DNS servers if your domain
is example.com), which typically cache those records for 48
hours. However, those DNS changes will be immediately
available for any DNS servers that do not have them cached.
And, any DNS changes on your domain other than the NS
records and authoritative DNS server names can be nearly
instantaneous, if you choose for them to be (by lowering
the TTL once or twice ahead of time, and waiting until the
old TTL expires before making the change).
DNS in the real world

DNS resolving from program to OS-resolver to ISP-resolver
to greater system.
Users generally do not communicate directly with a DNS
resolver. Instead DNS resolution takes place transparently
in client applications such as web browsers, mail clients,
and other Internet applications. When a request is made
which necessitates a DNS lookup, such programs send a
resolution request to the local DNS resolver in the
operating system which in turn handles the communications
required.
The DNS resolver will almost invariably have a cache (see
above) containing recent lookups. If the cache can provide
the answer to the request, the resolver will return the
value in the cache to the program that made the request. If
the cache does not contain the answer, the resolver will
send the request to a designated DNS server or servers. In
the case of most home users, the Internet service provider
to which the machine connects will usually supply this DNS
server: such a user will either have configured that
server's address manually or allowed DHCP to set it;
however, where systems administrators have configured
systems to use their own DNS servers, their DNS resolvers
point to separately maintained nameservers of the
organization. In any event, the name server thus queried
will follow the process outlined above, until it either
successfully finds a result or does not. It then returns
its results to the DNS resolver; assuming it has found a
result, the resolver duly caches that result for future
use, and hands the result back to the software which
initiated the request.
Broken resolvers
An additional level of complexity emerges when resolvers
violate the rules of the DNS protocol. Some people have
suggested[citation needed] that a number of large ISPs have
configured their DNS servers to violate rules (presumably
to allow them to run on less-expensive hardware than a
fully compliant resolver), such as by disobeying TTLs, or
by indicating that a domain name does not exist just
because one of its name servers does not respond.
As a final level of complexity, some applications such as
Web browsers also have their own DNS cache, in order to
reduce the use of the DNS resolver library itself. This
practice can add extra difficulty to DNS debugging, as it
obscures which data is fresh, or lies in which cache. These
caches typically have very short caching times of the order
of one minute. A notable exception is Internet Explorer;
recent versions cache DNS records for half an hour.[2]
Other DNS applications
The system outlined above provides a somewhat simplified
scenario. The DNS includes several other functions:
? Hostnames and IP addresses do not necessarily match
on a one-to-one basis. Many hostnames may correspond to a
single IP address: combined with virtual hosting, this
allows a single machine to serve many web sites.
Alternatively a single hostname may correspond to many IP
addresses: this can facilitate fault tolerance and load
distribution, and also allows a site to move physical
location seamlessly.
? There are many uses of DNS besides translating
names to IP addresses. For instance, Mail transfer agents
use DNS to find out where to deliver e-mail for a
particular address. The domain to mail exchanger mapping
provided by MX records accommodates another layer of fault
tolerance and load distribution on top of the name to IP
address mapping.
? Sender Policy Framework and DomainKeys instead of
creating own record types were designed to take advantage
of another DNS record type, the TXT record.
? To provide resilience in the event of computer
failure, multiple DNS servers provide coverage of each
domain. In particular, more than thirteen root servers
exist worldwide. DNS programs or operating systems have the
IP addresses of these servers built in.
The DNS uses TCP and UDP on port 53 to serve requests.
Almost all DNS queries consist of a single UDP request from
the client followed by a single UDP reply from the server.
TCP typically comes into play only when the response data
size exceeds 512 bytes, or for such tasks as zone transfer.
Some operating systems such as HP-UX are known to have
resolver implementations that use TCP for all queries, even
when UDP would suffice.

Active Directory:

Active Directory is an implementation of LDAP
directory services by Microsoft for use primarily in
Windows environments. The main purpose of Active Directory
is to provide central authentication and authorization
services for Windows based computers. Active Directory also
allows administrators to assign policies, deploy software,
and apply critical updates to an entire organization.
Active Directory stores information and settings relating
to an organization in a central, organized, accessible
database. Active Directory networks can vary from a small
installation with a few hundred objects, to a large
installation with millions of objects.
Active Directory was previewed in 1996, released first with
Windows 2000 Server edition, and revised to extend
functionality and improve administration in Windows Server
2003.
Active Directory was called NTDS (NT Directory Service) in
older Microsoft documents. This name remains in some AD
binaries as well.
Objects
Active Directory is a directory service used to store
information about the network resources across a domain.
An Active Directory (AD) structure is a hierarchical
framework of objects. The objects fall into three broad
categories: resources (e.g. printers), services (e.g. e-
mail) and users (accounts, or users and groups). The AD
provides information on the objects, organizes the objects,
controls access and sets security.
Each object represents a single entity ? whether a user, a
computer, a printer, or a group ? and its attributes.
Certain objects can also be containers of other objects. An
object is uniquely identified by its name and has a set of
attributes ? the characteristics and information that the
object can contain ? defined by a schema, which also
determines the kind of objects that can be stored in the AD.
Each attribute object can be used in several different
schema class objects. These schema objects exist to allow
the schema to be extended or modified when necessary.
However, because each schema object is integral to the
definition of AD objects, deactivating or changing these
objects can have serious consequences because it will
fundamentally change the structure of AD itself. A schema
object, when altered, will automatically propagate through
Active Directory and once it is created it can only be
deactivated ? not deleted. Changing the schema usually
requires a fair amount of planning.[1]
Forests, trees, and domains
The framework that holds the objects is viewed at a number
of levels. At the top of the structure is the Forest - the
collection of every object, its attributes and rules
(attribute syntax) in the AD. The forest holds one or more
transitive, trust-linked Trees. A tree holds one or more
Domain and domain trees, again linked in a transitive trust
hierarchy. Domains are identified by their DNS name
structure, the namespace. A domain has a single DNS name.
The objects held within a domain can be grouped into
containers called Organizational Units (OUs). OUs give a
domain a hierarchy, ease its administration, and can give a
semblance of the structure of the AD's company in
organizational or geographical terms. OUs can contain OUs -
indeed, domains are containers in this sense - and can hold
multiple nested OUs. Microsoft recommends as few domains as
possible in AD and a reliance on OUs to produce structure
and improve the implementation of policies and
administration. The OU is the common level at which to
apply group policies, which are AD objects themselves
called Group Policy Objects (GPOs), although policies can
also be applied to domains or sites (see below). The OU is
the level at which administrative powers are commonly
delegated, but granular delegation can be performed on
individual objects or attributes as well.
AD also supports the creation of Sites, which are physical,
rather than logical, groupings defined by one or more IP
subnets. Sites distinguish between locations connected by
low-speed (e.g. WAN, VPN) and high-speed (e.g. LAN)
connections. Sites are independent of the domain and OU
structure and are common across the entire forest. Sites
are used to control network traffic generated by
replication and also to refer clients to the nearest domain
controllers. Exchange 2007 also uses the site topology for
mail routing. Policies can also be applied at the site
level.
The actual division of the company's information
infrastructure into a hierarchy of one or more domains and
top-level OUs is a key decision. Common models are by
business unit, by geographical location, by IT Service, or
by object type. These models are also often used in
combination. OUs should be structured primarily to
facilitate administrative delegation, and secondarily, to
facilitate group policy application. Although OUs form an
administrative boundary, the only true security boundary is
the forest itself and an admin
Physical structure and replication
Physically the AD information is held on one or more equal
peer domain controllers (DCs), replacing the NT PDC/BDC
format. Each DC has a copy of the AD; changes on one
computer being synchronized (converged) between all the DC
computers by multi-master replication. Servers joined in to
AD, which are not domain controllers, are called Member
Servers. The AD database is split into different stores or
partitions. Microsoft often refers to these partitions
as 'naming contexts'. The 'Schema' partition contains the
definition of object classes and attributes within the
Forest. The 'Configuration' partition, contains information
on the physical structure and configuration of the forest
(such as the site topology). The 'Domain' partition holds
all objects created in that domain. The first two
partitions replicate to all domain controllers in the
Forest. The Domain partition replicates only to Domain
Controllers within its domain. A subset of objects in the
domain partition are also replicated to domain controllers
that are configured as global catalogs.
Unlike earlier versions of Windows which used NetBIOS to
communicate, Active Directory is fully integrated with DNS
and TCP/IP ? indeed DNS is required. To be fully
functional, the DNS server must support SRV resource
records or service records.
AD replication is 'pull' rather than 'push'. The Knowledge
Consistency Checker (KCC) creates a replication topology of
site links using the defined sites to manage traffic.
Intrasite replication is frequent and automatic as a result
of change notification, which triggers peers to begin a
pull replication cycle. Intersite replication intervals are
less frequent and do not use change notification by
default, although this is configurable and can be made
identical to intrasite replication. A different 'cost' can
be given to each link (e.g. DS3, T1, ISDN etc.) and the
site link topology will be altered accordingly by the KCC.
Replication between domain controllers may occur
transitively through several site links on same-protocol
site link bridges, if the 'cost' is low, although KCC
automatically costs a direct site-to-site link lower than
transitive connections. Site-to-site replication can be
configured to occur between a bridgehead server in each
site, which then replicates the changes to other DCs within
the site.
In a multi-domain forest the AD database becomes
partitioned. That is, each domain maintains a list of only
those objects that belong in that domain. So, for example,
a user created in Domain A would be listed only in Domain
A's domain controllers. Global catalog (GC) servers are
used to provide a global listing of all objects in the
Forest. The Global catalog is held on domain controllers
configured as global catalog servers. Global Catalog
servers replicate to themselves all objects from all
domains and hence, provide a global listing of objects in
the forest. However, in order to minimize replication
traffic and to keep the GC's database small, only selected
attributes of each object are replicated. This is called
the partial attribute set (PAS). The PAS can be modified by
modifying the schema and marking attributes for replication
to the GC.
Replication of Active Directory uses RPCs (Remote Procedure
Calls). Between Sites you can also choose to use SMTP for
replication, but only for changes in the Schema or
Configuration. SMTP cannot be used for replicating the
Domain partition. In other words, if a domain exists on
both sides of a WAN connection, you must use RPCs for
replication.
The AD database, the directory store, in Windows 2000 uses
the JET Blue-based Extensible Storage Engine (ESE98),
limited to 16 terabytes and 1 billion objects in each
domain controller's database. Microsoft have created NTDS
databases with more than 2 billion objects. (NT4's Security
Account Manager could support no more than 40,000 objects).
Called NTDS.DIT, it has two main tables: the data table and
the link table. In Windows 2003 a third main table was
added for security descriptor single instancing.

Is This Answer Correct ?

11 Yes

7 No