1. What is Active Directory?

Active Directory is a technology created by Microsoft that provides a variety of network

services, including: * LDAP-like directory services * Kerberos-based authentication * DNS-
based naming and other network information * Central location for network administration
and delegation of authority http://en.wikipedia.org/wiki/Active_Directory

2. What is LDAP?

LDAP
From Wikipedia, the free encyclopedia

  (Redirected from Ldap)

Jump to: navigation, search

The Lightweight Directory Access Protocol (LDAP) (pronounced /ˈɛldæp/) is an

application protocol for querying and modifying data of directory services implemented in
Internet Protocol (IP) networks.[1]

A directory is a set of objects with attributes organized logically in a hierarchical manner. A

simple example is the telephone directory, which consists of a list of names (of either persons
or organizations) organized alphabetically, with each name having an address and phone
number associated with it.

A directory information tree often reflects various political, geographic, and/or organizational
boundaries, depending on the model chosen. LDAP deployments today tend to use Domain
Name System (DNS) names for structuring the topmost levels of the hierarchy. Deeper inside
the directory might appear entries representing people, organizational units, printers,
documents, groups of people or anything else that represents a given tree entry (or multiple
entries).

The latest version of LDAP is Version 3, which is specified in a series of Internet

Engineering Task Force (IETF) Standard Track Requests for comments (RFCs) as detailed in
RFC 4510.

Internet Protocol Suite

Application Layer

BGP · DHCP · DNS · FTP · HTTP · IMAP · IRC ·

LDAP · MGCP · NNTP · NTP · POP · RIP · RPC ·
RTP · SIP · SMTP · SNMP · SSH · Telnet ·
TLS/SSL · XMPP ·
 (more)

Transport Layer

TCP · UDP · DCCP · SCTP · RSVP · ECN ·

(more)

Internet Layer

IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec ·

(more)

Link Layer

ARP/InARP · NDP · OSPF · Tunnels (L2TP) · PPP ·

Media Access Control (Ethernet, DSL, ISDN, FDDI) ·
(more)

This box: view • talk • edit

Contents
[hide]

 1 Origin and influences

 2 Protocol overview
 3 Directory structure
 4 Operations
o 4.1 StartTLS
o 4.2 Bind (authenticate)
o 4.3 Search and Compare
o 4.4 Update Data
o 4.5 Extended operations
o 4.6 Abandon
o 4.7 Unbind
 5 LDAP URLs
 6 Schema
 7 Variations
 8 Other data models
 9 Usage
o 9.1 Naming structure
 10 Terminology
 11 See also
 12 References
 13 Further reading
  14 External links
o 14.1 Configuration
o 14.2 RFCs

[edit] Origin and influences

Telecommunication companies introduced the concept of directory services to information
technology and computer networking, since their understanding of directory requirements
was well-developed after some 70 years of producing and managing telephone directories.
The culmination of this input was the comprehensive X.500 specification,[2] a suite of
protocols produced by the International Telecommunication Union (ITU) in the 1980s.

X.500 directory services were traditionally accessed via the X.500 Directory Access Protocol
(DAP), which required the Open Systems Interconnection (OSI) protocol stack. LDAP was
originally intended to be a lightweight alternative protocol for accessing X.500 directory
services through the simpler (and now widespread) TCP/IP protocol stack. This model of
directory access was borrowed from the DIXIE and Directory Assistance Service protocols.

Standalone LDAP directory servers soon followed, as did directory servers supporting both
DAP and LDAP. The latter has become popular in enterprises, as LDAP removed any need to
deploy an OSI network. Today, X.500 directory protocols including DAP can also be used
directly over TCP/IP.

The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille
of Isode Limited, and Wengyik Yeong of Performance Systems International, circa 1993.
Further development has come through the Internet Engineering Task Force.

In the early engineering stages of LDAP, it was known as Lightweight Directory Browsing
Protocol, or LDBP. It was renamed with the expansion of the scope of the protocol beyond
directory browsing and searching, to include directory update functions. It was given its
Lightweight name because it was not as network intensive as its DAP predecessor and thus
was more easily implemented over the internet due to its lightweight bandwidth usage.

LDAP has influenced subsequent Internet protocols, including later versions of X.500, XML
Enabled Directory (XED), Directory Service Markup Language (DSML), Service
Provisioning Markup Language (SPML), and the Service Location Protocol (SLP).

[edit] Protocol overview

