DNS
Last updated
Last updated
The DNS was developed to solve issues that could impede Internet growth. It is a hierarchical system of rules for managing Internet names and their interactions.
The DNS is designed with the domain name system in mind. Form the start, the DNS were developed to be both fast and resilient. The architects succeeded with their intentions!
The domain name is an identification string that defines a realm of administrative autonomy, authority or control within the Internet. A tiny part of the domain name space is illustrated in this picture and has the shape of an upside down tree with the root domain on top. A domain name consists of one or more parts, called labels, delimited by dots, such as example.com. The hierarchy of domains descends from the right to the left label in the name, each label to the left specifies a subdomain to the domain to the right. The full domain name may not exceed 253 characters in length.
Below the root domain are the Top level domains. They are distinguished into the following six groups:
Infrastructure top level domains (ARPA)
Generic top level domains (gTLD)
Restricted generic top level domains (grTLD)
Sponsored top level domains (sTLD)
Country code top level domains (ccTLD)
Test top level domains (tTLD)
Today, ICANN, the Internet Corporation for Assigned Names and Numbers, manages the top-level development and architecture of the Internet domain name space. It authorizes domain name registrars, through which domain names may be registered and reassigned.
The DNS infrastructure is made up of two distinctive entities; authoritative name servers and iterative resolvers.
An authoritative name servers hold the data for its assigned domains as well as information about delegated domains or subdomains. The delegation information held by the name servers are imperative for the domain name system to work. An authoritative name server will only respond to queries about its authoritative data.
Iterative resolvers, without their own data, initiate searches based on initial pointers. Through iterative querying, they acquire and cache information to expedite future searches.
An authoritative DNS contains zone files for the domains and zones it is responsible for and replies to queries about those domains.
In order to make the DNS and domain hierarchy work, authoritative DNS servers serving the different domain levels need to have an intimate relationship. This relationship is called parent and child, where the parent are the DNS servers delegating the subdomain and the DNS servers receiving the delegation are the children. The DNS records that make this possible are called delegation records or NS records.
Take note that the NS records in the example above are identical in both parent and child. This is important to assure that the name servers will be reached when resolvers perform their iteration and to avoid unnecessary name lookups. A subdomain should never be delegated to less than two DNS servers to maintain a decent amount of resiliency for the delegated domain.
The domain example.com is served by two name servers. These are the only two name servers that hold the authoritative data for that domain. Should both of them fail, no data for the example.com domain would be available including any delegated subdomains.
The counterpart to the authoritative DNS is the iterative resolver. The iterative resolver performs name lookups on requests from its clients using an iteration process which queries the different authoritative name servers.
In order for an iterative resolver to work it needs information about where to start its iteration process. That information is found at the IANA website and is called Root Hints and contains names and IP addresses to all authoritative root name servers.
The iteration for all queries start at the domain root, which is the common denominator of all domain names and DNS records. In the pictures below we have illustrated how a name iteration is performed and how the end result is returned to the client.
In the picture above we introduce something called a stub resolver. The stub resolver is nothing more than a resolver that lacks the iterative capabilities and can only be configured to know where to direct its queries to. A stub resolver can be found in virtually all Internet aware hosts.
The stub resolver queries its configured iterative resolver to find out the IPv4 address to the host www.example.com.
The iterative resolver don't know the answer so it begins an iteration process to find the answer to the query. The iterative resolver query one of the root name servers for the IPv4 address to www.example.com.
The root name server doesn't know the correct answer to this query since it only servers the root zone. What it does is to give a little help on the way. It does know which name servers that are authoritative for the .com domain. The query reply contains referral records to the authoritative name servers for the .com domain. This is called a referral response.
The iterative resolver repeats the same query but thanks to the referral response i just received it directs the query to one of the authoritative name servers for the .com domain.
The .com name server, like the root name server in the last query, doesn't know the correct answer either. It does know however, which name servers are authoritative for the example.com. domain and encloses that knowledge in a referral reply.
Once again, the resolver send the same query to the example.com. name servers.
This time around, the example.com. name servers knows the answer to the query and return a reply with the requested information.
The iterative resolver have successfully found the requested reply and return the answer to the stub resolver and closes the iteration process.
To increase the speed of the iteration process a resolver will cache each answer and each referral it receives. Instead of repeating the whole process, each resolver will cut corners and use the cached information whenever it gets another query.
In the example illustration above the iterative resolver will cache the referral information as well as the query response. The stub resolver will cache the query response. This caching will result in less DNS queries and improve the overall performance of name lookups. The stub resolver will not ask the iterative resolver again for www.example.com since it already have the answer in its own cache. All other queries will be sent to the iterative resolver.
Since the iterative resolver now knows which name servers are authoritative for the .com domain it can go straight to the .com name servers when receiving a query for another .com domain like acme.com If a query for another host record in the example.com domain would be received it can go straight to the example.com name servers.
The cached information will remain in cache as long as each individual resource record allows it to. Every DNS resource record set contains a TTL, Time To Live, which dictates how long the record is allowed to be cached before it should be discarded.
DNS record type
Description
Host (A)
Used to resolve a name to an IPv4 address.
Host (AAAA)
Used to resolve a name to an IPv6 address.
Alias (CNAME)
Used to resolve a name to another name. For example, an alias can resolve app.contoso.com to sea-svr1.contoso.com.
Service location (SRV)
Used by applications to identify the location of servers hosting that application. For example, AD DS uses SRV records to identify the location of domain controllers and related services.
Mail exchanger (MX)
Used to identify email servers for a domain.
Text (TXT)
Used to store arbitrary strings of information in DNS.
All resource records are configured with a time to live (TTL). The TTL for a resource record defines how long DNS clients and DNS servers can cache a DNS response for the record. For example, if a record has a TTL of 60 minutes, when a client makes a DNS query for the record, the response is cached for 60 minutes. If the client attempts to use the queried and resolved name within that 60 minutes, the cached record is used.
A DNS zone is the specific portion of a DNS namespace (such as contoso.com) that's hosted on a DNS server. A DNS zone contains resource records, and the DNS server responds to queries for records in that namespace. For example, the DNS server that's authoritative for resolving www.contoso.com to an IP address would contain the Contoso.com zone.
Contoso IT infrastructure staff can choose to store the Contoso.com DNS zone content in a file or in the AD DS database.
An established and common way to set up authoritative DNS servers is to configure one server as master and the rest of the servers as slaves. This setup allows for easy administration where the updates to the zone files are performed on the master server which in turn make the new zone file available to the slaves.
The slave servers picks up the zone files from the master server by zone transfers, either by periodically checking in to the master server using the SOA refresh timer or by way of a notification sent by the master server.
The DNS servers make no distinction to its zone data whether they are configured as master or slave, The zone data is identical as long as all slave servers are correctly updated.
The purpose of a stub zone is to provide a list of name servers that can be used to resolve information for a domain without synchronizing all the records locally. To enable this, the following are synchronized:
Name server records
Corresponding host records for the name servers
SOA record
The dynamic DNS records, which are created when a machine joins the domain or receives an IP address via DHCP can sometimes become stale. The easiest way to resolve this is to enable your DNS servers to scavenge old records . We can do this for all of our zones at once or doing them individually.
Create a forward lookup query with following information:
Zone name: harchit.local
Create two A records with following IP addresses
192.168.10.20
192.168.10.30
Create MX record with following information:
192.168.10.78
Create CNAME record for 192.168.10.20 (name is optional)
Create a reverse lookup query and map it to 192.168.10.20
Go to nslookup and verify your configuration
Go into the DNS manager and by default two Forward lookup zones should exist which are harchit.local and _msdcs.harchit.local
Select the yourname.local zone, in my case which is harchit.local, right click and select New Host(A or AAAA)
Type the IP address 192.168.10.20. It will use the parent domain name and for this exercise we are not creating PTR records now associating the A record with any owner name to update it. Select 'Add Host'
Following the same steps, add the second A record
Click Done, once the A record is added, now lets add an MX record for mail
Following the same procedures, lets add MX record
Make the mail server as '192.168.10.78', Click 'ok'
Let's create CNAME record following the same method, name is optional
Since we don't have any reverse lookup zones be default, lets create a reverse lookup zone first. Right click Reverse lookup zones and select New Zone
Click 'Next' on the wizard
Primary Zone should be selected by default and then click 'next'
Keeping the default setting, click 'next'
Click 'next'
Fill in the network id which in this case is 192.168.10 since we have /24 subnet and click next
Click 'next'
Review and click finish
Before we performing queries, it is necessary to enable aging and scavenging in our zones so that stale records can be deleted timely, preventing incorrect IP resolution and reducing DNS query latency.
Right-click on the specific zone in the left pane and choose "Properties."
In the "General" tab, check the box that says "Aging"
19.Select '"Scavenge stale resource records" and press 'Ok'
If we want to enable DNS aging and scavenging for all our zones at once
In the DNS Manager, right-click on the server name in the left pane and select "Set Aging/Scavenging for All Zones"
Select "Scavenge stale resource records" and click "Ok"
Now let's create the reverse lookup query which will require us to make a PTR record in our reverse lookup zone.
Right click the reverse lookup zone and select 'New Pointer(PTR)
Type 20 since 192.168.10. will already be written, making the address 192.168.10.20, host name is optional , Press ok
To verify our configuration, go to cmd and type nslookup. For every record you want to confirm set the type. For example, to see all the A records, set type=a and then the domain name harchit.local to see all the A records for the domain. The process would be a little different to confirm all the DNS records through cmd so refer to the screenshot below
You can access the contents of the DNS resolver cache either by using the Get-DnsClientCache cmdlet, or by running the ipconfig /displaydns command. You can clear the contents of the DNS resolver cache either by using the Clear-DnsClientCache cmdlet, or by using the ipconfig /flushdns command.
