Showing posts with label Dynamic DNS. Show all posts
Showing posts with label Dynamic DNS. Show all posts

Friday, April 3, 2009

How to Use Dynamic DNS in Windows 2000 Professional

Windows 2000 Professional has a feature called Dynamic DNS (DDNS) that enables host records to be updated automatically in a Windows 2000 DNS server when the client address changes. This enables host records to remain accurate even when clients receive their address assignments through DHCP, for example.

A Windows 2000 Professional client can request an update to its host (A) record in the DNS server when its IP address or host name changes. A Windows 2000 DHCP server can also request an update to the associated pointer (PTR) record on behalf of its DHCP clients.

To configure a client for DDNS, follow these steps:

  1. Open the Properties sheet for the network connection through the Network And Dial-Up Connections folder.
  2. Double-click TCP/IP.
  3. Go to Advanced | DNS.
  4. Select the Register This Connection’s Addresses In DNS option to enable DDNS for the client.
  5. Note: The Use This Connection’s DNS Suffix In DNS Registration option, if selected, registers the client using the first part of the computer name specified in the System properties along with the DNS suffix specified by the DNS Suffix For This Connection option.
Source: blogs.techrepublic.com.com

Wednesday, November 12, 2008

DHCP Server Security

Although DHCP servers are critical to the operation of most enterprise networks, DHCP server security is often one of the most overlooked areas of network security. One reason for this might be the simplicity of how DHCP works: DHCP clients broadcast discovery messages (DHCPDISCOVER) containing their MAC addresses and DHCP servers respond by offering (DHCPOFFER) to lease an IP address and other TCP/IP settings that the client can use to communicate on the network. The client responds (DHCPREQUEST) to the first lease offer it receives and the server acknowledges (DHCPACK) the request and marks the address as leased in its DHCP database. That's all there is to it—who needs to worry about security?

Attacking DHCP

Unfortunately it's the very simplicity of DHCP that's actually the problem as far as security goes. No authentication or authorization takes place during an exchange between a DHCP server and DCHP client, so the server has no way of knowing if the client requesting the address is a legitimate client on the network, and the client has no way of knowing if the server that assigned the address is a legitimate DHCP server. The possibility of rogue clients and servers on your network can create all kinds of problems.

For example, a rogue DHCP server could provide legitimate clients with bogus TCP/IP information that prevents the clients from communicating on the network. A denial of service (DoS) condition then results, and users are unable to connect to network resources to perform their work. Setting up a rogue DHCP server could be as simple as conducting a social engineering attack to gain physical access to your network and plugging in a laptop configured as a DHCP server.

Another scenario might involve an attacker compromising a client computer on your network and installing software that repeatedly requests new IP addresses using spoofed MAC addresses until the entire pool of addresses in your DHCP server's scope is leased. When this happens, legitimate clients that boot onto the network can't acquire an address and again users are unable to access the network and can't do their work.

A more sinister result happens when an attacker breaches network security and gains control of your own DHCP servers. At that point the attacker might proceed to modify the DHCP server to assign clients an incorrect subnet setting and thus create another DoS condition. Or they might modify the server to assign clients incorrect DNS settings and redirect clients to rogue or hijacked DNS servers, which could then redirect clients to hostile websites where they unknowingly download a trojan.

Worse yet, if you're running your DHCP server on a domain controller then an attacker who compromises your DHCP server gains access to your accounts database and can cause all sorts of further problems. The result is usually your worst nightmare. Fortunately, there are some measures you can take to protect your DHCP servers and avoid many of these scenarios, provided you're also following all the usual best practices for securing Windows-based networks. Let's look at some specific threats to DHCP on your network and the countermeasures you can take to mitigate these different threats.

Threats and Countermeasures

On the face of it, the requirement that Windows 2000 and Windows Server 2003 DHCP servers be authorized in Active Directory before they can start leasing addresses to requesting clients seems to mitigate the threat of rogue DHCP servers on your network. Authorization means that when a Windows 2000 or Windows Server 2003 DHCP server boots onto an Active Directory network it first contacts a domain controller to check if its own IP address is found on the list of authorized DHCP servers maintained by the domain controller. If the DHCP server determines that it is authorized to lease addresses to clients, it begins to do so. If it's not authorized, Windows shuts down the DHCP Server service on the machine so it won't be able to lease addresses.

The real benefit of this is to protect your network against legitimate DHCP servers that are badly configured, though it has the added side effect of guarding against accidental or rogue DHCP servers running Windows 2000 or Windows Server 2003. What happens though if an attacker compromises your network with a rogue DHCP server not running Windows 2000 or Windows Server 2003? In this case authorization won't help because non-Microsoft DHCP servers may not respond the same way as Microsoft ones to the DHCPINFORM messages Windows uses to check if DHCP servers are authorized.

