DNS Questions

Q) Describe a few methods of finding an MX record for a remote domain on the

Internet?

In order to find MX Records for SMTP domains you can use Command-line tools such
as NSLOOKUP or DIG. You can also use online web services that allow you to
perform quick searches and display the information in a convenient manner.


Q) What does "Disable Recursion" in DNS mean?

If you disable recursion on the DNS server, you cannot use forwarders on the same
server.



Q) What could cause the Forwarders and Root Hints to be grayed out?


You may have an authoritative DNS server running. This means it won't forward and
it won't look to your root hint DNS servers to resolve anything outside it's own
domains. To fix this, delete the zone "." Yes, that's a dot, a period. When you
remove this zone your server will allow you to forward and it will use root hints. Also,
make sure your 2K AD/DNS box is using itself as it's primary DNS server. You may
need to reboot and give it some time to populate the root hints. If it doesn't do this
fast enough for you, you can add them manually.


Q) What is the "in-addr.arpa" zone used for?

DNS has a few special cases you need to be aware of. Probably the most important
of these is the in-addr.arpa domain, which is used to convert 32-bit numeric IP
addresses back into domain names.


Q) What are the requirements from DNS to support AD?


In order for a DNS server to be able to support Active Directory, the server is
required to support the service (SRV) resource record type and the dynamic update
protocol, as described in the RFC 2136. Active Directory uses DNS as the location
mechanism for domain controllers, enabling computers on the network to obtain IP
addresses of domain controllers. During the installation of Active Directory, the
service (SRV) and address (A) resource records are dynamically registered in DNS.
Both types of records are necessary for the functionality of the domain controller
locator (Locator) mechanism.
To find domain controllers in a domain or forest, a client queries DNS for the SRV
and A DNS resource records of the domain controller. The resource records provide
the client with the names and IP addresses of the domain controllers. In this context,
the SRV and A resource records are referred to as Locator DNS resource records.
When a domain controller is added to a forest, a DNS zone hosted on a DNS server is
updated with the Locator DNS resource records for that domain controller. For this
reason, the DNS zone must allow dynamic updates (RFC 2136), and the DNS server
hosting that zone must support the SRV resource records (RFC 2782) to advertise
the Active Directory directory service.
At the very least, the DNS server must support the SRV resource record; but the
SRV resource records can be added to DNS manually. After installing Active Directory,
these records can be found on the domain controller in the following location:
systemroot\System32\Config\Netlogon.dns.


Q) Name 3 benefits of using AD-integrated zones?


Fault tolerance - Standard zones rely on zone transfers for replication, a process
that requires the primary server to send updates to the secondary server. If a
primary server goes offline, there is no way to promote a secondary server to
become a primary, and updates do not occur again until the primary server is
brought online. With Ad integrated zones, there isnt the same single point of failure.


Security- AD integrated zones do not store zone information in a text file as
standard primary and secondary zones do, and in addition, zone updates can be set
so that only secure updates are allowed.



Integrated replication- Because the DNS zone is integrated into AD, it is replicated
through the normal AD replication process. Standard zones would require creating an
additional replication topology for DNS


Q) What is Round robin?

Round robin is a load balancing mechanism used by DNS servers to share and
distribute network resource loads.




Q) What is PTR record?

PTR record is typically used to perform reverse lookups of ip address to host name
mappings.


Q) What is A (host) record?

Host record (A) maps a DNS Domain name and the clients name to a single 32 bit ip
V4 address.


Q) Canonical Name (CNAME) or Alias records?

A Canonical Name (CNAME) or Alias record allows a DNS server to have multiple
names for a single host. For example, an Alias record can have several records that
point to a single server in your environment. This is a common approach if you have
both your Web server and your mail server running on the same machine.



Q) Mail Exchange (MX) records?

Mail Exchange records help you identify mail servers within a zone in your DNS
database. With this feature, you can prioritize which mail servers will receive the
highest priority. Creating MX records will help you keep track of the location of all of
your mail servers.


Q) What is Name server (NS) record?

The NS record identify the DNS server that are authoritative for the zone and are
accompanied by the appropriate address (A) records and pointer PTR) records.