A client starts an LDAP session by connecting to an LDAP server, called a Directory System
Agent (DSA), by default on TCP port 389. The client then sends an operation request to the
server, and the server sends responses in return. With some exceptions, the client does not
need to wait for a response before sending the next request, and the server may send the
responses in any order.

The client may request the following operations:

 Start TLS — use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection
  Bind — authenticate and specify LDAP protocol version
 Search — search for and/or retrieve directory entries
 Compare — test if a named entry contains a given attribute value
 Add a new entry
 Delete an entry
 Modify an entry
 Modify Distinguished Name (DN) — move or rename an entry
 Abandon — abort a previous request
 Extended Operation — generic operation used to define other operations
 Unbind — close the connection (not the inverse of Bind)

In addition the server may send "Unsolicited Notifications" that are not responses to any
request, e.g. before it times out a connection.

A common alternate method of securing LDAP communication is using an SSL tunnel. This
is denoted in LDAP URLs by using the URL scheme "ldaps". The default port for LDAP
over SSL is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2)
but it was never standardized in any formal specification. This usage has been deprecated
along with LDAPv2, which was officially retired in 2003.

LDAP is defined in terms of ASN.1, and protocol messages are encoded in the binary format
BER. It uses textual representations for a number of ASN.1 fields/types, however.

[edit] Directory structure

The protocol accesses LDAP directories, which follow the 1993 edition of the X.500 model:

 A directory is a tree of directory entries.

 An entry consists of a set of attributes.
 An attribute has a name (an attribute type or attribute description) and one or more values.
The attributes are defined in a schema (see below).
 Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative
Distinguished Name (RDN), constructed from some attribute(s) in the entry, followed by the
parent entry's DN. Think of the DN as the full file path and the RDN as its relative filename in
its parent folder (e.g. if C:\foo\bar\myfile.txt were the DN, then myfile.txt would be the
RDN).

Be aware that a DN may change over the lifetime of the entry, for instance, when entries are
moved within a tree. To reliably and unambiguously identify entries, a UUID might be
provided in the set of the entry's operational attributes.

An entry can look like this when represented in LDAP Data Interchange Format (LDIF)
(LDAP itself is a binary protocol):

dn: cn=John Doe,dc=example,dc=com

cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: [email protected]
 manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

"dn" is the distinguished name of the entry; it's not an attribute nor part of the entry. "cn=John
Doe" is the entry's RDN (Relative Distinguished Name), and "dc=example,dc=com" is the
DN of the parent entry, where "dc" denotes 'Domain Component'. The other lines show the
attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common
name, "dc" for domain component, "mail" for e-mail address and "sn" for surname.

A server holds a subtree starting from a specific entry, e.g. "dc=example,dc=com" and its
children. Servers may also hold references to other servers, so an attempt to access
"ou=department,dc=example,dc=com" could return a referral or continuation reference to a
server which holds that part of the directory tree. The client can then contact the other server.
Some servers also support chaining, which means the server contacts the other server and
returns the results to the client.

LDAP rarely defines any ordering: The server may return the values of an attribute, the
attributes in an entry, and the entries found by a search operation in any order. This follows
from the formal definitions - an entry is defined as a set of attributes, and an attribute is a set
of values, and sets need not be ordered.

[edit] Operations
The client gives each request a positive Message ID, and the server response has the same
Message ID. The response includes a numeric result code which indicates success, some error
condition or some other special cases. Before the response, the server may send other
messages with other result data - for example each entry found by the Search operation is
returned in such a message.

Expand discussion of referral responses to various operations, especially modify, for example
where all modifies must be directed from replicas to a master directory.

[edit] StartTLS

The StartTLS operation establishes Transport Layer Security (the descendant of SSL) on the
connection. It can provide data confidentiality (to protect data from being observed by third
parties) and/or data integrity protection (which protects the data from tampering). During
TLS negotiation the server sends its X.509 certificate to prove its identity. The client may
also send a certificate to prove its identity. After doing so, the client may then use
SASL/EXTERNAL. By using the SASL/EXTERNAL, the client requests the server derive
its identity from credentials provided at a lower level (such as TLS). Though technically the
server may use any identity information established at any lower level, typically the server
will use the identity information established by TLS.

Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly known as
"LDAP over SSL") protocol on a separate port, by default 636. LDAPS differs from LDAP in
two ways: 1) upon connect, the client and server establish TLS before any LDAP messages
are transferred (without a StartTLS operation) and 2) the LDAPS connection must be closed
upon TLS closure.

LDAPS was used with LDAPv2, because the StartTLS operation had not yet been defined.
The use of LDAPS is deprecated, and modern software should only use StartTLS .

