Question

In 3–4 paragraphs:

• Enumerate as many DNS errors as you can, and propose a method to detect one of them, or a small cluster of related ones.
• Analyze the errors you have chosen for their potential to be used as a deliberate or accidental attack (for example, a man-in-the middle attack).
• Propose a method to reduce or eliminate the risk. Since some problems are only truly fixed by updated software or infrastructure, there may be interim workarounds, so you may propose one of those, and those steps to improve security or stability may reduce the functionality of the systems.

Answer 1

1). ANSWER :

GIVENTHAT :

10 DNS Errors

1. TCP/IP Configuration Points to Public DNS Servers
This is by far the most common DNS error. Each network interface has a set of TCP/IP settings that lists the DNS servers used by that interface.

If the TCP/IP settings for a member computer specify the IP address of a public DNS server—perhaps at an ISP or DNS vendor or the company’s public-facing name server—the TCP/IP resolver won’t find Service Locator (SRV) records that advertise domain controller services, LDAP, Kerberos and Global Catalog. Without these records, a member computer can’t authenticate and get the information it needs to operate in the domain. It then acts like a teenager who can’t get the car keys, growing sullen and exhibiting a variety of bad behaviors.

2. Improper DNS Suffix Handling
Users treat additional keystrokes as if they were penalties visited upon them by uncaring IT bureaucrats. Imagine what would happen if you asked your users to type Fully Qualified Domain Names (FQDNs) rather than simple flat names to connect to internal servers. Quelle catastrophe, as we say in southern New Mexico. Users are willing to type www.ebay.com to buy a used wristwatch, but they don’t want to type \\w2k3s102.west.school.edu\ freshman_zclass to map a drive.

DNS servers, however, stubbornly insist that every query specify a target domain. How else could they select the proper zone file? Simplicity vs. utility: It’s a classic conundrum. The DNS resolver in Windows strikes a compromise. It accepts the flat name from the user then appends a suffix to form a FQDN it can send to a DNS server. The resolver obtains this DNS suffix from one of several places.

3. Improperly Configured Forwarding
Ordinarily, when a client confronts its DNS server with a request for a resource record in an outside domain, the DNS server searches for a name server in the target domain and submits the query to that server. This standard query resolution has a couple of problems. First, the internal server can get so preoccupied chasing down recursive queries for public hosts that it runs out of resources to handle queries for its own zones. Worse still, the internal server must reach through the firewall and connect to a variety of DNS servers, some of which could have traps that play malicious games with DNS requests.

An internal root server doesn’t need to waste energy or cause security problems by chasing referrals. Like a manager who doesn’t want to get dirty hands, it can let some other DNS server do the grunt work. This process is called forwarding. The server that gets the job of doing the recursive queries and delivering the results is called a forwarder.

4. Improper Zone Transfer Configuration
In a standard text-based DNS zone, only the primary master DNS server has full Read/Write access to the zone file. Secondary DNS servers hold read-only replicas of the zone file. A resource record called Start of Authority (SOA) identifies the primary master server.

Each change to the zone increments a serial number in the SOA record. Two zones in sync have matching SOA serial numbers. The primary master DNS server retains each zone change in a separate log file to use for iterative transfers. In iterative transfers, a secondary DNS server only pulls changes since the last zone transfer. The secondary servers keep track of zone changes using the SOA serial number.

5. Failure to Verify Dynamic Update of Resource Records
Every modern Windows client periodically registers its A and PTR record with the Start of Authority (SOA) server for the forward and reverse lookup zones, respectively. The clients send their record updates to the SOA servers because, in standard BIND-style DNS, only the SOA has a Read/Write copy of the zone file. In AD-integrated zones, any DC running DNS can update a zone record.

The DHCPClient service on a Windows computer handles the dynamic updates for each network interface. Don’t disable this service on a statically mapped server; you’ll prevent the server from updating its DNS records if you (or a colleague, after you’re long gone) change the server name or its IP address.

6. Failure to Properly Delegate Child Zones
All DCs in a forest share a common copy of the Configuration and Schema naming contexts, so DCs need to find replication partners regardless of their domain. AD identifies domains and DCs in DNS using CNAME records that correlate a server’s GUID and its FQDN. CNAME records for the School.edu forest.

If a CNAME record references a server in a child domain, the root DNS server needs to go to a DNS server in the child domain to retrieve a copy of the server’s A record. It gets the name of this DNS server by way of delegation.

7. Failure to Secure Public- Facing DNS Servers
For security, you want all internal servers to rely solely on forwarders to resolve Internet names. Don’t let your internal servers roam the Internet looking for name servers. Select the “Do not use recursion for this domain” option when configuring forwarding. This essentially makes your internal DNS server a slave of its forwarders; so specify two or more forwarders and try to use servers in different subnets, if possible. You don’t want a network failure at your ISP to keep your clients from resolving DNS names.

Now let’s turn attention to the servers you’ll use as forwarders. It’s important to keep the two primary DNS functions—caching and zone table lookups—on separate servers. If you allow your primary public DNS server to accept recursive queries and cache the results, you open yourself up for cache pollution. That’s why you want to install a caching-only server in your DMZ to act as a forwarder, rather than using your public DNS server as a forwarder.

8. Failure To Properly Secure Resource Records
If you use a BIND-style primary master to store a zone, you shouldn’t allow dynamic updates. Windows can’t secure updates to a text-based zone file. Any machine can assert itself as an existing host and overwrite the A record with a new IP address. This essentially allows a machine to hijack the DNS records of another machine.

If you want to use dynamic updates for a zone, integrate the zone into AD and permit secure updates only. This requires a client to use Kerberos to validate its identity, then initiate a secure transaction to obtain a signing key that it can use to digitally sign the update request. RFC 2930, “Secret Key Establishment for DNS,” documents this method, which can only be used by modern Windows clients (Win2K, Windows XP and Windows 2003).

9. Incorrect, Outdated or Unreachable DNS Servers
Anyone can get in a hurry and type an incorrect IP address in a host record or misspell a server name in a CNAME record. DNS doesn’t validate your entries—it assumes you’re a consummate IT professional and accepts your input unquestioningly. For this reason, it’s a good idea to test every new entry you make into a zone. If you do this as a habit, the test becomes a reflex.

The best test of a new A or CNAME record is usually a quick ping right at the console of the DNS server or your workstation. Take a couple of precautions to keep from getting fooled by caching. Both the DNS server and the local DNS resolver cache any records they receive for a period of time determined by a TTL setting in the record. The SOA for the zone determines the default TTL, which is one hour for Windows DNS servers. Clear the local cache using ipconfig /flushdns. For the server, use the Clear Cache option in the server’s property menu in the DNS console or use the Dnscmd utility with the syntax dnscmd /clearcache

10. Lack of Fault Tolerance
As systems administrators, we’re trained to think about the possibility of server failures and operational flexibilities. You would probably not set up a single DNS server in a large enterprise because your entire computing operation would grind to a halt if you take the server down for maintenance. But would you put the second DNS server on the same rack as the first? Or in the same subnet? Or even in the same server room?

Fault tolerance is all about assessing business risks, and if your business relies heavily on DNS, it makes sense to put some thought into maintaining continuity of service. You’ll get a big head start by integrating your DNS zones into AD. This allows you to use any DC in the domain as a primary master DNS server, eliminating the single point of failure in standard BIND-style DNS. Also, because each DC represents itself as the SOA server for the zone, its DNS clients do their dynamic updates locally rather than sending them across the WAN to a single primary master.