Overview of the Domain Name System (DNS)

Table of contents

• How are nodes delegated?
• What is a zone file?
• What are the typical steps involved in a DNS query?
• Step 1
• Step 2
• Step 3
• Step 4
• Step 5
• Nameserver architecture
• DNS nameserver addressing methodologies
• Anycast for the secondary DNS service 
• How does the Domain Name System (DNS) work? 
• How are nodes delegated?
• What is a zone file?
• What are the typical steps involved in a DNS query?
• Step 1
• Step 2
• Step 3
• Step 4
• Step 5
• Nameserver architecture

Download the PDF

The DNS is a technology that most IT managers don’t think much about; it works well and usually does not require much attention to support organizational objectives. As businesses increasingly rely on their web strategy, the DNS infrastructure deserves attention for many reasons, including:

1. Increasing trend towards DDoS attacks against the DNS has raised awareness of weaknesses in traditional legacy DNS architecture that can easily be exploited.
2. Increasing complexity of websites and web applications, along with sourcing of content from multiple different sites, has resulted in longer page load times. DNS latency, although typically low, is part of the total sum and optimizing your DNS infrastructure will enhance your users’ web experience.
3. Understanding that, for many organizations, there are benefits to keeping local Canadian traffic within Canadian borders. This helps to improve information security, mitigate geographically sourced malicious attacks, and increase speed. DNS architectures can be configured to optimize regional traffic while serving global traffic.

To help demystify the DNS, this short primer provides information to help IT managers or technical decision makers re-familiarize themselves with the technology.

How does the Domain Name System (DNS) work?

The Domain Name System (DNS) provides the core backbone of the Internet by providing the map between easily-readable hostnames (i.e. stg.cira.ca) and IP addresses (192.228.29.1) by way of resource records. It is essential to the operation of the Internet by enabling the use of logical, human-readable names for locations rather than complex IPv4 or IPv6 addresses. It additionally provides mappings to things like mail servers, SIP servers, redirects, digital signatures,
and more.

The DNS is a distributed database organized as a tree of interconnected nodes (server or server clusters) where each node is a partition of the database. Nodes are delegated to designated authorities and there can be only one authority for a node or group of nodes.

How are nodes delegated?

The DNS is a top-down hierarchical distributed database with the Internet Corporation for Assigned Names and Numbers (ICANN) acting as “the root” at the top of the database. Top-level domains (TLDs) are delegated to both countries and commercial entities, who likewise delegate second-level domains to Registrants. For example, ICANN/IANA delegates the authority for .CA to the Canadian Internet Registration Authority (CIRA), who delegates the authority for gc.ca to the Canadian government, and the Canadian government may (and does) delegate authority for subdomains under gc.ca to its departments.

What is a zone file?

A zone file is a list of DNS resource records for the zone. The responsibility for maintaining this zone file rests with the organization or individual with delegated authority for the zone.

The responsible organization or individual is also obligated to ensure that there are DNS nameservers available to respond to DNS queries for resource records in the zone. For some organizations, this function is offloaded to another company for management, and this is particularly so for small companies using hosting packages from a Registrar or other hosting company. A typical SOHO (small office/home office) would tend to not have the expertise needed to manage their own DNS nameservers. With medium and larger organizations within Canada, CIRA research shows that DNS authorities are using a mix of insourced DNS infrastructure and outsourced DNS service providers.

What are the typical steps involved in a DNS query?

Step 1

Network connected devices resolvers) send a request (or query) to a recursive nameserver. If the recursive server does not have the answer cached it moves to step two.

Step 2

The recursive nameserver sends a query to the root nameservers to resolve the address for the top-level domain. The root nameservers for the top-level domain then return a referral to the recursive nameserver.

Step 3

The recursive nameserver then sends a query to the top level nameservers (in this example, .CA) which then returns a referral to the second-level nameservers.

Step 4

The recursive nameserver then sends a query to the second-level nameservers (in this example, gc.ca) which then returns a referral to the third-level nameservers.

Step 5

The recursive name server then sends a query to the third-level nameservers (in this example, ic.gc.ca) which then returns an authoritative answer to the recursive nameservers.

Nameserver architecture