[edit] Bind (authenticate)

The Bind operation authenticates the client to the server. Simple Bind can send the user's DN
and password in plaintext, so the connection should be protected using Transport Layer
Security (TLS). The server typically checks the password against the userPassword attribute
in the named entry. Anonymous Bind (with empty DN and password) resets the connection to
anonymous state. SASL (Simple Authentication and Security Layer) Bind provides
authentication services through a wide range of mechanisms, e.g. Kerberos or the client
certificate sent with TLS.

Bind also sets the LDAP protocol version. Normally clients should use LDAPv3, which is the
default in the protocol but not always in LDAP libraries.

Bind had to be the first operation in a session in LDAPv2, but is not required in LDAPv3 (the
current LDAP version).

[edit] Search and Compare

The Search operation is used to both search for and read entries. Its parameters are:

baseObject 

The DN (Distinguished Name) of the entry at which to start the search,

scope 

What elements below the baseObject to search. This can be BaseObject (search just the
named entry, typically used to read one entry), singleLevel (entries immediately below
the base DN), or wholeSubtree (the entire subtree starting at the base DN).

filter 

Criteria to use in selecting elements within scope. For example, the filter
(&(objectClass=person)(|(givenName=John)(mail=john*))) will select
"persons" (elements of objectClass person) who either have the given name "John" or an e-
mail address that begins with the string "john".

derefAliases 

Whether and how to follow alias entries (entries which refer to other entries),

attributes 

Which attributes to return in result entries.

sizeLimit, timeLimit 

Maximum number of entries to return, and maximum time to allow search to run.

typesOnly 

Return attribute types only, not attribute values.

The server returns the matching entries and potentially continuation references. These may be
returned in any order. The final result will include the result code.

The Compare operation takes a DN, an attribute name and an attribute value, and checks if
the named entry contains that attribute with that value.

[edit] Update Data

Add, Delete, and Modify DN - all require the DN of the entry that is to be changed.

Modify takes a list of attributes to modify and the modifications to each: Delete the attribute
or some values, add new values, or replace the current values with the new ones.

Add operations also can have additional attributes and values for those attributes.

Modify DN (move/rename entry) takes the new RDN (Relative Distinguished Name),
optionally the new parent's DN, and a flag which says whether to delete the value(s) in the
entry which match the old RDN. The server may support renaming of entire directory
subtrees.

An update operation is atomic: Other operations will see either the new entry or the old one.
On the other hand, LDAP does not define transactions of multiple operations: If you read an
entry and then modify it, another client may have updated the entry in the mean time. Servers
may implement extensions [3] which support this, however.

[edit] Extended operations

The Extended Operation is a generic LDAP operation which can be used to define new
operations. Examples include the Cancel and Password Modify.

[edit] Abandon

The Abandon operation requests that the server abort an operation named by a message ID.
The server need not honor the request. Unfortunately, neither Abandon nor a successfully
abandoned operation send a response. A similar Cancel extended operation has therefore
been defined which does send responses, but not all implementations support this.

[edit] Unbind

The Unbind operation abandons any outstanding operations and closes the connection. It has
no response. The name is of historical origin, and is not the opposite of the Bind operation.[4]
Clients can abort a session by simply closing the connection, but they should use Unbind.[5]
Unbind allows the server to gracefully close the connection and free resources that it would
otherwise keep for some time until discovering the client had abandoned the connection. It
also instructs the server to cancel operations that can be canceled, and to not send responses
for operations that cannot be canceled.[6]

[edit] LDAP URLs

An LDAP URL format exists which clients support in varying degree, and which servers
return in referrals and continuation references (see RFC 4516):

ldap://host:port/DN?attributes?scope?filter?extensions

Most of the components, which are described below, are optional.

 host is the FQDN or IP address of the LDAP server to search.

 port is the network port of the LDAP server.
 DN is the distinguished name to use as the search base.
 attributes is a comma-separated list of attributes to retrieve.
 scope specifies the search scope and can be "base" (the default), "one" or "sub".
 filter is a search filter. For example (objectClass=*) as defined in RFC 4515.
 extensions are extensions to the LDAP URL format.

For example, "ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com" refers to

all user attributes in John Doe's entry in ldap.example.com, while
"ldap:///dc=example,dc=com??sub?(givenName=John)" searches for the entry in the
default server (note the triple slash, omitting the host, and the double question mark, omitting
the attributes). As in other URLs, special characters must be percent-encoded.