Rogue clients is another problem entirely though, as DHCP is designed to make it easy for clients to obtain IP addresses so they can participate on a network. The obvious way of dealing with the problem of rogue clients would seem at first to be DHCP reservation, though on large networks this entails considerable administrative overhead. A reservation is a predefined setting that maps a MAC address to an IP address so that only a client with a particular MAC address can lease the IP address associated with that reservation. If security is critical an administrator could create reservations for each and every client machine on the network, and if unreserved IP addresses still remain in the DHCP server's cope then these could be reserved using invalid or non-existing MAC addresses. Then when a rogue client tries to boot on the network the result is that the DHCP server has no free addresses to lease and the client can't connect.

If only it were that simple. While this approach might foil a casual attack, sophisticated attackers have ways for circumventing DHCP reservations. The simplest approach is for the attacker to run a program that listens for DHCPDISCOVER broadcasts from clients and harvests their MAC addresses. Then when a legitimate client shuts down the rogue client can reconfigure its MAC address to match that of the legitimate client and hijack the legitimate client's lease or try to disrupt communications for the client. Considering this, security-conscious administrators might consider dropping DHCP entirely in favor of static addressing, but what's to stop an attacker who has physical access to your network from assigning a static address to their own machine and joining the network?

Via:windowsecurity.com/articles/DHCP-Security-Part1.html

Friday, November 7, 2008

How to reinstall a dynamic DNS Active Directory-integrated zone

Under the following situations you may want to reinstall the dynamic DNS in a Windows 2000 Active Directory:


  • Multiple DNS errors have occurred and methods have been unsuccessful.

  • Services that depend upon DNS, such as, the File Replication service (FRS) and/or Active Directory are failing. Also, the standard troubleshooting procedures have been unable to locate the exact cause of the problem.

  • DNS had been built as a secondary DNS server or files copied from a DNS server do not support dynamic updates.
To create a better name space design, such as, splitting the internal and external name spaces.
You have to remove DNS and the DNS cache. Then, you must rebuild one Active Directory DNS server to set up long term stability.

The following steps can remove the defective information in Active Directory-integrated DNS:

  • Go to the properties of the DNS zone files and change them to be a "Standard Primary".

  • In the %Systemroot%\Winnt\System32\DNS folder, delete the text DNS Zones files.

  • Delete the object in Active Directory Users and Computers.

  • On the View menu, click Advanced Features, expand the System folder, click MicrosoftDNS, and then delete the zone file objects.

  • For each Active Directory-integrated DNS server, repeat steps 1-3.

  • In the Transmission Control Protocol/Internet Protocol (TCP/IP) properties of the first Active Directory-integrated DNS server, point it to itself.

  • To obtain proper resolution, you must clear the Caching Resolver, which is the DNS client on the DNS server. At the command prompt, type: ipconfig /flushdns.

  • Stop and restart DNS and the NetLogon service. Then, remove and re-add the DNS service.
You have completed the process to clear out a DNS server. You must complete the process for any additional DNS servers that you plan to integrate with Active Directory.

The following steps can assist you to build a strong foundation for DNS, Active Directory, and FRS:


  • Configure all DNS servers to point to the same DNS server in the domain or forest under TCP/IP properties in DNS: Right-click My Network Places, click Local Area

    Connection
    , right-click Local Area Connection, click Properties, select the properties of TCP/IP, and then point all DNS servers to the same DNS server. Also, click the Advanced DNS tab, and then confirm that secondary DNS servers are not configured.

  • Re-add the DNS service, or re-add the zones and configure them to be Active Directory integrated. For troubleshooting purposes, you may want to set "Allow Dynamic Updates?" to Yes. Later, you can change this setting to "Allow Only Secure Updates".

  • Run the ipconfig /flushdns command, and then run the comand. This command can help you to register your A resource record for DNS as well as your start of authority (SOA). You may want to run this command on any other servers that are critical to you.ipconfig /registerdns
  • NOTE: The Dynamic Host Configuration Protocol (DHCP) client service needs to be running on each of these computers to register the records in Dynamic DNS. It is not relevant if the computer is a DHCP client or not. You must have this service set to "start" and the "Start up" type set to "automatic." The DHCP client service is what registers records in Dynamic DNS. (Refer to the description in the Computer Management snap-in.)

  • Active Directory-integrated DNS is now working on your first Dynamic DNS server. You must point additional Dynamic DNS servers to the first DNS server under TCP/IP properties. You must confirm that a full and complete replication process has occurred before you change the TCP/IP properties to point to itself for any additional DNS servers.
Before you configure DNS, you must research the benefits of various DNS name space architectures, such as, internal name spaces, external name spaces, child domains, caching only DNS servers, and reverse look-up zones. Then, you must consider how to develop a design architecture that can work for your organization.

Source:support.microsoft.com/kb/294328

Monday, August 4, 2008