The best practice for architecting nameservers is to use a hidden master (primary) nameserver and secondary nameservers. This has the benefit of keeping a hidden primary/master server within the corporate infrastructure for administration of the zones. With this structure in place, management of the server and/or downtime at this server will not impact access to the organization’s web properties. For security, the firewall should be configured to only allow communication to and from the secondary servers.

Once this architecture is in place, the choices and scope of the secondary infrastructure is based on organizational needs and risk tolerance.

DNS nameserver addressing methodologies

Like any server infrastructure, it is best practice to have redundancy built into the DNS infrastructure. There are two methods of addressing DNS nameservers:

• Unicast

  Broadly applied, unicast is the communication from a single sender to a single receiver on a network. As it applies to the DNS it is a one-to-one association between a network address and the end-point. In other words, if the unicast DNS has 2 records (ns1 and ns2) then each corresponds to exactly one server. This does not preclude building in redundancy at unicast nodes or having more than one node online to answer queries, but it does not afford the full suite of benefits of an anycast solution for external DNS resolution.

• Anycast

  Anycast is one of several routing schemes that can be used to control the flow of traffic across a network, typically using the Border Gateway Protocol (BGP). With anycast DNS, multiple nodes that are copies of each other are geographically dispersed. In this way, multiple servers sit behind identical IP addresses and answers to queries are always done by the geographically closest node. Benefits of an anycast network include: lower latency,
  increased redundancy, and higher resilience to DNS DDoS attacks.

Anycast for the secondary DNS service 

Much like other organizational decisions, the provisioning of DNS secondary services comes down to a, “build, buy, or both” decision. Whatever is chosen, adding an anycast secondary DNS service improves speed and resiliance for the organization’s web properties and services.

If a secondary DNS service architecture is already in place, whether in house or from a service provider, this does not preclude adding additional secondary DNS services. By incrementally adding new services to their DNS an IT manager can improve speed and resilience for their web properties and can get additional benefits from geo-focused services. For instance, CIRA runs the D-Zone Anycast DNS Service, which offers both global and local secondary nodes, where the local nodes are set-up to serve Canadian traffic and to protect the Canadian traffic from external DDoS attacks. In business parlance, the D-Zone solution will help protect a company’s Canadian audience and related objectives while also improving global reach through nodes located in Internet hubs around the world.

DDoS attacks on the DNS are a top operations threat with “one-third of DNS operators having experienced a customer-impacting attack” – Arbor 2016 Worldwide Infrastructure Security Report.

DNS architecture showing the secure corporate network, the use of a hidden primary DNS nameserver and the secondary service serving queries via an anycast cloud.

Read the DNS glossary to learn more

The DNS is a technology that most IT managers don’t think much about; it works well and usually does not require much attention to support organizational objectives. As businesses increasingly rely on their web strategy, the DNS infrastructure deserves attention for many reasons, including:

1. Increasing trend towards DDoS attacks against the DNS has raised awareness of weaknesses in traditional legacy DNS architecture that can easily be exploited.

2. Increasing complexity of websites and web applications, along with sourcing of content from multiple different sites, has resulted in longer page load times. DNS latency, although typically low, is part of the total sum and optimizing your DNS infrastructure will enhance your users’ web experience.

3. Understanding that, for many organizations, there are benefits to keeping local Canadian traffic within Canadian borders. This helps to improve information security, mitigate geographically sourced malicious attacks, and increase speed. DNS architectures can be configured to optimize regional traffic while serving global traffic.

To help demystify the DNS, this short primer provides information to help IT managers or technical decision makers re-familiarize themselves with the technology.

How does the Domain Name System (DNS) work? 

The Domain Name System (DNS) provides the core backbone of the Internet by providing the map between easily-readable hostnames (i.e. stg.cira.ca) and IP addresses (192.228.29.1) by way of resource records. It is essential to the operation of the Internet by enabling the use of logical, human-readable names for locations rather than complex IPv4 or IPv6 addresses. It additionally provides mappings to things like mail servers, SIP servers, redirects, digital signatures, and more.

The DNS is a distributed database organized as a tree of interconnected nodes (server or server clusters) where each node is a partition of the database. Nodes are delegated to designated authorities and there can be only one authority for a node or group of nodes.

How are nodes delegated?