There is a similar non-standard ldaps: URL scheme for LDAP over SSL. This should not be
confused with LDAP with TLS, which is achieved using the StartTLS operation using the
standard ldap: scheme.

[edit] Schema
The contents of the entries in a subtree are governed by a schema known as a directory
information tree (DIT).

The schema of a Directory Server defines a set of rules that govern the kinds of information
that the server can hold. It has a number of elements, including:

 Attribute Syntaxes—Provide information about the kind of information that can be stored in
an attribute.
 Matching Rules—Provide information about how to make comparisons against attribute
values.
 Matching Rule Uses—Indicate which attribute types may be used in conjunction with a
particular matching rule.
 Attribute Types—Define an OID and a set of names that may be used to refer to a given
attribute, and associates that attribute with a syntax and set of matching rules.
  Object Classes—Define named collections of attributes and classify them into sets of
required and optional attributes.
 Name Forms—Define rules for the set of attributes that should be included in the RDN for an
entry.
 Content Rules—Define additional constraints about the object classes and attributes that
may be used in conjunction with an entry.
 Structure Rule—Define rules that govern the kinds of subordinate entries that a given entry
may have.

Attributes are the elements responsible for storing information in a directory, and the schema
defines the rules for which attributes may be used in an entry, the kinds of values that those
attributes may have, and how clients may interact with those values.

Clients may learn about the schema elements that the server supports by retrieving an
appropriate subschema subentry.

The schema defines object classes. Each entry must have an objectClass attribute, containing
named classes defined in the schema. The schema definition of the classes of an entry defines
what kind of object the entry may represent - e.g. a person, organization or domain. The
object class definitions also define the list of attributes that must contain values and the list of
attributes which may contain values.

For example, an entry representing a person might belong to the classes "top" and "person".
Membership in the "person" class would require the entry to contain the "sn" and "cn"
attributes, and allow the entry also to contain "userPassword", "telephoneNumber", and other
attributes. Since entries may have multiple ObjectClasses values, each entry has a complex of
optional and mandatory attribute sets formed from the union of the object classes it
represents. ObjectClasses can be inherited, and a single entry can have multiple
ObjectClasses values which define the available and required attributes of the entry itself. A
parallel to the schema of an objectClass is a class definition and an instance in Object-
oriented programming, representing LDAP objectClass and LDAP entry, respectively.

Directory servers may publish the directory schema controlling an entry at a base DN given
by the entry's subschemaSubentry operational attribute. (An operational attribute describes
operation of the directory rather than user information and is only returned from a search
when it is explicitly requested.)

Server administrators can add additional schema entries in addition to the provided schema
elements. A schema for representing individual people within organizations is termed a white
pages schema.

[edit] Variations
A lot of the server operation is left to the implementor or administrator to decide.
Accordingly, servers may be set up to support a wide variety of scenarios.

For example, data storage in the server is not specified - the server may use flat files,
databases, or just be a gateway to some other server. Access control is not standardized,
though there has been work on it and there are commonly used models. Users' passwords
may be stored in their entries or elsewhere. The server may refuse to perform operations
when it wishes, and impose various limits.

Most parts of LDAP are extensible. Examples: One can define new operations. Controls may
modify requests and responses, e.g. to request sorted search results. New search scopes and
Bind methods can be defined. Attributes can have options that may modify their semantics.

[edit] Other data models

As LDAP has gained momentum, vendors have provided it as an access protocol to other
services. The implementation then recasts the data to mimic the LDAP/X.500 model, but how
closely this model is followed varies. For example, there is software to access SQL databases
through LDAP, even though LDAP does not readily lend itself to this.[7] X.500 servers may
support LDAP as well.

Similarly, data which were previously held in other types of data stores are sometimes moved
to LDAP directories. For example, Unix user and group information can be stored in LDAP
and accessed via PAM and NSS modules. LDAP is often used by other services for
authentication.

[edit] Usage
[edit] Naming structure

Since an LDAP server can return referrals to other servers for requests the server itself will
not/can not serve, a naming structure for LDAP entries is needed so one can find a server
holding a given DN. Since such a structure already exists in the Domain name system (DNS),
servers' top level names often mimic DNS names, as they do in X.500.

If an organization has domain name example.org, its top level LDAP entry will typically have
the DN dc=example,dc=org (where dc means domain component). If the LDAP server is
also named ldap.example.org, the organization's top level LDAP URL becomes
ldap://ldap.example.org/dc=example,dc=org.

Below the top level, the entry names will typically reflect the organization's internal structure
or needs rather than DNS names.