Q) What is start of authority (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

Q) What is AAA record?

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


Q) What is DNS Spoofing?

DNS spoofing is term used when a DNS server accepts and uses incorrect
information from a host that has no authority to giving that information.



Q) What is a Root hint?

A file that is provided within the DNS software in Windows 2000/2003. This file
points to the 13 Root servers on the internet and allows for public name resolution.

- The file name is .,.0/38 and is located in <systemrooy>\system32\dns.
- This file can be managed using a notepad. Extra entries can be added.

Q) Types of DNS Zones with explanation?

Types of DNS Zones
A zone is a contiguous portion of DNS namespace managed by one or more name
servers. Zones contain resource records that specify the name of the DNS server
authoritative for the zone (SOA record), the names and IP addresses of all name
servers in the zone (NS records), the names and IP addresses of other hosts (A
records), aliases for hosts (CNAME records), and so on.
In the original implementation of DNS found in RFCs 1034 and 1035, two different
types of zones were defined:
O Primary zones, which store their zone information in a writable text file on the
name server.
O Secondary zones, which store their zone information in a read-only text file
on the name server.
In the implementation of DNS on Windows NT, these two types of zones were
referred to as standard zones. A typical scenario for a company that had a single
Windows NT domain deployed would involve setting up two name servers on the
network, one containing the standard primary zone (the primary name server for the
domain) and the other containing the standard secondary zone (the secondary name
server). Whenever a new host (for example, a file server) was added to the network,
both these name servers had to be updated so clients could find the new host using
DNS. To do this, the administrator would create a new A record on the primary name
server since the only the primary zone could be modified. The primary name server
would then notify the secondary that its records had changed, and the secondary
would pull the updated zone information from the primary until it had an identical
copy of the primary zone. From the perspective of the secondary name server, the
primary name server represents the master name server for this zone.
The main problem with this arrangement was that if the primary name server went
down, no changes could be made to the resource records since secondary name
servers contained read-only zone information. Also, it meant that all the changes you
made to DNS had to be performed on a single name server (the primary), which
could be an inconvenience if the company spanned several locations.
Windows 2000 provided a solution to these issues by introducing Active Directory
Integrated zones, which stored their zone information within Active Directory instead
of text files. The advantages of this new type of zone included using Active Directory
replication for zone transfers and allowing resource records to be added or modified
on any domain controller running DNS. In other words, all Active Directory
Integrated zones are always primary zones as they contain writable copies of the
zone database.
Active Directory Integrated zones work well for most Windows 2000-based
networks, but they do have some issues. One limitation is if you are dealing with two
separate forests (disjointed namespace), a common scenario when companies are
merging or form part of a conglomerate. For example, say Company A has close
business ties with Company B and employees in Company A need access to
resources on Company B's internal network. The usual way of providing them this
access would be for the DNS administrator of Company A to add a standard
secondary zone on each of Company A's name servers. These secondary zones
would then point to name servers on Company B's network as their master name
servers, and would obtain their resource records by zone transfers with Company B's
name servers. While that works, it's overkill for several reasons. First, it generates a
lot of zone transfer traffic between name servers in Company A and Company B,
which can pose a problem if the companies are linked together by a slow WAN
connection. Second, if Company B decides to decommission one of its name servers
without telling the administrator of Company A, some of the secondary zones on
Company A's name servers could suddenly find themselves without a master, and
once their records expire the Company A clients that use them will no longer be able
to access resources in Company B.
What Stub Zones Do
Enter stub zones to the rescue. A stub zone is like a secondary zone in that it obtains
its resource records from other name servers (one or more master name servers). A
stub zone is also read-only like a secondary zone, so administrators can't manually
add, remove, or modify resource records on it. But the differences end here, as stub
zones are quite different from secondary zones in a couple of significant ways.
First, while secondary zones contain copies of all the resource records in the
corresponding zone on the master name server, stub zones contain only three kinds
of resource records:
O A copy of the SOA record for the zone.
O Copies of NS records for all name servers authoritative for the zone.
O Copies of A records for all name servers authoritative for the zone.
That's it--no CNAME records, MX records, SRV records, or A records for other hosts
in the zone. So while a secondary zone can be quite large for a big company's
network, a stub zone is always very small, just a few records. This means replicating
zone information from master to stub zone adds almost nil DNS traffic to your
network as the records for name servers rarely change unless you decommission an
old name server or deploy a new one. And to make replication even more efficient,
stub zones don't use UDP as traditional DNS zone transfers do. Instead, stub zones
use TCP, which supports much larger packet sizes than UDP. So while a typical zone
transfer might involve many UDP packets flooding the network, stub zone transfer
only involves a few packets at most. Also, while most DNS servers can be configured
to prevent zone transfers to secondary zones from occurring, stub zones request
only SOA, NS, and A records for name servers, all of which are provided without
restriction by any name server since these records are essential for name resolution
to function properly. Finally, since stub zones can be integrated within Active
Directory (secondary zones can't), they can make use of Active Directory replication
to propagate their information to all domain controllers on your network.
In our previous scenario, stub zones can be used instead of secondary zones to
reduce the amount of zone transfer traffic over the WAN link connecting the two
companies. To do this, the administrator for Company A would simply log on to one
of the domain controllers, open the DNS console, and create a new stub zone that
uses one or more of Company B's name servers as master name servers. By making
this stub zone an Active Directory Integrated zone, the stub zone will then be
automatically replicated to all other domain controllers on Company A's network.
Now when a client on Company A's network wants to connect to a resource on
Company B's network, the client issues a DNS query to the nearest Company A
domain controller, which then forwards the query to one of Company B's name
servers to resolve.
ow to Create a Stub Zone
Let's see how it works in practice. In my lab I have two forests set up, one for
Company A running Windows 2003 Server and named test2003.local, and the other
for Company B running Windows 2000 and named test2000.local. The domain
controller for the root domain of Company A is named SRV220 while the domain
controllers for the root domain of Company B are named SRV210, SRV211 and
SRV212. Sally is an employee of Company A and her desktop computer is named
DESK231, and she needs to access a share named CATALOG located on SRV210 in
Company B. To do this she clicks Start, selects Run, and types
\\srv210.test2000.local\catalog and the result is an error:

This is because her command issues a DNS query against her name server SRV220
which has no information in its DNS database about test2000.local, the root domain
of Company B:

To allow users in Company A to access resources in Company B, the administrator of
Company A decides to create a stub zone for Company B's domain. To do this, right-
click on Forward Lookup Zones in the figure above and select New Zone. This starts
the New Zone Wizard:

Clicking Next brings up the Zone Type screen, and we'll choose Stub Zone here and
select the checkbox to create an Active Directory Integrated stub zone:

Click Next and the Active Directory Zone Replication Scope screen is displayed, which
we'll leave at its default setting for automatic replication of stub zone information to
all domain controllers in the test2003.local domain.

Clicking Next displays the Zone Name screen, and here we type test2000.local as the
name of the stub zone since this is the name of the target domain on Company B's
network:

Clicking Next displays the Master DNS Servers screen, and we enter the IP address
172.16.11.210 for one of the name servers on Company B's network:

Clicking Next and then Finish runs the wizard and creates the new stub zone, which
here is highlighted in the DNS console connected to SRV220 on Company A's network:

Note in the above Iigure that as expected the stub zone contains only an SOA record, an
NS record Ior each name server in the domain, and an A record Ior each name server in
the domain. Now when Sally clicks Start, selects Run, and types
\\srv210.test2000.local\catalog a window opens up displaying the contents oI the
CATALOG share on SRV210 in the remote Iorest:

Summary
Stub zones are easy to create and can make name resolution between Iorests more
eIIicient, but they have other uses as well. For example, stub zones can enable name
servers to perIorm recursion without needing to query the Internet root name servers or
internal corporate root servers, thus decreasing the number oI hops between name servers
and making name resolution more eIIicient. Another use oI stub zones is to keep
delegated zone inIormation up to date and prevent lame delegations Irom wrecking name
resolution within a Iorest, and that would make a good topic Ior a Iuture article. Both oI
these are good topics Ior Iuture articles, so stay tuned Ior more on stub zones later.


Q) What is DNS Conditional Forwarding?