The DNS is a top-down hierarchical distributed database with the Internet Corporation for Assigned Names and Numbers (ICANN) acting as “the root” at the top of the database. Top-level domains (TLDs) are delegated to both countries and commercial entities, who likewise delegate second-level domains to Registrants. For example, ICANN/IANA delegates the authority for .CA to the Canadian Internet Registration Authority (CIRA), who delegates the authority for gc.ca to the Canadian government, and the Canadian government may (and does) delegate authority for subdomains under gc.ca to its departments.

What is a zone file?

A zone file is a list of DNS resource records for the zone. The responsibility for maintaining this zone file rests with the organization or individual with delegated authority for the zone.

The responsible organization or individual is also obligated to ensure that there are DNS nameservers available to respond to DNS queries for resource records in the zone. For some organizations, this function is offloaded to another company for management, and this is particularly so for small companies using hosting packages from a Registrar or other hosting company. A typical SOHO (small office/home office) would tend to not have the expertise needed to manage their own DNS nameservers. With medium and larger organizations within Canada, CIRA research shows that DNS authorities are using a mix of insourced DNS infrastructure and outsourced DNS service providers.

What are the typical steps involved in a DNS query?

Step 1

Network connected devices resolvers) send a request (or query) to a recursive nameserver. If the recursive server does not have the answer cached it moves to step two.

Step 2

The recursive nameserver sends a query to the root nameservers to resolve the address for the top-level domain. The root nameservers for the top-level domain then return a referral to the recursive nameserver.

Step 3

The recursive nameserver then sends a query to the top level nameservers (in this example, .CA) which then returns a referral to the second-level nameservers.

Step 4

The recursive nameserver then sends a query to the second-level nameservers (in this example, gc.ca) which then returns a referral to the third-level nameservers.

Step 5

The recursive name server then sends a query to the third-level nameservers (in this example, ic.gc.ca) which then returns an authoritative answer to the recursive nameservers.

Nameserver architecture

The best practice for architecting nameservers is to use a hidden master (primary) nameserver and secondary nameservers. This has the benefit of keeping a hidden primary/master server within the corporate infrastructure for administration of the zones. With this structure in place, management of the server and/or downtime at this server will not impact access to the organization’s web properties. For security, the firewall should be configured to only allow communication to and from the secondary servers.

Once this architecture is in place, the choices and scope of the secondary infrastructure is based on organizational needs and risk tolerance.

DNS nameserver addressing methodologies

Like any server infrastructure, it is best practice to have redundancy built into the DNS infrastructure. There are two methods of addressing DNS nameservers:

• Unicast

  Broadly applied, unicast is the communication from a single sender to a single receiver on a network. As it applies to the DNS it is a one-to-one association between a network address and the end-point. In other words, if the unicast DNS has 2 records (ns1 and ns2) then each corresponds to exactly one server. This does not preclude building in redundancy at unicast nodes or having more than one node online to answer queries, but it does not afford the full suite of benefits of an anycast solution for external DNS resolution.

• Anycast

  Anycast is one of several routing schemes that can be used to control the flow of traffic across a network, typically using the Border Gateway Protocol (BGP). With anycast DNS, multiple nodes that are copies of each other are geographically dispersed. In this way, multiple servers sit behind identical IP addresses and answers to queries are always done by the geographically closest node. Benefits of an anycast network include: lower latency,
  increased redundancy, and higher resilience to DNS DDoS attacks.

Anycast for the secondary DNS service 

Much like other organizational decisions, the provisioning of DNS secondary services comes down to a, “build, buy, or both” decision. Whatever is chosen, adding an anycast secondary DNS service improves speed and resiliance for the organization’s web properties and services.

If a secondary DNS service architecture is already in place, whether in house or from a service provider, this does not preclude adding additional secondary DNS services. By incrementally adding new services to their DNS an IT manager can improve speed and resilience for their web properties and can get additional benefits from geo-focused services. For instance, CIRA runs the D-Zone Anycast DNS Service, which offers both global and local secondary nodes, where the local nodes are set-up to serve Canadian traffic and to protect the Canadian traffic from external DDoS attacks. In business parlance, the D-Zone solution will help protect a company’s Canadian audience and related objectives while also improving global reach through nodes located in Internet hubs around the world.

DDoS attacks on the DNS are a top operations threat with “one-third of DNS operators having experienced a customer-impacting attack” – Arbor 2016 Worldwide Infrastructure Security Report.

Read the DNS glossary to learn more