[edit] Terminology
The LDAP terminology one can encounter is rather cumbersome. Some of this is due to
misunderstandings, other examples are due to its historical origins, others arise when used
with non-X.500 services that use different terminology. For example, "LDAP" is sometimes
used to refer to the protocol, other times to the protocol and the data. An "LDAP directory"
may be the data or also the access point. An "attribute" may be the attribute type, or the
contents of an attribute in a directory, or an attribute description (an attribute type with
options). An "anonymous" and an "unauthenticated" Bind are different Bind methods that
both produce anonymous authentication state, so both terms are being used for both variants.
3. Can you connect Active Directory to other 3rd-party Directory
Services? Name a few options.
4. Where is the AD database held? What other folders are related
to AD?
5. What is the SYSVOL folder?
6. Name the AD NCs and replication issues for each NC
7. What are application partitions? When do I use them
8. How do you create a new application partition
9. How do you view replication properties for AD partitions and
DCs?
10. What is the Global Catalog?
11. How do you view all the GCs in the forest?
12. Why not make all DCs in a large forest as GCs?
13. Trying to look at the Schema, how can I do that?
14. What are the Support Tools? Why do I need them?
15. What is LDP? What is REPLMON? What is ADSIEDIT?
What is NETDOM? What is REPADMIN?
16. What are sites? What are they used for?
17. What’s the difference between a site link’s schedule and
interval?
18. What is the KCC?
19. What is the ISTG? Who has that role by default?
20. What are the requirements for installing AD on a new
server?
21. What can you do to promote a server to DC if you’re in a
remote location with slow WAN link?
22. How can you forcibly remove AD from a server, and what
do you do later? • Can I get user passwords from the
AD database?
23. What tool would I use to try to grab security related
packets from the wire?
24. Name some OU design considerations.
25. What is tombstone lifetime attribute?
26. What do you do to install a new Windows 2003 DC in a
Windows 2000 AD?
27. What do you do to install a new Windows 2003 R2 DC in
a Windows 2003 AD?
28. How would you find all users that have not logged on
since last month?
29. What are the DS* commands?
30. What’s the difference between LDIFDE and CSVDE?
Usage considerations?
31. What are the FSMO roles? Who has them by default?
What happens when each one fails?
32. What FSMO placement considerations do you know of?
33. I want to look at the RID allocation table for a DC. What
do I do?
34. What’s the difference between transferring a FSMO role
and seizing one? Which one should you NOT seize? Why?
35. How do you configure a “stand-by operation
master” for any of the roles?
36. How do you backup AD?
37. How do you restore AD?
38. How do you change the DS Restore admin password?
39. Why can’t you restore a DC that was backed up 4 months
ago?
40. What are GPOs?
41. What is the order in which GPOs are applied?
42. Name a few benefits of using GPMC.
43. What are the GPC and the GPT? Where can I find them?
44. What are GPO links? What special things can I do to
them?
45. What can I do to prevent inheritance from above?
46. How can I override blocking of inheritance?
47. How can you determine what GPO was and was not
applied for a user? Name a few ways to do that.
48. A user claims he did not receive a GPO, yet his user and
computer accounts are in the right OU, and everyone else there
gets the GPO. What will you look for?
49. Name a few differences in Vista GPOs
50. Name some GPO settings in the computer and user parts.
51. What are administrative templates?
52. What’s the difference between software publishing and
assigning?
53. Can I deploy non-MSI software with GPO?
54. You want to standardize the desktop environments
(wallpaper, My Documents, Start menu, printers etc.) on the
computers in one department. How would you do that?
Different Types of DNS Records With Syntax and Examples

Types of DNS Records

A
AAAA
CNAME
MX
PTR
NS
SOA
SRV
TXT
NAPTR

The above DNS records are mostly used in all DNS Configurations. Now we will see
each one with examples.

A Record

An A record or address record.

Address Record, assigns an IP address to a domain or subdomain name. When the

domain name system was designed it was recommended that no two A records refer
to the same IP address.

Suppose you have the somedomain.tld domain and want to assign 10.10.0.1 IP
address to your web server, then you should create an A record with
"www.somedomain.tld" as Fully Qualified Domain Name and "10.10.0.1" in the value
field.

From now on, all the requests for www.somedomain.tld will be sent to a server with
that IP.

Basically is useful to use an A record when you have subdomains residing on various
systems.

Usefultip: you might use a "*.somedomain.tld" A record to allow

WHATEVER.somedomain.tld to be resolved to your IP, though a wildcard CNAME
record is often better than a wildcard A record.

Example of A Record with Syntax

