How Dynamic DNS Populates the DNS Database- Implementing DNS

TCP/IP is the protocol used for network communications on a Microsoft Windows Server 2022 network. Users have two ways to receive a TCP/IP number:

          Static (you manually enter the TCP/IP information)

         Dynamic (using DHCP)

When you set up TCP/IP, DNS can also be configured.

Once a client gets the address of the DNS server, if that client is allowed to update with DNS, the client sends a registration to DNS or requests DHCP to send the registration. DNS then does one of two things, depending on which Dynamic Updates option is specified:

       Check with Active Directory to see if that computer has an account (Secure Only updates) and, if it does, enter the record into the database.

               Enter the record into its database (nonsecure and secure updates).

What if you have clients that cannot update DNS? Well, there is a solution—D HCP. In the DNS tab of the IPv4 Properties window, check the option labeled “Dynamically update DNS records for DHCP clients that do not request updates (for example, clients running Windows NT 4.0),” which is shown in Figure 5.4.

FIGURE 5.4 DHCP settings for DNS

DHCP, along with Dynamic DNS clients, allows an organization to update its DNS database dynamically without the time and effort of having an administrator manually enter DNS records.

DNS Queries

As stated earlier, a client can make three types of queries to a DNS server: recursive, inverse, and iterative. Remember that the client of a DNS server can be a resolver (what you’d normally call a client) or another DNS server.

Iterative Queries

Iterative queries are the easiest to understand: a client asks the DNS server for an answer, and the server returns the best answer. This information likely comes from the server’s cache. The server never sends out an additional query in response to an iterative query. If the server doesn’t know the answer, it may direct the client to another server through a referral.

Recursive Queries

In a recursive query, the client sends a query to a name server, asking it to respond either with the requested answer or with an error message. The error states one of two things:

         The server can’t come up with the right answer.

         The domain name doesn’t exist.

In a recursive query, the name server isn’t allowed to just refer the client to some other name server. Most resolvers use recursive queries. In addition, if your DNS server uses a forwarder, the requests sent by your server to the forwarder will be recursive queries.

Figure 5.5 shows an example of both recursive and iterative queries. In this example, a client within the Microsoft Corporation is querying its DNS server for the IP address for www.whitehouse.gov.

FIGURE 5.5 A sample DNS query

Here’s what happens to resolve the request:

  1. The resolver sends a recursive DNS query to its local DNS server asking for the IP address of www.whitehouse.gov. The local name server is responsible for resolving the name, and it cannot refer the resolver to another name server.
  2. The local name server checks its zones, and it finds no zones corresponding to the requested domain name.
  3. The root name server has authority for the root domain and will reply with the IP address of a name server for the .gov top- level domain.
  4. The local name server sends an iterative query for www.whitehouse.gov to the Gov name server.
  5. The Gov name server replies with the IP address of the name server servicing the whitehouse.gov domain.
  6. The local name server sends an iterative query for www.whitehouse.gov to the whitehouse.gov name server.
  7. The whitehouse.gov name server replies with the IP address corresponding to  www.whitehouse.gov.
  8. The local name server sends the IP address of www.whitehouse.gov back to the original resolver.

Inverse Queries

Inverse queries use pointer (PTR) records. Instead of supplying a name and then asking for an IP address, the client first provides the IP address and then asks for the name. Because there’s no direct correlation in the DNS namespace between a domain name and its associated IP address, this search would be fruitless without the use of the in- addr.arpa domain. Nodes in the in- addr.arpa domain are named after the numbers in the dotted- octet representation of IP addresses. However, because IP addresses get more specific from left to right and domain names get less specific from left to right, the order of IP address octets must be reversed when building the in- addr.arpa tree. With this arrangement, administration of the lower limbs of the DNS in- addr.arpa tree can be given to companies as they are assigned their Class A, B, or C subnet address or delegated even further down thanks to  Variable Length Subnet Masking (VLSM).

Once the domain tree is built into the DNS database, a special PTR record is added to associate the IP addresses with the corresponding hostnames. In other words, to find a hostname for the IP address 206.131.234.1, the resolver would query the DNS server for a PTR record for 1.234.131.206.in- addr.arpa. If this IP address is outside the local domain, the DNS server will start at the root and sequentially resolve the domain nodes until arriving at 234.131.206.in- addr.arpa, which would contain the PTR record for the desired host.

Caching and Time to Live

When a name server is processing a recursive query, it may be required to send out several queries to find the definitive answer. Name servers, acting as resolvers, are allowed to cache all of the received information during this process; each record contains information called time to live (TTL). The TTL specifies how long the record will be held in the local cache until it must be resolved again. If a query comes in that can be satisfied by this cached data, the TTL that’s returned with it equals the current amount of time left before the data is flushed.

There is also a negative cache TTL. The negative cache TTL is used when an authoritative server responds to a query indicating that the record queried doesn’t exist, and it indicates the amount of time that this negative answer may be held. Negative caching is quite helpful in preventing repeated queries for names that don’t exist.

The administrator for the DNS zone sets TTL values for the entire zone. The value can be the same across the zone, or the administrator can set a separate TTL for each RR within the zone. Client resolvers also have data caches and honor the TTL value so that they know when to flush. Users also have the ability to manually flush the DNS cache by running the Ipconfig /flushDNS command.

Leave a Reply

Your email address will not be published. Required fields are marked *