MintDNS 2006 Tutorials

MintDNS 2006 is a fully featured server suite that allows you to run your own enterprise level DDNS Server.

Supporting both Dynamic and Static DNS MintDNS also supports several standard update protocols. Which enables support for many existing third party IP address update clients, and many hardware(Firmware) clients. This allows you to provide time tested reliable Dynamic DNS services to most all internet connected computers, or even remote cameras.

MintDNS is completely template based, so the look and feel of your DNS service can easily be adapted to match your existing website or modified to suite your specific needs.

We have provided Dynamic DNS solutions for more than 5 years. MintDNS 2006 Enterprise is our latest product and is also the most dependable, feature rich and scaleable product we have ever offered.

If your interested in custom development you may like to know that MintDNS is almost completely open sourced allowing you to easily expand on the existing system to meet any special needs your company may have. The advantage to having an established time tested platform to build on could save months of development time.

The all new web based administration console gives you instant access to advanced user management features, statistics charts, accounting features and complete control over server settings.

Monday, April 7, 2008

Domain Name System Client Behavior in Windows Vista

Microsoft® Windows Vista™ includes both Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) protocol stacks that are installed and enabled by default. Domain Name System (DNS) name queries and registrations can now involve both IPv4 address records (A records) and IPv6 address records (AAAA records). This article describes the behavior of the DNS Client service in Windows Vista for DNS queries and registrations and the possible impact on DNS traffic.

Note: This article does not describe changes to DNS client behavior in versions of Windows released after Windows Vista with Service Pack 1 and Windows Server 2008, including additional service packs or other updates.

DNS Query Behavior

Computers running Windows Vista need to perform both A and AAAA queries to determine the best method of connectivity to the desired endpoint. By obtaining both IPv4 and IPv6 addresses, there is an increased chance of being able to access the desired endpoint if one of the addresses is unreachable.

The DNS Client service in Windows Vista has been designed to minimize the impact on DNS servers when performing DNS name queries through the following behavior:

· If the host has only link-local or Teredo IPv6 addresses assigned, the DNS Client service sends a single query for a records.

· If the host has at least one IPv6 address assigned that is not a link-local or Teredo address, the DNS Client service sends a DNS query for A records and then a separate DNS query to the same DNS server for AAAA records. If an A record query times out or has an error (other than name not found), the corresponding AAAA record query is not sent.

This DNS querying behavior will assist enterprises and ISPs in their transition to IPv6. When AAAA records are added to DNS either manually or through DNS dynamic update, computers running Windows Vista will by default use IPv6 over IPv4, providing proof to IT staff that the IPv6 routing and name resolution infrastructure is working properly for IPv6 connectivity. When organizations transition to an IPv6-only infrastructure and disable IPv4, the DNS Client service will send only AAAA queries.

Computers running Windows Vista can increase DNS traffic and the load on DNS servers when the computers have been configured with a global address:

· On intranets that have deployed IPv6 (either native or ISATAP), there will be additional DNS query traffic. However, deployments of Windows Vista in enterprise networks using IPv6 have not resulted in dramatic increases in the loads on intranet DNS servers. Intranets running at or near capacity for DNS might need to provide additional capacity to better support an enterprise deployment of Windows Vista.

· On the Internet, computers running Windows Vista by default will typically not be configured with a global address from their ISPs or from their gateway devices. At this time, typical ISPs do not support native IPv6 connectivity and typical home routers do not support the 6to4 transition technology. If a computer running Windows Vista is located behind a network address translator (NAT), the Teredo client component will automatically configure a global Teredo address, even if it is in an inactive state. However, a computer running Windows Vista will not send AAAA record queries if it only has a Teredo address assigned.

DNS Registration Behavior

The DNS Client service in Windows Vista uses DNS dynamic update and attempts to register the following records:

· A records for all IPv4 addresses assigned to the interfaces that are configured with a DNS server

· Pointer (PTR) records for IPv4 addresses assigned to interfaces that are configured with a DNS server

· AAAA records for all global IPv6 addresses assigned to interfaces that are configured with a DNS server

Teredo addresses are not registered.

For the typical intranet host configured with a global IPv6 address, additional AAAA records for IPv6 global addresses are registered. However, a DNS dynamic update client includes all of the records that they are registering in a single packet. Therefore, although there are additional records to register, there are no additional packets for AAAA record registration. Therefore, the impact on intranet DNS servers for AAAA registration is minimal.

Typical Internet-based DNS servers do not support DNS dynamic update. However, if an Internet-based DNS server did support DNS dynamic update, there is typically no additional traffic because the typical Windows Vista-based Internet host does not have a global IPv6 address assigned and Teredo addresses are not registered. Therefore, for typical Windows Vista-based hosts on today's Internet, there is no performance impact on Internet DNS servers for DNS registration.


source technet.microsoft.com