example.com. IN A 69.9.64.11

Where
IN indicates Internet

A indicates the Address record.

The above example indicate that the IP Address for the domain example.com is
69.9.64.11

AAAA Record

An AAAA record or IPv6 address record maps a hostname to a 128-bit IPv6 address.

The regular DNS Address resource record is defined for a 32-bit IPv4 address, so a
new one was created to allow a domain name to be associated with a 128-bit IPv6
address. The four “A”s (“AAAA”) are a mnemonic to indicate that the IPv6 address is
four times the size of the IPv4 address. The AAAA record is structured in very much
the same way as the A record in both binary and master file formats; it is just much
larger. The DNS resource record Type value for AAAA is 28.

Example of AAAA Record with Syntax

The AAAA record is to help transition and coexistence between IPv4 and IPv6
networks.An IPv4 nameserver can provide IPv6 addresses:

linux aaaa 3ffe:1900:4545:2:02d0:09ff:fef7:6d2c

CNAME Record

A CNAME record or canonical name record makes one domain name an alias of
another. The aliased domain gets all the subdomains and DNS records of the original.

You should use a CNAME record whenever you want associate a new subdomain to
an already existing A record; i.e. you can make "www.somedomain.tld" to
"somedomain.tld", which should already have been assigned an IP with an A record.

This allows you to have as many subdomains as you wish without having to specify
the IP for every record. Use a CNAME if you have more services pointing to the same
IP. This way you will have to update only one record in the convenience of a change
of IP address.

Example of a CNAME record: "stuff.everybox.com CNAME www.everybox.com" where

'www.everybox.com' is an A record listing an IP address, and 'stuff.everybox.com'
points to 'www.everybox.com'. It will NOT allow you to foward a domain to a specific
web page. Use a webhop for that. Port numbers can be changed with webhops, as
well; CNAMEs cannot change the HTTP default of 80 to any other port number.

Do not use CNAME defined hostnames in MX records. For example, this is not
recommended

Example Of CNAME With syntax

mail.example.com IN CNAME mail.example.net

where

IN indicates Internet
CNAME indicates CNAME record.

MX Record

An MX record or mail exchange record maps a domain name to a list of mail

exchange servers for that domain.

Example with MX Record Syntax - Single mail servers

mydomain.com. 14400 IN MX 0 mydomain.com.

The MX record shows that all emails @ mydomain.com should be routed to the mail
server at mydomain.com. The DNS record shows that mydomain.com is located at
26.34.9.14. This means that email meant for [email protected] will be routed to
the email server at 26.34.9.14. This finishes the task of the MX record. The email
server on that server then takes over, collects the email and then proceeds to
distribute it to the user ``test''.

It is important that there be a dot(``.'') after the domain name in the MX record. If
the dot is absent, it routes to ``mydomain.com.mydomain.com''. The number 0,
indicates Preferance number. Mail is always routed to the server which has the lowest
Preferance number. If there is only one mail server, it is safe to mark it 0.

Using Multiple mail servers

If you want to use multiple mail servers you have to use MX record preferences.The
MX record preference values indicate which mail server to use and in which order to
try them when they fail or don't respond. A larger preference number is less
preferred. Thus, a mail exchanger with a preference of zero (0) is always preferred
over all other mail exchangers. Setting preference values to equal numbers makes
mail servers equally preferred.

Example with MX Record Syntax - Multiple mail servers

mydomain.com. 14400 IN MX 0 mydomain.com.

mydomain.com. 14400 IN MX 30 server2.mydomain.com

You can have unlimited MX entries for Fallback or backup purpose.If all the MX
records are equal Preference numbers, the client simply attempts all equal
Preference servers in random order, and then goes to MX record with the next
highest Preference number.

PTR Record

A PTR record or pointer record maps an IPv4 address to the canonical name for that
host. Setting up a PTR record for a hostname in the in-addr.arpa domain that
corresponds to an IP address implements reverse DNS lookup for that address. For
example www.name.net has the IP address 122.0.3.16, but a PTR record maps
16.3.0.122.in-addr.arpa.

Example of PTR Record with syntax

16.3.0.122.in-addr.arpa. IN PTR name.net

Here as you see the IP Address is reversed and added with in-addr.arpa and this has
come to the left side while the actual domain name has gone to right side of IN PTR.
This is mostly used as a security and an anti-spam measure wherein most of the
webservers or the email servers do a reverse DNS lookup to check if the host is
actually coming from where it claims to come from. It is always advisable to have a
proper reverse DNS record (PTR) is been setup for your servers especially when you
are running a mail / smtp server.