Conditional Iorwarding is a new Ieature oI DNS in Windows Server 2003 that can be
used to speed up name resolution in certain scenarios. They can also be used to help
companies resolve each other's namespace in a situation where companies collaborate a
merger is underway. This article will look in detail at how conditional Iorwarding works,
how to conIigure it, and when you might use it. But Iirst, let's brieIly review the concepts
oI Iorwarding and Iorwarders in traditional DNS, starting with diIIerent types oI name
queries.
Forwarders and Forwarding
When a name server is queried in DNS, the way it responds depends on the type oI query
issued, which can be either iterative or recursive. In an iterative query, the client asks the
name server Ior the best possible answer to its query. The name server checks its cache
and the zones Ior which it is authoritative and returns the best possible answer to the
client, which could be either a Iull answer like "here is the IP address oI the host you are
looking Ior" or a partial answer like "try this other name server instead, it might know the
answer." In a recursive query, things work a little diIIerent Ior here the client demands
either a Iull answer (the IP address oI the target host) or an error message like "sorry,
name not Iound." In Windows DNS, client machines always send recursive queries to
name servers, and name servers usually send iterative queries to other name servers.
Sometimes this process isn't enough however. A simple example is a company that has
Active Directory deployed on its internal network and uses a private top-level domain
like .local Ior its Iorest. For example, say a company has a single Active Directory
domain named test2003.local, a domain controller (and DNS server) named SRV220 and
has a dedicated connection to the Internet. A user named Bob goes to his desktop
computer named DESK231, opens Internet Explorer, and tries to access Google
(www.google.com). Here's what happens DNS-wise as Iar as name resolution is
concerned:
1. DESK231 sends a recursive query to SRV220 asking to resolve www.google.com
into its associated IP address.
2. SRV220 looks in its DNS database and Iinds zone inIormation only Ior the
test2003.local domain, realizes www.google.com is not part oI that domain,
decides it has no way oI knowing how to resolve www.google.com into an IP
address, and what happens next depends:
a. II, when you promoted your standalone server to the role oI domain
controller using dcpromo, your machine was disconnected Irom the
Internet and there were no other DNS servers on your network, then
dcpromo creates a root zone (".") in its DNS database that speciIies itselI
as the root name server Ior all DNS name resolution (that is, "the buck
stops here"). In this case, SRV220 realizes it can't answer the query and
returns a "name not Iound" error to the client and Bob can't open the
Google home page.
b. II however, when you promoted your server to a domain controller, your
machine was connected to the Internet, then Windows contacts the Iirst
available Internet root name server and downloads a list oI all Internet root
name servers, which becomes its list oI root hints. In that case name
resolution now continues as Iollows:
3. SRV220 sends an iterative query to the Iirst available Internet root name server,
which responds with the IP address oI a name server authoritative Ior the .com
top-level domain.
4. SRV220 sends a second iterative query to the name server authoritative Ior .com,
and this machine responds with the IP address oI a name server authoritative Ior
the google.com domain.
5. SRV220 sends a third iterative query to the name server authoritative Ior
google.com, and this machine responds with the IP address oI the host named
www.google.com.
6. SRV220 returns the IP address oI www.google.com to DESK231 and Bob sees
the Google home page appear in his browser.
Now that's a lot oI steps, and iI the company has a slow WAN link to the Internet then
you're using valuable bandwidth. A better approach than "going up to root" to resolve
www.google.com would be to conIigure a Iorwarder. A Iorwarder is a name server that
handles name queries that can't be resolved by another name server. Let's see how the
above scenario works when a Iorwarder is conIigured on the internal name server
SRV210:
1. DESK231 sends a recusrive query to SRV220 asking to resolve www.google.com
into its associated IP address.
2. SRV220 looks in its DNS database and Iinds zone inIormation only Ior the
test2003.local domain, realizes www.google.com is not part oI that domain,
decides it has no way oI knowing how to resolve www.google.com into an IP
address, and checks its list oI Iorwarders to see iI any Iorwarders have been
conIigured Ior it.
3. On the Iorwarders list it Iinds the IP address oI the external name server hosted by
the company's Internet Service Provider, so it Iorwards the query to the ISP's
name server to handle.
4. The ISP's name server goes up to root as needed (which can involve two or more
additional queries) to resolve www.google.com into its IP address and returns this
address to SRV220.
5. SRV220 returns the address to Bob and he sees Google appear in his browser.
Note that this procedure takes about the same number oI steps as beIore, but most oI
these steps are perIormed oIIsite by the ISP's name server, so the amount oI bandwidth
used over the Internet connection is considerably less and the processing load on the
internal name server SRV220 is minimized as well. And these are good things Irom an
administrator's perspective. OI course, iI the Iorwarder doesn't respond within the timeout
conIigured, the server can either try another Iorwarder (iI conIigured) or use root hints (iI
available) or give up and return an error.
On Windows 2000, Iorwarders are conIigured using the General tab oI the DNS server's
properties sheet in the DNS console:

