Jump to content

Recommended Posts

Posted

Hello Again,

Our Layout.

Internet | Novell Bordermanager | Lan Servers

All our AD servers are behind the firewall. Now due to a lack of funds we need to remove/alocate some new roles.

We currently have 2 AD DC's with DNS/WINS and on the second DHCP.

A single Server to host only Ext DNS with a secondary provided by our Service Provider.

Now the "proposed" plan is to remove our External DNS and allocate it a new Role as a WebServer.

Then uninstall internal DNS on one of our DC's and have that become our new External DNS (While AD is still running on that Box)

Now for the record i don't think this is a good idea. BUT hey what ru gonna do if the BOSS says DO IT.

So this is how i thought i'd go about it.

Seeing as our One AD DC will be without DNS i would point it now to our other AD DC with DNS still running. ( That part is still OK to me )

Now the problem for me is running external DNS on our AD server something about this doesn't seem a good idea.

The webserver will be running WebEdition.

Any help Advice "good practice" would be great

Thanks

Minus Human

  • 2 weeks later...

Posted

Best practices for DNS

Enter the correct e-mail address of the responsible person for each zone you add to or manage on a DNS server.

This field is used by applications to notify DNS administrators for a variety of reasons. For example, query errors, incorrect data returned in a query, and security problems are a few ways in which this field can be used. While most Internet e-mail addresses contain the at sign (@) when used in e-mail applications, this symbol must be replaced with a period (.) when entering an e-mail address for this field. For example, instead of "administrator@microsoft.com", you would use "administrator.microsoft.com".

For more information on configuring the responsible person for a zone, see To modify the start of authority (SOA) record for a zone.

Be conservative in adding alias records to zones.

Avoid using CNAME resource records (RRs) where they are not needed to alias a host name used in a host (A) resource record. Also, ensure that any alias names you use are not used in other RRs.

DNS allows an owner name of a CNAME resource record to be used as the owner name of the other types of resource records, such as NS, MX, and TXT resource records.

For more information, see Alias (CNAME) resource records.

When designing your DNS network use standard guidelines and, wherever possible, follow preferred practices for managing your DNS infrastructure.

DNS was designed to provide a level of fault tolerance for resolving names. If possible, you should have at least two name servers hosting each zone.

If you are using Active Directory, use directory-integrated storage for your DNS zones for increased security, fault tolerance, simplified deployment and management.

By integrating zones, you can simplify network planning. For example, domain controllers for each of your Active Directory domains correspond in a direct one-to-one mapping to DNS servers. This can simplify planning and troubleshooting DNS and Active Directory replication problems because the same server computers are used in both topologies.

If you are using directory-integrated storage for your zones, you may select from the different replication scopes that replicate your DNS zone data throughout the directory. If your DNS infrastructure must support Windows 2000 DNS servers, you will use the directory-integrated storage method that replicates DNS zone data to all domain controllers in a domain. If your DNS infrastructure is composed of DNS servers running Windows Server 2003 only, you may also select from replication scopes that replicate your DNS zone data to all DNS servers in the Active Directory forest, all DNS servers in a specified Active Directory domain, or all domain controllers specified in a custom replication scope.

For more information on directory-integrated DNS zone storage and replication options, see DNS zone replication in Active Directory.

Any DNS server hosting a directory-integrated zone is a primary DNS server for that zone. This enables a multimaster model where multiple DNS servers may update the same zone data. A multimaster model eliminates a single point of failure associated with a conventional single-master DNS topology, where updates may only be done to a single DNS server for a given zone.

One of the important benefits of directory integration is the support for secure dynamic update of the names within a zone. For more information, see Secure dynamic updates.

Consider the use of secondary zones to assist in off-loading DNS query traffic wherever it makes sense.

Secondary servers can be used as backups for DNS clients. This allows you to use secondary servers as a means to load balance DNS query traffic on your network and reserve your DNS-enabled primary servers for use only by those clients that need them to perform dynamic registration and updates of their A and PTR RRs.

For more information about the use of secondary or caching-only servers, see Using secondary servers and Using caching-only servers.

If you are planning a large DNS design, such as for a large Internet service provider (ISP) that supports the use of DNS, review the following Request for Comments (RFC) documents published by the Internet Engineering Task Force (IETF). RFC Title

1912 Common DNS Operational and Configuration Errors

2182 Selection and Operation of Secondary DNS Servers

2219 Use of DNS Aliases for Network Services