NS Record

An NS record or name server record maps a domain name to a list of DNS servers
authoritative for that domain. Delegations depend on NS records.

NS Record Name Server Record which indicates the Authoritative Name Servers for a
particular Domain. The NS records of the Authoritative Name Server for any given
Domain will be listed on the Parent Server. These are called as the Delegation
Records as these records on the Parent Server indicates the delegation of the domain
to the Authoritative servers.

The NS record will also be listed in the Zone records of the Authoritative Name
Server itself. These records are called as the Authoritative Records.

The NS records found on the Parent Server should match the NS records on the
Authoritative Server as well. However, you can have NS records listed on the
Authoritative server that is not listed in the Parent Server. This arrangement is
normally used to configure Stealth Name Servers.

Example of NS Record With syntax

example.com. IN NS ns1.live.secure.com.

where

IN indicates the Internet

NS indicates the type of record which Name Server record

The above indicates that the ns1.live.secure.com is the authoritative server for the
domain example.com

SOA Record

An SOA record or start of authority record specifies the DNS server providing
authoritative information about an Internet domain, the email of the domain
administrator, the domain serial number, and several timers relating to refreshing
the zone.

An SOA(State of Authority) Record is the most essential part of a Zone file. The SOA
record is a way for the Domain Administrator to give out simple information about
the domain like, how often it is updated, when it was last updated, when to check
back for more info, what is the admins email address and so on. A Zone file can
contain only one SOA Record.

A properly optimized and updated SOA record can reduce bandwidth between
nameservers, increase the speed of website access and ensure the site is alive even
when the primary DNS server is down.

Example of SOA Record with syntax