What's diIIerent in Windows Server 2003 is the concept oI .onditional Iorwarding, which I'll look at next.
What Conditional Forwarding Does
A conditional Iorwarder is one that handles name resolution only Ior a speciIic domain.
For example, you could conIigure your name server to Iorward any requests Ior hosts in
the domain google.com directly to a speciIic name server that is authoritative Ior the
google.com domain. What this does is speed up the name resolution process by
eliminating the need to go up to root to Iind this authoritative server. In this case our
previous example would now look like this:
1. DESK231 sends a recusrive query to SRV220 asking to resolve www.google.com
into its associated IP address.
2. SRV220 looks in its DNS database and Iinds zone inIormation only Ior the
test2003.local domain, realizes www.google.com is not part oI that domain,
decides it has no way oI knowing how to resolve www.google.com into an IP
address, and checks its list oI Iorwarders to see iI any Iorwarders have been
conIigured Ior it.
3. On the Iorwarders list it Iinds a conditional Iorwarder conIigured, which speciIies
the IP address oI an authoritative name server Ior the google.com domain, so it
Iorwards the query to this name server to handle it.
4. The google.com name server immediately resolves www.google.com into its IP
address without the need oI going up to root and returns this address to SRV220.
5. SRV220 returns the address to Bob and Google quickly shows up in his browser,
prompting Bob to say, "Hey, the network sure is Iast today!"
Let's now see how to conIigure this in Windows Server 2003 DNS.
ow to Configure Conditional Forwarding
First let's Iind a name server authoritative Ior the google.com domain. To do this we'll use
the WHOIS lookup tool on the NetworkSolutions website at
http://www.networksolutions.com/enUS/whois/index.jhtml. Go to this page, type
google.com into the WHOIS search box, enter the code displayed (a Ieature that prevents
mass lookups by automated programs), and the Iollowing results are displayed:
google.com
Whois Server Version 1.
Domain names in the .com and .net domains can now be registered
with many diIIerent competing registrars. Go to http://www.internic.net
Ior detailed inIormation.
Domain Name: GOOGLE.COM
Registrar: ALLDOMAINS.COM INC.
Whois Server: whois.alldomains.com
ReIerral URL: http://www.alldomains.com
Name Server: NS2.GOOGLE.COM
Name Server: NS1.GOOGLE.COM
Name Server: NS3.GOOGLE.COM
Name Server: NS4.GOOGLE.COM
Status: REGISTRAR-LOCK
Updated Date: 03-oct-2002
Creation Date: 15-sep-1997
Expiration Date: 14-sep-2011
Let's Iind out the IP address oI name server NS1.GOOGLE.COM using ping:

