Service (SRV) Records
SRV
records are RRs that indicate which resources perform a particular
service. Domain controllers in Active Directory are referenced by SRV
records that define specific services, such as the global catalog,
LDAP, and Kerberos. SRV records are relatively new additions to DNS and
did not exist in the original implementation of the standard. Each SRV
record contains information about a particular functionality that a
resource provides. For example, an LDAP server can add an SRV record
indicating that it can handle LDAP requests for a particular zone. SRV
records can be very useful for Active Directory because domain
controllers can advertise that they can handle GC requests.
Note
Because SRV records are a relatively new
addition to DNS, they are not supported by several down-level DNS
implementations, such as UNIX BIND 4.1 and NT 4.0 DNS. It is,
therefore, critical that the DNS environment that is used for Windows
Server 2012 Active Directory has the capability to create SRV records.
For UNIX BIND servers, version 8.1.2 or higher is required.
Alias Records
A
canonical name (CNAME) record represents a server alias or allows any
one of the member servers to be referred to by multiple names in DNS.
The record redirects queries made to the A record for the particular
host. CNAME records are useful when migrating servers, and for
situations in which friendly names, such as mail.companyabc.com, are required to point to more complex, server-naming conventions, such as sfoexch01.companyabc.com.
Caution
Though DNS entries for MX records can be
pointed to CNAME host records, doing so is not advised and is not a
Microsoft recommended best practice. Increased administrative overhead
and the possibility of misrouted messages can result. Microsoft
recommends that mail/DNS administrators always link MX records to fully
qualified principal names or domain literalss.
Other Records
Other,
less common forms of records that might exist in DNS have specific
purposes, and there might be cause to create them. The following is a
sample list, but it is by no means exhaustive:
• AAAA—Maps a standard IP address into a 128-bit IPv6 address. This type of record becomes more prevalent as IPv6 is adopted.
• ISDN—Maps a specific DNS name to an Integrated Services Digital Network (ISDN) telephone number.
• KEY—Stores a public key used for encryption for a particular domain.
• RP—Specifies the responsible person for a domain.
• WKS—Designates a particular well-known service.
• MB—Indicates which host contains a specific mailbox.
Multihomed DNS Servers
For
multihomed DNS servers, an administrator can configure the DNS service
to selectively enable and bind only to IP addresses that are specified
using the DNS console. By default, however, the DNS service binds to
all IP interfaces configured for the computer.
This can include the following:
• Any additional IP addresses configured for a single network connection.
•
Individual IP addresses configured for each separate connection where
more than one network connection is installed on the server computer.
•
For multihomed DNS servers, an administrator can restrict DNS service
for selected IP addresses. When this feature is used, the DNS service
listens for and answers only DNS requests that are sent to the IP
addresses specified on the Interface tab in the Server properties.
By
default, the DNS service listens on all IP addresses and accepts all
client requests sent to its default service port (UDP 53 or TCP 53 for
zone transfer requests). Some DNS resolvers require that the source
address of a DNS response be the same as the destination address that
was used in the query. If these addresses differ, clients could reject
the response. To accommodate these resolvers, you can specify the list
of allowed interfaces for the DNS server. When a list is set, the DNS
service binds sockets only to allowed IP addresses used on the computer.
In
addition to providing support for clients that require explicit
bindings to be used, specifying interfaces can be useful for other
reasons:
• If an administrator does not want to use some of the IP addresses or interfaces on a multihomed server computer
•
If the server computer is configured to use a large number of IP
addresses and the administrator does not want the added expense of
binding to all of them
When
configuring additional IP addresses and enabling them for use with the
Windows Server 2012 DNS server, consider the following additional
system resources that are consumed at the server computer:
• DNS server performance overhead increases slightly, which can affect DNS query reception for the server.
•
Although Windows Server 2012 provides the means to configure multiple
IP addresses for use with any of the installed network adapters, there
is no performance benefit for doing so.
•
Even if the DNS server is handling multiple zones registered for
Internet use, it is not necessary or required by the Internet
registration process to have different IP addresses registered for each
zone.
• Each additional address
might only slightly increase server performance. In instances when a
large overall number of IP addresses are enabled for use, server
performance can be degraded noticeably.
•
In general, when adding network adapter hardware to the server
computer, assign only a single primary IP address for each network
connection.
• Whenever possible, remove nonessential IP addresses from existing server TCP/IP configurations.
Using DNS to Route SMTP Mail in Exchange Server 2013
The
primary protocol for sending email on the Internet today is known as
Simple Mail Transfer Protocol, or SMTP. SMTP has been used for quite
some time in UNIX and Linux environments, and has been incorporated
into Active Directory as an alternative transport mechanism for site
traffic.
Domains that want to participate
in electronic mail exchange need to set up MX record(s) for their
published zone. This advertises the system that will handle mail for
the particular domain, so that SMTP mail will find the way to its
destination.
Understanding SMTP Mail Routing
After
the World Wide Web, email is arguably the second most widely used
TCP/IP and Internet application today. SMTP defines a set of rules for
addressing, sending, and receiving mail between systems. As a result of
a user mail request, the SMTP sender establishes a two-way connection
with the SMTP receiver. The SMTP receiver can be either the ultimate
destination or an intermediate (mail gateway). The SMTP sender
generates commands that are replied to by the receiver. All this
communication takes place over TCP port 25. When the connection is
established, a series of commands and replies are exchanged between the
client and server. This connection is similar to a phone conversation,
and the commands and responses are equivalent to verbal communication.
Note
In various implementations, there is a
possibility of exchanging mail between the TCP/IP SMTP mailing system
and the locally used mailing systems. These applications are called
mail gateways or mail bridges. Sending mail through a mail gateway may
alter the end-to-end delivery specification because SMTP guarantees
delivery only to the mail gateway host, not to the real destination
host, which is located beyond the TCP/IP network. When a mail gateway
is used, the SMTP end-to-end transmission is host-to-gateway,
gateway-to-host, or gateway-to-gateway; the behavior beyond the gateway
is not defined by SMTP.
Examining Client DNS Use for Exchange
Before
users can access their mailboxes on an Exchange server, they must be
authenticated. Authentication requires a DNS lookup to locate a domain
controller on which the users’ accounts can be authenticated.
Clients
normally cannot deliver messages directly to destination mail hosts.
They typically use a mail server to relay messages to destinations.
Using SMTP, clients connect to a mail server, which first verifies that
the client is allowed to relay through this server, and then accepts
the message destined for other domains.
A
client uses DNS to resolve the name of a mail server. For example, when
configuring an Outlook mail client to connect to an Exchange server,
only the short name and not the FQDN is used to connect to the server.
The short name is resolved by DNS to the FQDN of the Exchange server to
which the client is connected.
Understanding DNS Requirements for Exchange Server 2013
In
Active Directory, all client logons and lookups are directed to local
domain controllers and GC servers through references to the SRV records
in DNS. Each configuration has its DNS and resource requirements.
Exchange relies on other servers for client authentication and uses DNS
to find those servers. In an Active Directory domain controller
configuration, on the other hand, the Exchange server also participates
in the authentication process for Active Directory.
Using DNS in Exchange Server 2013
As
has been stated, Active Directory and DNS access are vital to an
Exchange implementation. It is critical that the host records for all
Exchange Server 2013 servers be properly registered and configured in
the DNS server for the Active Directory forest. Clients, as well as
other servers, will use DNS to locate and communicate with Exchange
Server 2013 servers.
Any computer acting
in one of the Exchange Server 2013 organizational server roles must be
a domain member and registered in DNS. The three server roles are as
follows:
• Edge Transport
• Client Access server
• Mailbox server
All server roles, with the exception of the Edge Transport, can be deployed on a single server.
Configuring Edge Transport Server DNS Settings
For
the Edge Transport server(s), which reside in the perimeter network, to
communicate with the Hub Transport servers in your Exchange
environment, they must be able to locate each other using host name
resolution. This is accomplished by creating host records in a forward
lookup zone on the internal DNS server that each server is configured
to query, or by editing the local hosts file for each server.
Before
installing the Edge Transport server role, you have to configure a DNS
suffix for the server name. After you have installed the Edge Transport
server role, the server name cannot be changed.
To complete this task, you must log on to the Edge Transport server as a user who is a member of the local Administrators group.
To use Windows Control Panel to configure the DNS suffix, complete the following steps:
1. Open Windows Control Panel.
2. Double-click on System to open the System page.
3. Click Advanced System Settings to open the System Properties dialog box.
4. Click the Computer Name tab.
5. Click Change.
6. On the Computer Name Changes page, click More.
7. In the Primary DNS Suffix of This Computer field, type a DNS domain name and suffix for the Edge Transport server.
DNS and SMTP RFC Standards
In
1984, the first DNS architecture was designed. The result was released
as RFC 882 and 883. These were superseded by RFC 1034 (Domain
Names—concepts and facilities) and 1035 (Domain Names—implementation
and specification), the current specifications of the DNS. RFCs 1034
and 1035 have been improved by many other RFCs, which describe fixes
for potential DNS security problems, implementation problems, best
practices, and performance improvements to the current standard.
RFCs 2821 and 2822 define SMTP, which replaced the earlier versions of RFCs 821 and 822.