Here is the SOA record. Notice the starting bracket ``(``. This has to be on the
same line, otherwise the record gets broken.

; name TTL class rr Nameserver email-address

mydomain.com. 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com. (
2004123001 ; Serial number
86000 ; Refresh rate in seconds
7200 ; Update Retry in seconds
3600000 ; Expiry in seconds
600 ; minimum in seconds )

name - mydomain.com is the main name in this zone.

TTL - 14400 - TTL defines the duration in seconds that the record may be cached by
client side programs. If it is set as 0, it indicates that the record should not be
cached. The range is defined to be between 0 to 2147483647 (close to 68 years !) .

Class - IN - The class shows the type of record. IN equates to Internet. Other options
are all historic. So as long as your DNS is on the Internet or Intranet, you must use
IN.

Nameserver - ns.nameserver.com. - The nameserver is the server which holds the

zone files. It can be either an external server in which case, the entire domain name
must be specified followed by a dot. In case it is defined in this zone file, then it can
be written as ``ns'' .

Email address - root.ns.nameserver.com. - This is the email of the domain name

administrator. Now, this is really confusing, because people expect an @ to be in an
email address. However in this case, email is sent to [email protected], but
written as root.ns.nameserver.com . And yes, remember to put the dot behind the
domain name.

Serial number - 2004123001 - This is a sort of a revision numbering system to show

the changes made to the DNS Zone. This number has to increment , whenever any
change is made to the Zone file. The standard convention is to use the date of
update YYYYMMDDnn, where nn is a revision number in case more than one updates
are done in a day. So if the first update done today would be 2005301200 and
second update would be 2005301201.

Refresh - 86000 - This is time(in seconds) when the slave DNS server will refresh
from the master. This value represents how often a secondary will poll the primary
server to see if the serial number for the zone has increased (so it knows to request
a new copy of the data for the zone). It can be written as ``23h88M'' indicating 23
hours and 88 minutes. If you have a regular Internet server, you can keep it
between 6 to 24 hours.

Retry - 7200 - Now assume that a slave tried to contact the master server and failed
to contact it because it was down. The Retry value (time in seconds) will tell it when
to get back. This value is not very important and can be a fraction of the refresh
value.

Expiry - 3600000 - This is the time (in seconds) that a slave server will keep a
cached zone file as valid, if it can't contact the primary server. If this value were set
to say 2 weeks ( in seconds), what it means is that a slave would still be able to give
out domain information from its cached zone file for 2 weeks, without anyone
knowing the difference. The recommended value is between 2 to 4 weeks.

Minimum - 600 - This is the default time(in seconds) that the slave servers should
cache the Zone file. This is the most important time field in the SOA Record. If your
DNS information keeps changing, keep it down to a day or less. Otherwise if your
DNS record doesn't change regularly, step it up between 1 to 5 days. The benefit of
keeping this value high, is that your website speeds increase drastically as a result of
reduced lookups. Caching servers around the globe would cache your records and
this improves site performance.

SRV Record

The theory behind SRV is that given a known domain name e.g. example.com, a
given service e.g. web (http) which runs on tcp in this case, a DNS query may be
issued to find the host name that provides such on behalf of the domain - and which
may or may not be within the domain.

Example of SRV Record with syntax

srvce.prot.name ttl class rr pri weight port target

_http._tcp.example.com. IN SRV 0 5 80 www.example.com.

srvce

Defines the symbolic service name (see IANA port-numbers) prepended with a '_'
(underscore). Case insensitive. Common values are:

_http - web service

_ftp - file transfer service
_ldap - LDAP service

prot

Defines the protocol name (see IANA service-names) prepended with a '_'
(underscore). Case insensitive. Common values are

_tcp - TCP protocol

_udp - UDP protocol

name

Incomprehensible description in RFC 2782. Leaving the entry blank (without a dot)
will substitute the current zone root (the $ORIGIN), or you can explicitly add it as in
the above _http._tcp.example.com. (with a dot).

ttl

Standard TTL parameter. For more information about TTL values.

pri

The relative Priority of this service (range 0 - 65535). Lowest is highest priority.

weight

Used when more than one service with same priority. A 16 bit unsigned integer in the
range 0 - 65535. The value 0 indicates no weighting should be applied. If the weight
is 1 or greater it is a relative number in which the highest is most frequently
delivered i.e. given two SRV records both with Priority = 0, one with weight = 1 the
other weight = 6, the one with weight 6 will have its RR delivered first 6 times out of
7 by the name server.

port

Normally the port number assigned to the symbolic service but does this is not a
requirement e.g. it is permissible to define a _http service with a port number of
8100 rather than the more normal port 80.

target

The name of the host that will provide this service. Does not have to be in the same
zone (domain).

TXT Record

A TXT record allows an administrator to insert arbitrary text into a DNS record. For
example, this record is used to implement the Sender Policy Framework specification.

Example of TXT Record with syntax

SPF domains have to publish at least two directives: a version identifier and a default
mechanism.

mydomain.com. TXT "v=spf1 -all"

This is the simplest possible SPF record: it means your domain mydomain.com never
sends mail.

It makes sense to do this when a domain is only used for web services and doesn't
do email.

MX servers send mail, designate them.

mydomain.com. TXT "v=spf1 mx -all"

Let's pretend mydomain.com has two MX servers, mx01 and mx02. They would both
be allowed to send mail from mydomain.com.

other machines in the domain also send mail, designate them.

mydomain.com. TXT "v=spf1 mx ptr -all"

This designates all the hosts whose PTR hostname match mydomain.com.

any other machines not in the domain also send mail from that domain, designate
them.

mydomain.com. TXT "v=spf1 a:mydomain.com mx ptr -all"

mydomain.com's IP address doesn't show up in its list of MX servers. So we add an

"a" mechanism to the directive set to match it.

mydomain.com. TXT "v=spf1 a mx ptr -all"

This is shorthand for the same thing.

Each of your mail servers should have an SPF record also.When your mail servers
create a bounce message, they will send it using a blank envelope sender: <>. When
an SPF MTA sees a blank envelope sender, it will perform the lookup using the HELO
domain name instead. These records take care of that scenario.

amx.mail.net. TXT "v=spf1 a -all"

mx.mail.net. TXT "v=spf1 a -all"

NAPTR Record

NAPTR records (NAPTR stands for "Naming Authority Pointer") are a newer type of
DNS record that support regular expression based rewriting.

Example of NAPTR Record with syntax

$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.

NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:[email protected]!" .

NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:[email protected]!" .
NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:[email protected]!" .

This record set maps the phone number +441632960083 onto three possible
identically ordered URIs, with a preference for SIP, then H323, and finally email. In
each case, the regular expression matches the full AUS (^.$), and replaces it with a
URI (e.g., sip:[email protected]). As this is a terminal record, this URI is returned
to the client.Though most NAPTR records replace the full AUS, it is possible for the
regular expression to back-reference part of the AUS, to grab an extension number,
say:

$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. *

NAPTR 10 100 "u" "E2U+sip""!^+441632960(.*)$!sip:\[email protected]!" .

Once the client has the URI it must be resolved using DNS, but this is no longer part
of the DDDS algorithm..

wildcard DNS record

A wildcard DNS record is a record in a DNS zone file that will match all requests for
non-existent domain names, i.e. domain names for which there are no records at all.