Now that we have the IP address oI one oI the name servers authoritative Ior the
google.com domain, we can conIigure Windows Server 2003 DNS to conditionally
Iorward all name queries Ior this domain to this name server.
To conIigure conditional Iorwarding, open the DNS console under Administrative Tools,
right-click on the DNS server node, select properties to open the Properties sheet Ior the
DNS server, and select the Forwarding tab:

II you compare this to the previous Iigure Ior Windows 2000 DNS above, you'll see a Iew
diIIerences. First, iI you just want to conIigure a regular Iorwarder here, leave "All other
DNS domains" selected in the DNS domain listbox, enter the IP address oI the Iorwarder
(typically the address oI your ISP's name server) in the dotted box, and click Add. II you
want to add a conditional Iorwarder however, do the Iollowing. First, click the New
button and type the name oI the domain you want your name server to conditionally
Iorward to:

Click OK and the new domain appears in the top listbox (make sure it is selected Ior the
next step):

Now type the IP address oI your conditional Iorwarder into the dotted box and click Add
to add it to the selected domain's Iorwarders list:

Click OK to apply the change and close the properties sheet and you're done. Now any
name queries Ior the google.com domain that are issued against the name server are
Iorwarded directly to the name server Ior the google.com domain to resolve.
&sing Conditional Forwarding
When might you want to use conditional Iorwarding in the real world? I can think oI
several situations where it might be useIul:
O To improve name resolution between two separate companies that need to provide
their users with access to resources in the other company's intranet. This sort oI
situation is common in a merger situation or between supply-chain partners. Just
set up DNS servers in each company to Iorward name requests Ior resources in
the other company's network directly to the IP addresses oI name servers in the
other company and you're done. OI course, this can also be done using stub zones
as I discussed in my previous article DNS Stub Zones in Windows Server 2003
and I'll compare the two approaches in a moment.
O To improve name resolution within an Active Directory implementation that has a
disjointed namespace (separate Iorests or multiple domain trees) or a deep
hierarchy oI subdomains. In this kind oI situation you can set up conditional
Iorwarding so users in one domain can avoid having to go all the way to root to
Iind resources in a separate Iorest, another domain tree, or way down the domain
hierarchy in a tree. Again, stub zones could also be used Ior this purpose iI
desired.
O And then there's using it simply to Iorward name queries Ior speciIic Internet sites
like google.com as in the example above, but that example was meant only to be
illustrative oI the procedure Ior conIiguring conditional Iorwarding on your name
server--my company has no plans on merging with Google anytime soon.
Summary
Finally, is there anything you need to watch out Ior regarding using conditional
Iorwarding? Two things come to mind First, conditional Iorwarding is suitable iI you are
dealing with a Iixed DNS inIrastructure. That means in a merger or supply-chain scenario
you must be sure the other company doesn't plan on changing their DNS inIrastructure by
decommissioning old name servers, deploying new ones, or changing the IP addresses oI
existing ones. II they do change their inIrastructure and don't inIorm you oI this, then
your name server may suddenly Iind itselI Iorwarding queries to non-existing name
servers resulting in Iailed name queries and Irustrated users Ilooding help desk with calls.
In that case, it might be better to create stub zones on your name servers Ior zones Ior
which the other company's name servers are authoritative. That's because stub zones
automatically update themselves with the current list oI name servers in the zone while
conIiguring Iorwarders is a process that has to be done manually. Same thing in a large
enterprise that has a complex Active Directory Iorest--iI you aren't sure that
administrators in other divisions oI your company are going to tell you in advance when
they change their DNS inIrastructures, don't implement conditional Iorwarding--use stub
zones instead.
The second caveat concerning conditional Iorwarding is not to get to carried away
implementing it. You might think you could improve name resolution Ior your users by
adding dozens oI Iorwarders Ior the most popular Internet sites they use Ior work
purposes, but this might be a bad idea. The reason is, when you have a long list oI
conditional Iorwarders conIigured, your name server has to go through the entire list until
it either Iinds the domain requested or Iails to Iind it, in which case standard Iorwarding
is used (iI conIigured), aIter which root hints is tried and standard recursion employed.
The result oI this is that your name server has to perIorm extra processing to go through
the Iorwarders list each time a query is received, and in addition to increasing the CPU
load on your server this can also result in slower name resolution rather than Iaster due to
the time it takes to process an especially long list. And iI the Iorwarder itselI is also part
oI your own company's DNS inIrastructure then be aware that the added load oI receiving
Iorwarded queries Irom other name servers and perIorming recursive queries to resolve
them means your Iorwarders will experience especially heavy CPU utilization and may
need to have their hardware beeIed up considerably to handle it. So iI you do plan on
using conditional Iorwarding, particularly within your own enterprise, be sure to use it
only where it really makes a diIIerence and use it sparingly.