The Domain Name System (DNS) is a query response protocol found at the Application layer of the OSI model. DNS queries and responses take place in the form of messages.

Queries and General Lookup

Standard Queries

Fundamentally DNS is used by client devices through standard queries to translate human readable, fully qualified domain names such as williedeklerk.com into IP addresses needed for locating and identifying specific computer resources such as web servers. (Mockapetris, RFC 1034, 1987, pp. 16 – 18)

*Inverse Queries

DNS can be used by client devices through inverse queries to map a particular resource to a domain name or domain names that have the resource. (Mockapetris, RFC 1034, 1987, p. 18)

There is much more to inverse queries and their use in the modern age of DNS. Due to the Domain Name System structure used to resolve DNS queries, an inverse query is really inefficient. To help speed things back up again, special domains such as “in-addr.arpa” and “ip6.arpa” was created. This means that most DNS queries that users think of as Inverse queries, are in reality Standard Queries to *.in-addr.arpa or *.ip6.arpa.

General Lookup

DNS associates’ various information in the form of resource records with domain names allowing client devices to perform a general lookup function for DNS information.

DNS message format

The Domain Name System makes use of two types of messages namely Queries and Replies. Each message consists of a DNS protocol header which contains a number of fixed fields which are always present, and four sections to carry query parameters and resource records.

The four sections:

Question: Carries the query name and other query parameters related to resource records.
Answer: Carries resource records which answer the query.
Authority: Carries resource records which describe other authoritative servers.
Additional: Carries resource records which may be helpful in using the resource records in the other sections.

(Mockapetris, RFC 1034, 1987, pp. 15 – 16)

The fixed fields (flags) within the DNS protocol header controls the content of the four sections described above and the fields are:

R: Indicates if the message is a query (0) or a reply (1)
OPCODE: It indicates the type of query in the message, the type can be QUERY (standard query, 0) IQUERY (inverse query, 1) or STATUS (server status request, 2)
AA: Authoritative Answer, used in response messages and specifices whether the DNS server queried is authoritative for the queried hostname.
TC: Truncation indicates that the message was truncated due to its length being longer than permitted.
RD: Recursion Desired, if the client sets this value the server is instructed to perform the query recursively
RA: Recursion Available, indicates whether the server is replying to the message supports recursive querying.
Z: Always set to zero in all queries and responses as it is reserved for future use.
RCODE: This field indicates the response code which can be:
- 0. No error: The preferred ideal response code, indicating no error.
- 1. Format error: Unable to interpret the query due to incorrect formatting.
- 2. Server Failure Unable to process the request due to server-side error.
- 3. Name Error: THe domain name being queried does not exist.
- 4. Not Implemented: The query type is not supported.
- 5. Refused: The name server being queried refuses to perform the specified task due to policy reasons

(Mockapetris, RFC 1035, 1987, pp. 26 – 28)

Resource Records

DNS associates’ various information in the form of resource records with domain names. A resource record at a fundamental level contains the following information:

Owner: The domain name where the resource record is found.
Type: A 16-bit encoded value that specifies the type of the resource in the resource record.
Class: A 16-bit encoded value that identifies a protocol family or instance of a protocol.
TTL: The time to live value of a resource record. It is a 32-bit integer. It describes how long a resource record can be cached before it should be discarded.
RDATA: The type and sometimes the class of dependent data that describes the resource.

(Mockapetris, RFC 1034, 1987, pp. 11 – 13)

Some of the more common resource records that you may be familiar with include: (more at iana.org dns-parameters) Record Type: A NS CNAME PTR AAAA Reference: RFC1035 RFC 3596

DNS Resolvers and Nameservers

In order for domain name resolution to occur successfully, there are quite a number of nameservers and resolvers that need to work together. Some of the design elements are quite interesting, utilizing caching along with time-to-live values to reduce overall resource usage such as memory and network bandwidth usage.

Stub Resolver

A stub resolver is lightweight resolver for client devices. It makes use of a list of name server addresses that will perform the recursive requests on behalf of the client. This is typically stored in a small configuration file. (Mockapetris, RFC 1034, 1987, p. 32)

Recursive Resolver

A recursive resolver performs dns query resolution on behalf of the client, contacting the name servers if a response is not already cached. When a response is cached the dns server does not go through the entire process, only sending the cached response to the client.

Root Name Server

The first stop if you are a recursive dns server. A root nameserver will direct the recursive resolver to the top-level domain name server. Root-servers.org iana.org

Top-Level Domain Name Server

The second stop if you are a recursive dns server, having received a response from a rot nameserver pointing you to this TLD server. It maintains information for all domains sharing a top-level domain such as .com. The TLD server would respond to the recursive dns servers query with the authoritative nameserver for the requested domain.

Second-Level Domain Name Server

At the last stop the SLD server would usually have the information specific to the domain name it serves and provides the IP address for the resource such as an IPv4 address for an A resource record.

DNS Namespace Hierarchy

The DNS namespace follows an inverted tree structure. The “za” , “nl”, “ca” top-level domain forms part of country-code top-level domains (ccTLDS) for South Africa (za), Netherlands (nl), Canada (ca). The “com” top-level domain forms part of generic top-level domains (gTLDs). For a complete list of Top-Level domains in alphabetical order, please visit data.iana.org

Taking South Africa as an example

Second level domains under the “za.” top-level domain such as “gov.” and “co.” cannot be registered by people as they are reserved. The “gov.” second-level domain is reserved for governmental agencies and institutions in South Africa. The “co.” second-level domain is reserved for companies in South Africa.

It should be noted that it is possible for companies to register domain names under {company}.co.za as a third-level domain in South Africa. An example of this includes eskom.co.za. Using the .com gTLD makes it possible to register a second level domain such as williedeklerk.com.

If you would like to register your own domain after reading this, you can do it at a registrar such as: squarespace.com, cloudflare.com, namecheap.com (sometimes free for 1yr), afrihost.com

Transport Protocols used by DNS

Traditionally, DNS has made use of the User Datagram Protocol (UDP) for transport over IP Networks. As the internet and computer networks evolved other transport protocols took the place of UDP in terms of security however UDP still remains in service to this day. Some of the more common transport protocols that can be used by DNS for transport over IP networks include: DNS over UDP | DNS over TCP | DNS over TLS (DoT) | DNS over HTTPS (DoH).

Digging DNS

here is a linux command called dig that can be used to gather DNS information. It has an extensive list of available options however if you consult the article at different sections, the following should make some sense.

Conclusion

We have to thank the people who have dedicated significant amounts of their lives to developing DNS as without it , the internet as we the collective internet users know it today might not have been brought into existence.

DNS has three major components that allows it to function:

Domain name space and resource records: A query will include the domain name of interest and the type of resource information that is being requested.
Name Servers: Server programs that hold information about the domain tree’s structure and set information.
Resolvers: Programs that extract information from name servers in response to client requests.

(Mockapetris, RFC 1034, 1987, p. 6)

Domain Name Systems