You can obtain these RFCs from the RFC Editor Web site. This Web site is currently maintained by members of the Information Sciences Institute (ISI) who publish a classified listing of all RFCs. RFCs are classified as one of the following: approved Internet standards, proposed Internet standards (circulated in draft form for review), Internet best practices, or For Your Information (FYI) documents.

Server planning for DNS

When planning for your DNS servers, it is important to consider the following:

Perform capacity planning and review server hardware requirements.

Determine how many DNS servers you need and their role in your network.

When deciding the number of DNS servers to use, decide which servers will host primary and secondary copies of zones. Also, if you are using Active Directory, determine whether the server computer will perform as a domain controller or a member server for the domain.

Decide where you are going to place DNS servers on your network for traffic loads, replication, and fault tolerance.

Decide whether to use only DNS servers running Windows Server 2003 for all your DNS servers or if you are operating a mixture of Windows and other DNS server implementations.

Server capacity planning

Planning and deploying DNS servers on your network involves examining several aspects of your network and the capacity requirements for any DNS servers you intend to use in it. Some questions to consider when planning include the following:

How many zones is the DNS server expected to load and host?

For each zone the server is loading for service, how large is the zone (based on the size of the zone file or the number of resource records used in the zone)?

For a multihomed DNS server, how many interfaces are to be enabled for listening to and servicing DNS clients on each of the server's connected subnets?

How many total or overall DNS query requests from all of its clients is a DNS server expected to receive and service?

In many cases, adding more RAM to a DNS server can provide the most noticeable improvements in performance. This is because the DNS Server service fully loads all of its configured zones into memory at startup. If your server is operating and loading a large number of zones, and dynamic updates occur frequently for zone clients, additional memory can be helpful.

Keep in mind that for typical usage, the DNS server consumes system memory as follows:

Approximately 4 MB of RAM is used when the DNS server is started without any zones.

For each addition of zones or resource records to the server, the DNS server consumes additional server memory.

It is estimated that for the addition of every resource record to a server zone, an average of approximately 100 bytes of server memory is used.

For example, if a zone containing 1000 resource records is added to a server, it would require approximately 100 KB (kilobytes) of server memory.

In determining your DNS server plans, you can start by reviewing sample DNS server performance test results collected by the DNS development and testing teams. In addition, you can use DNS server-related counters provided for use with monitoring tools to obtain your own performance measurements. For more information, see Monitoring DNS server performance.

Important

The previous recommendations are not intended to indicate maximum performance or limitations for DNS servers.

These numbers are approximate and can be influenced by the type of resource records entered in zones, the number of resource records with the same owner name, and the number of zones in use at a specific DNS server.

Where to place DNS servers

In general, place your DNS servers at a location on your network that is centrally accessible to your clients. It is often most practical to use a DNS server on each subnet. There are several factors to consider when deciding where a DNS server is needed:

If you are deploying DNS to support Active Directory, is the DNS server computer also a domain controller or likely to be promoted to one in the future?

If the DNS server stops responding, are its local clients able to gain access to an alternate DNS server?

If the DNS server is located on a subnet that is remote to some of its clients, what other DNS servers or name resolution options are available if the routed connection stops responding?

For DNS server installations where the use of Active Directory is an issue, review special interoperability issues and installation details. For more information, see DNS considerations for Active Directory.

For all DNS server installations including those in which the use of Active Directory is not an issue, the following server placement and planning guidelines can be usefully applied.

For example, if you have a routed local area network and high-speed links that are fairly reliable, you might be able to use one DNS server for a larger, multiple subnetted network area. If you have a high number of client nodes on a single subnet design, you might want to add more than one DNS server to the subnet to provide backup and failover if the preferred DNS server stops responding.

When determining the number of DNS servers you need to use, assess the effect of zone transfers and DNS query traffic on slower links in your network. Although DNS is designed to help reduce broadcast traffic between local subnets, it does create some traffic between servers and clients that should be reviewed, particularly when used in complexly routed LAN or WAN environments.

Consider the effects of zone transfer over slower speed links, like those typically used for a wide area network (WAN) connection. Although the DNS Server service supports incremental zone transfers and DNS clients and servers can cache recently used names, traffic considerations are sometimes still an issue, particularly when DHCP leases are shortened and, as a result, dynamic updates in DNS are performed more frequently. One option for dealing with remote locations on WAN links is to set up a DNS server at these locations to provide caching-only DNS service.

With most installations, you should have at least two server computers hosting each of your DNS zones for fault tolerance. DNS was designed to have two servers for each zone, one as a primary server and the other as a backup or secondary server. When making any final determinations about the number of servers to use, first assess the level of fault tolerance you need for your network.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...