Posts tagged: Time-to-Live (TTL)

Basics: DNS Structure and Process

Most of us take Internet surfing for granted. However, much is happening to make this work for you. We must consider the technology behind our simple ability to type a domain universal resource locator, aka URL, in our browsers and arrive at the landing page. The DNS structure is based on a DNS hierarchy, which makes reaching the landing page possible in seconds.

The DNS architecture consists of a hierarchical and decentralized name resolution system for resources connected to the Internet. It stores the associated information of the domain names assigned to each resource.

Thousands of DNS servers are distributed and hierarchical, but they need a complete database of all hostnames, domain names, and IP addresses. If a DNS server does not have information for a specific domain, it may have to ask other DNS servers for help. A total of 13 root name servers contain information for top-level domains such as com, net, org, biz, edu, or country-specific domains such as uk, nl, de, be, au, ca, etc.

That allows them to be reachable via the DNS resolution process. DNS queries for a resource pass through the DNS – with the URLs as parameters. Then, the DNS takes the URLs, translates them into the target IP addresses, and sends the queries to the correct resource.

Guide: DNS Process

Domain Name System

Now that you have an idea of DNS, let’s look at an example of a host that wants to find the IP address of a hostname. The host will send a DNS request and receive a DNS reply from the server. The following example shows I have a Cisco Router set up as a DNS server. I also have several public name servers configured with an external connector.

With Cisco Modelling Labs, getting external access with NAT is relatively easy. Set your connecting interface to DHCP, and the external connecter does the rest.

Note:

In the example below, the host will now send a DNS request to find the IP address of bbc.co.uk. Notice the packet capture output. Below, you can see that the DNS query uses UDP port 53. The host wants to know the IP address for bbc.co.uk. Here’s what the DNS server returns:

One of Dig’s primary uses is retrieving DNS records. By querying a specific domain, Dig can provide information such as the IP address associated with the domain, mail server details, and even the DNS records’ time-to-live (TTL) value. We will explore the types of DNS records that can be queried using Dig, including A, AAAA, MX, and NS records.

• Advanced Dig Techniques

Dig goes beyond simple DNS queries. It offers advanced techniques to extract more detailed information. We will uncover how to perform reverse DNS lookups, trace the DNS delegation path, and gather information about DNSSEC (Domain Name System Security Extensions). These advanced techniques can be invaluable for network administrators and security professionals.

• Using Dig for Troubleshooting

Dig is a powerful troubleshooting tool that can help diagnose and resolve network-related issues. We will cover common scenarios where Dig can rescue, such as identifying DNS resolution problems, checking DNS propagation, and verifying DNSSEC signatures. 

Understanding the Basic Syntax

Dig command follows a straightforward syntax: `dig [options] [domain] [type]`. Let’s break it down:

• • Options: Dig offers a range of options to customize your query. For example, the “+short” option provides only concise output, while the “+trace” option traces the DNS delegation path.
  • Domain: Specify the domain name you want to query. It can be a fully qualified domain name (FQDN) or an IP address.
  • Type: The type parameter defines the type of DNS record to retrieve. It can be A, AAAA, MX, NS, and more.

Exploring Advanced Functionality

Dig offers more advanced features that can enhance your troubleshooting and analysis capabilities.

• • Querying Specific DNS Servers: The “@server” option lets you query a specific DNS server directly. This can be useful for testing DNS configurations or diagnosing issues with a particular server.
  • Reverse DNS Lookup: Dig can perform reverse DNS lookups using the “-x” option followed by the IP address. This lets you obtain the domain name associated with a given IP address.

Analyzing DNSSEC Information

DNSSEC (Domain Name System Security Extensions) provides a layer of security to DNS. Dig can assist in retrieving and verifying DNSSEC-related information.

• • Checking DNSSEC Validation: The “+dnssec” option enables DNSSEC validation. Dig will fetch the DNSSEC signatures for the queried domain, allowing you to ensure the integrity and authenticity of the DNS responses.

Troubleshooting DNS Issues

Dig proves to be a valuable tool for troubleshooting DNS-related problems.

• • Checking DNS Resolution: By omitting the “type” parameter, Dig retrieves the default A record for the specified domain. This can help identify if the DNS resolution is functioning correctly.
  • Analyzing Response Times: Dig provides valuable information about response times, including the time DNS servers take to respond to queries. This can aid in identifying latency or performance issues.

DNS Architecture

DNS is a hierarchical system, with the root at the top and various levels of domains, subdomains, and records below. The Internet root server manages top-level domains such as .com, .net, and .org at the root level. These top-level domains are responsible for managing their subdomains and records.

Below the top-level domains are the authoritative nameservers, which are responsible for managing the records of the domains they are responsible for. These authoritative nameservers are the source of truth for the DNS records and are responsible for responding to DNS queries from clients.

At the DNS record level, there are various types of records, such as A (address) records, MX (mail exchange) records, and CNAME (canonical name) records. Each record type serves a different purpose and provides information about the domain or subdomain.

Name Servers:

Name servers are the backbone of the DNS structure. They store and distribute DNS records, including IP addresses associated with domain names. When a user enters a domain name in their web browser, the browser queries the nearest name server to retrieve the corresponding IP address. Name servers are distributed globally, ensuring efficient and reliable DNS resolution.

Primary name servers, also known as master servers, are responsible for storing the original zone data for a domain. Secondary name servers, or slave servers, obtain zone data from primary servers and act as backups, ensuring redundancy and improved performance. Additionally, caching name servers, often operated by internet service providers (ISPs), store recently resolved domain information, reducing the need for repetitive queries.

DNS Zones:

A DNS zone refers to a specific portion of the DNS namespace managed by an authoritative name server. Zones allow administrators to control and maintain DNS records for a particular domain or subdomain. Each zone consists of resource records (RRs) that hold various types of information, such as A records (IP addresses), MX records (mail servers), CNAME records (aliases), and more.

Google Cloud DNS

**Understanding DNS Zones: The Building Blocks of Google Cloud DNS**

At the heart of Google Cloud DNS are DNS zones. A zone represents a distinct portion of the DNS namespace within the Google Cloud DNS service. There are two types of zones: public and private. Public zones are accessible over the internet, while private zones are accessible only within a specific Virtual Private Cloud (VPC) network. Understanding these zones is critical as they determine how your domain names are resolved, affecting how users access your services.

**Creating and Managing Zones: Your Blueprint to Success**

Creating a DNS zone in Google Cloud is a straightforward process. Begin by accessing the Google Cloud Console, navigate to the Cloud DNS section, and click on “Create Zone.” Here, you’ll need to specify a name, DNS name, and whether it’s a public or private zone. Once created, managing zones involves adding, editing, or deleting DNS records, which dictate the behavior of your domain and subdomains. This flexibility allows for precise control over your domain’s DNS settings, ensuring optimal performance and reliability.

**Integrating Zones with Other Google Cloud Services**

One of the standout features of Google Cloud DNS is its seamless integration with other Google Cloud services. For instance, when using Google Kubernetes Engine (GKE), you can automatically create DNS records for services within your clusters. Similarly, integrating with Cloud Load Balancing allows for automatic updates to DNS records, ensuring your applications remain highly available and responsive. These integrations exemplify the power and versatility of managing zones within Google Cloud DNS, enhancing your infrastructure’s scalability and efficiency.

**DNS Resolution Process**

When a user requests a domain name, the DNS resolution occurs behind the scenes. The resolver, usually provided by the Internet Service Provider (ISP), starts by checking its cache for the requested domain’s IP address. If the information is not cached or has expired, the resolver sends a query to the root name servers. The root name servers respond by directing the resolver to the appropriate TLD name servers. Finally, the resolver queries the authoritative name server for the specific domain and receives the IP address.

DNS Caching:

Caching is implemented at various levels to optimize the DNS resolution process and reduce the load on name servers. Caching allows resolvers to store DNS records temporarily, speeding up subsequent requests for the same domain. However, caching introduces the challenge of ensuring timely updates to DNS records when changes occur, as outdated information may persist until the cache expires.

DNS Traffic Flow:

First, two concepts are essential to understand. Every client within an enterprise network won’t be making external DNS queries. Instead, they make requests to the local DNS server or DNS resolver, which makes the external queries on their behalf. The communication chain for DNS resolve can involve up to three other DNS servers to fully resolve any hostname. The other concept to consider is caching. Before a client requests a DNS server, it will check the local browser and system cache.

DNS records are cached in three locations

In general, DNS records are cached in three locations, and keeping these locations secured is essential. First is the browser cache, which is usually stored for a very short period. If you’ve ever had a problem with a website fixed by closing and reopening or browsing with an incognito tab, the root issue probably had something to do with the page being cached. Next is the operating system cache. It doesn’t make sense for a server to make hundreds of requests when multiple users visit the same page, so this efficiency is beneficial. However, it still presents a security risk.

Role of UDP and DNS:

Regarding DNS, UDP is crucial in facilitating fast and lightweight communication. Unlike TCP (Transmission Control Protocol), which guarantees reliability but adds additional overhead, UDP operates in a connectionless manner. This means that UDP packets can be sent without establishing a formal connection, making it ideal for time-sensitive applications like DNS. UDP’s simplicity enables faster communication, eliminating the need for acknowledgments and other mechanisms present in TCP.

**The DNS Query Process**

Let’s explore the typical DNS query process to understand how DNS and UDP work together. When a user enters a domain name in their browser, the DNS resolver initiates a query to find the corresponding IP address. The resolver sends a DNS query packet, typically UDP, to the configured DNS server. The server then processes the query, searching its database for the requested information. Once found, the server sends a DNS response packet back to the resolver, enabling the user’s browser to establish a connection with the website.

**Ensuring Reliability in DNS with UDP**

While UDP’s connectionless nature provides speed advantages, it also introduces challenges in terms of reliability. Since UDP does not guarantee packet delivery or order, there is a risk of lost or corrupted packets during transmission. DNS implements various mechanisms to address this, such as retrying queries, caching responses, and even falling back to TCP when necessary. These measures ensure that DNS remains a reliable and robust system despite utilizing UDP as its underlying protocol.

Introducing DNS TCP

TCP, or Transmission Control Protocol, is another DNS protocol employed for specific scenarios. Unlike UDP, TCP provides reliable, connection-oriented communication. It ensures that all data packets are received in the correct order, making it suitable for scenarios where accuracy and reliability are paramount.

Use Cases for DNS TCP

While DNS UDP is the default choice for most DNS queries and responses, DNS TCP comes into play in specific situations. Large DNS responses that exceed the maximum UDP packet size can be transmitted using TCP. Additionally, DNS zone transfers, which involve the replication of DNS data between servers, rely on TCP due to its reliability.

In conclusion, DNS relies on UDP and TCP protocols to cater to various scenarios and requirements. UDP offers speed and efficiency, making it ideal for most DNS queries and responses. On the other hand, TCP ensures reliability and accuracy, making it suitable for large data transfers and zone transfers. 

Guide: Delving into DNS data

DNS Capture

In the lab guide, we will delve more into DNS data. Before digging into the data, it’s essential to understand some general concepts of DNS:

To browse a webpage (www.network-insight.net), the computer must convert the web address to an IP address. DNS is the protocol that accomplishes this

DNS involves queries and answers. You will make a query to resolve a web address. In response, your DNS Server (typically the Active Directory Server for an enterprise environment) will respond with an answer called a resource record. There are many types of DNS records. Notice below in the Wireshark capture, I am filtering only for DNS traffic.

In this section, you will generate some sample DNS traffic. By simply browsing www.network-insight.net, you will initiate a DNS query to resolve the IP. I have an Ubuntu host running on a VM. Notice that your first query is an “A” query, requesting an IPv4 address for www.network-insight.net. This is the most common form of DNS request.

As part of your web request, this automatically initiated two DNS queries. The second (shown here) is an “AAAA” query requesting an IPv6 address.

Note: In most instances, the “A” record response will be returned first; however, in some cases, you will see the “AAAA” response first. In either instance, these should be the 3rd and 4th packets.

Analysis:

• • The IP header contains IPv4 information. This is the communication between the host making the request (192.168.18.130) and the DNS Server (192.168.18.2). Typical DNS operates over UDP, but sometimes it works over TCP. DNS over UDP can open up some security concerns.
  • This means there’s no error checking or tracking in the network communication. Because of this, the DNS server will return a copy of the original query in the response to ensure they stay matched up.
  • Next are two A records containing the IPv4 answers. It’s pervasive for popular domains to have multiple IPs for load-balancing purposes.

Nslookup stands for “name server lookup.” It is a command-line tool for querying the Domain Name System (DNS) and obtaining information about domain names, IP addresses, and other DNS records. Nslookup is available on most operating systems and provides a simple yet powerful way to investigate DNS-related issues.

Nslookup offers a range of commands that allow users to interact with DNS servers and retrieve specific information. Some of the most commonly used commands include querying for IP addresses, performing reverse lookups, checking DNS records, and troubleshooting DNS configuration problems.

1. Use the -query option to request only an ‘A’ record:
   nslookup -query=A www.network-insight.net
2. Use the -debug option to display the full response information:
   nslookup -debug www.network-insight.net: This provides a much more detailed response, including the Time-to-Live (TTL) values and any additional record information returned.
3. You can also perform a reverse DNS lookup by sending a Pointer Record (PTR) and the IP address:
   nslookup -type=ptr xx.xx.xx.xx

Analysis: 

The result is localhost, despite us knowing that the IP given belongs to www.network-insight.net. This is a security strategy to bypass source address checks and prevent individuals from performing PTR lookups for some domains.

DNS Scalability and Redundancy

Scalability refers to the ability of a system to handle increasing amounts of traffic and data without compromising performance. In the context of DNS, scalability is crucial to ensure that the system can efficiently handle the ever-growing number of domain name resolutions. Various techniques, such as load balancing, caching, and distributed architecture, are employed to achieve scalability.

• Load Balancing for Scalability

Load balancing is vital in distributing incoming DNS queries across multiple servers. By evenly distributing the workload, load balancers prevent any server from overloading, ensuring optimal performance. Techniques like round-robin or dynamic load-balancing algorithms help achieve scalability by efficiently managing traffic.

• Caching for Improved Performance

Caching is another crucial aspect of DNS scalability. By storing recently resolved domain names and their corresponding IP addresses, caching servers can respond to queries without the need for recursive lookups, significantly reducing response times. Implementing caching effectively reduces the load on authoritative DNS servers, improving overall scalability.

• Achieving Redundancy with DNS

Redundancy is vital to ensure high availability and fault tolerance in DNS. It involves duplicating critical components of the DNS infrastructure to eliminate single points of failure. Redundancy can be achieved by implementing multiple authoritative DNS servers, using secondary DNS servers, and employing DNS anycast.

• Secondary DNS Servers

Secondary DNS servers act as backups to primary authoritative servers. They replicate zone data from the primary server, allowing them to respond to queries if the primary server becomes unavailable. By distributing the workload and ensuring redundancy, secondary DNS servers enhance the scalability and reliability of the DNS system.

• DNS Anycast for Improved Resilience

DNS anycast is a technique that allows multiple servers to advertise the same IP address. When a DNS query is received, the network routes it to the nearest anycast server, improving response times and redundancy. This distributed approach ensures that even if some anycast servers fail, the overall DNS service remains operational.

Knowledge Check: Authoritative Name Server

Understanding the Basics

Before we dive deeper, let’s start with the fundamentals. An authoritative name server is responsible for providing the official DNS records of a domain name. When a user types a website address into their browser, the browser sends a DNS query to the authoritative name server to retrieve the corresponding IP address. These servers hold the authoritative information for specific domain names, making them an essential component of the DNS hierarchy.

The Functioning of Authoritative Name Servers

Now that we have a basic understanding, let’s explore how authoritative name servers function. When a domain is registered, the registrar collects the necessary information and updates the top-level domain’s (TLD) authoritative name servers with the domain’s DNS records. These authoritative name servers act as the primary source of information for the domain, serving as the go-to reference for any DNS queries related to that domain.

Caching and Zone Transfers

Caching plays a crucial role in the efficient operation of authoritative name servers. Caching allows these servers to store previously resolved DNS queries, reducing the overall response time for subsequent queries. Additionally, authoritative name servers employ zone transfers to synchronize DNS records with secondary name servers. This redundancy ensures reliability and fault tolerance in case of primary server failures.

Load Distribution and Load Balancing

In the modern landscape of high-traffic websites, load distribution and load balancing are vital considerations. Authoritative name servers can employ various techniques to distribute the load evenly across multiple servers, such as round-robin DNS or geographic load balancing. These strategies help maintain optimal performance and prevent overwhelming any single server with excessive requests.

Domain Name System Fundamentals

DNS Tree

The domain name system (DNS) is a naming database in which Internet domain names are located and translated into Internet Protocol (IP) addresses. It uses a hierarchy to manage its distributed database system. The DNS hierarchy, also called the domain name space, consists of a DNS tree with a single domain at the top of the structure called the root domain.

Consider DNS a naming system that is both hierarchical and distributed. Because of the hierarchical structure, you can assign the same “label” to multiple machines (for example, www.abc.com maps to 10.10.10.10 and 10.10.10.20).

Domain Name System and its Operations

DNS servers are machines that respond to DNS queries sent by clients. Servers can translate names and IP addresses. There are differences between an authoritative DNS server and a caching server. A caching-only server is a name server with no zone files. It is not authoritative for any domain.

Caching speeds up the name-resolution process. This server can help improve a network’s performance by reducing the time it takes to resolve a hostname to its IP address. This can minimize web browsing latency, as the DNS server can quickly resolve the hostname and connect you to the website. A DNS caching server can also reduce the network’s data traffic, as DNS queries are sent only once, and the cached results are used for subsequent requests.

It can be viewed as a positive and negative element of DNS. Caching reduces the delay and number of DNS packets transmitted. On the negative side, it can produce stale records, resulting in applications connecting to invalid IP addresses and increasing the time applications failover to secondary services.

Ensuring that the DNS caching server is configured correctly is essential, as it can cause issues if the settings are incorrect. Additionally, it is crucial to ensure that the server is secure and not vulnerable to malicious attacks.

• A key point: Domain name system and TTL

The Time-to-Live (TTL) fields play an essential role in DNS. It controls how long a record should be stored in the cache. Choosing the suitable TTL timer per application is an important task. A short TTL can send too many queries, while a long TTL can’t capture any changes in the records.

DNS proxies and DNS resolvers respect the TTL setting for the form and usually honor TTL values as they should be. However, applications do not necessarily keep the TTL, which becomes problematic with failover events.

Site-selection considerations: Load balance data centers?

DNS is used to perform site selection. Multi-data centers use different IP endpoints in each data center, and DNS-based load balancing is used to send clients to one of the data centers. The design is to start using random DNS responses and slowly migrate to geo-location-based DNS load balancing. There are many load-balancing strategies, and different methods match different requirements.

Google Cloud DNS Routing Policy

Google Cloud DNS

DNS routing policies steer traffic based on query (for example, round robin or geolocation). You can configure routing policies by creating special ResourceRecordSets (in the collection sense) with particular routing policy values.

We will examine Cloud DNS routing policies in this lab. Users can configure DNS-based traffic steering using cloud DNS routing policies. Routing policies can be divided into two types. 

Note:

1. There are two types of routing policies: Weighted Round Robin (WRR) and Geolocation (GEO). Creating ResourceRecordSets with particular routing policy values can be used to configure routing policies.
2. When resolving domain names, use WRR to specify different weights per ResourceRecordSet. By resolving DNS requests according to the configured weights, cloud DNS routing policies ensure traffic is distributed across multiple IP addresses.
3. I have configured the Geolocation routing policy in this lab. Provide DNS answers corresponding to source geo locations using GEO. The geolocation routing policy applies to the nearest match if the traffic source location does not match any policy items exactly.
4. Here, we have a Cloud DNS routing policy, create ResourceRecordSets for geo.example.com, and configure the Geolocation policy to help ensure a client request is routed to a server in the client’s closest region.

Above, we have three client VMs in the same default VPC but in different regions. There is a Europe, USA, and Asia region. There is a web server in the European region and one in the USA region. There is no web server in Asia.

I have created a firewall to allow access to the VMs. I have permitted SSH to the client VM for testing and HTTP for the webservers to accept CURL commands when we try the geolocation.

Analysis:

It’s time to test the configuration; I SSH into all the client VMs. Since all of the web server VMs are behind the geo.example.com domain, you will use cURL command to access this endpoint.

Since you are using a Geolocation policy, the expected result is that:

• • Clients in the US should always get a response from the US-East1 region.
  • The client in Europe should always get a response from the Europe-West2 region.
  • Since the TTL on the DNS record is set to 5 seconds, a sleep timer of 6 seconds has been added. The sleep timer will ensure you get an uncached DNS response for each cURL request. This command will take approximately one minute to complete.
  • When we run this test multiple times and analyze the output to see which server is responding to the request, the client should always receive a response from a server in the client’s region.

**The Power of DNS Security**

DNS Security is a critical component of cloud security, and the Security Command Center excels in this area. DNS, or Domain Name System, is like the internet’s phone book, translating domain names into IP addresses. Unfortunately, it is also a common target for cyber attacks. SCC’s DNS Security features help identify and mitigate threats like DNS spoofing and cache poisoning. By continuously monitoring DNS traffic, SCC alerts users to suspicious activities, ensuring that your cloud infrastructure remains secure from DNS-based attacks.

**Maximizing Visibility with Google Cloud’s SCC**

One of the standout features of the Security Command Center is its ability to provide a unified view of security across all Google Cloud assets. With SCC, users can effortlessly track security metrics, detect vulnerabilities, and receive real-time alerts about potential threats. This centralized visibility means that security teams can respond swiftly to incidents, minimizing potential damage. Additionally, SCC’s integration with other Google Cloud services ensures a seamless security experience.

**Leveraging SCC for Threat Detection and Response**

Threat detection and response are crucial elements of any robust security strategy. The Security Command Center enhances these capabilities by employing advanced analytics and machine learning to identify and respond to threats. By analyzing patterns and anomalies in cloud activities, SCC can predict potential security incidents and provide actionable insights. This proactive approach not only protects your cloud environment but also empowers your security team to stay ahead of evolving threats.

Knowledge Check: DNS-based load balancing

DNS-based load balancing is an approach to distributing traffic across multiple hosts by using DNS to map requests to the appropriate host. It is a cost-effective way of scaling and balancing a web application or website load across multiple servers.

With DNS-based load balancing, each request is routed to the appropriate server based on DNS resolution. The DNS server is configured to provide multiple responses pointing to different servers hosting the same service.

The client then chooses one of the responses and sends its request to that server. The subsequent requests from the same client are sent to the same server unless the server becomes unavailable; in this case, the client will receive a different response from the DNS server and send its request to a different server.

DNS: Asynchronous Process

This approach has many advantages, such as improved reliability, scalability, and performance. It also allows for faster failover if one of the servers is down since the DNS server can quickly redirect clients to another server. Additionally, since DNS resolution is an asynchronous process, clients can receive near real-time responses and updates as servers are added or removed from the system.

Route Health Injection (RHI)

Try to combine the site selector ( the device that monitors the data centers) with routing, such as Route Health Injection ( RHI ), to overcome the limitation of cached DNS entries. DNS is used outside of performing load distribution among data centers, and Interior Gateway Protocol (IGP) is used to reroute internal traffic to the data center.

Avoid false positives by tuning the site selector accordingly. DNS is not always the best way to fail the data center. DNS failover can quickly influence 90 % of incoming data center traffic within the first few minutes.

If you want 100% of traffic, you will probably need additional routing tricks and advertising the IP of the secondary data center with conditional route advertisements or some other form of route injection.

Zone File Presentation

The application has changed, and the domain name system and DNS structure must be more intelligent. Users look up an “A” record for www.XYX.com, and there are two answers. When you have more than one answer, you have to think more about zone file presentation, what you offer, and based on what criteria/metrics.

Previously, the DNS structure was a viable solution with BIND. You had a primary/secondary server redundancy model with an exceedingly static configuration. People weren’t building applications with distributed data center requirements. Application requirements started to change in early 2000 with anycast DNS. DNS with anycast became more reliable and offered faster failover. Nowadays, performance is more of an issue. How quickly can you spit out an answer?

Ten years ago, to have the same application in two geographically dispersed data centers was a big deal. Now, you can spin up active-active applications in dispersed MS Azure and Amazon locations in seconds. Tapping new markets in different geographic areas takes seconds. The barriers to deploying applications in multi-data centers have changed, and we can now deploy multiple environments quickly.

Geographic routing and smarter routing decisions

Geographic routing is where you try to figure out where a user is coming from based on the Geo IP database. From this information, you can direct requests to the closest data center. Unfortunately, this doesn’t always work, and you may experience performance problems.

To make intelligent decisions, you need to take in all kinds of network telemetry about customers’ infrastructure and what is happening on the Internet now. Then, they can make more intelligent routing decisions. For this, you can analyze information about the end-user application to get an idea about what’s going on – where are you / how fast are your pipes, and what speed do you have?

The more they know, the more granular routing decisions are made. For example, are your servers overloaded, and at what point of saturation are your Internet or WAN pipes? They get this information using an API-driven approach, not dropping agents on servers.  

Geographical location – Solution

The first problem with geographical location is network performance. Geographical location is not relevant to how close things are. Second, you are looking at resolving the DNS server, not the client. You receive the IP address of the DNS resolver, not the end client’s IP address. Also, the user sometimes uses a DNS server that is not located where they are.

The first solution is an extension to DNS protocol – “EDNS client subnets.” This gets the DNS server to forward end-user information, including IP addresses. Google and OpenDNS will deliver the first three octets of the IP address, attempting to provide geographic routing based on the IP address of the actual end-user and not the DNS Resolver. To optimize response times or minimize packet loss, you should measure the metrics you are trying to optimize and then make a routing decision. Capture all information and then turn it into routing data.

Trying to send users to the “BEST” server varies from application to application. The word “best” really depends on the application. Some application performance depends heavily on response times. For example, streaming companies don’t care about RTT returning the first MPEG file. It depends on the application and what route you want.

DNS Structure & DNS Security designs

DNS pinning

DNS pinning is a technique to ensure that the IP address associated with a domain name remains consistent. It involves creating an association between a domain name and the IP address of the domain’s authoritative nameserver. This association is a DNS record and is stored in a DNS database.

When DNS pinning is enabled, an organization can ensure that the IP address associated with a domain name remains the same. This is beneficial in several ways. First, it helps ensure that users are directed to the correct server when accessing a domain name. Second, it helps prevent malicious actors from hijacking a domain name and redirecting traffic to a malicious server.

DNS Spoofing

So, the main reason for DNS pinning in browsers is enabled due to security problems with DNS spoofing. Browsers that don’t honor the TTL get stuck with the same IP for up to 15 minutes. Applications should always keep the TTL for reasons mentioned at the start of the post—no notion of session stickiness with DNS. DNS has no sessions, but you can have consistent routing hashing; the same clients go to the same data center.

Route hashing optimizes cache locality. It’s like stickiness for DNS and is used for data cache locality. However, most users use the same data center based on “source IP address” or other “EDNS client subnet” information.

Guide: Advanced DNS

DNS Advanced Configuration

Every client within a network won’t be making external DNS queries. Instead, they make requests to the local DNS Server or DNS Resolver, and it makes the external queries on their behalf. The communication chain for DNS Resolve can involve up to three other DNS servers to resolve any hostname fully. All of which need to be secured.

Note: The other concept to consider is caching. Before a client event requests the DNS Server, it will first check the local browser and system cache. DNS records are generally cached in three locations, and keeping these locations secured is essential.

• • First is the browser cache, which is usually stored for a very short period. If you’ve ever had a problem with a website fixed by closing/reopening or browsing with an incognito tab, the root issue probably had something to do with the page being cached.
  • Next is the Operating System (OS) cache. We will view this in the screenshot below.
  • Finally, we have the DNS Server’s cache. It doesn’t make sense for a Server to make hundreds of requests when multiple users visit the same page, so this efficiency is beneficial. However, it still presents a security risk.

Take a look at your endpoint’s DNS Server configuration. In most Unix-based systems, this is found in the resolv.conf file

Configuration options:

The resolv.conf file comprises various configuration options determining how the DNS resolver library operates. Let’s take a closer look at some of the essential options:

1. nameserver: This option specifies the IP address of the DNS server that the resolver should use for name resolution. Multiple nameserver lines can be included to provide backup DNS servers if the primary server is unavailable.

2. domain: This option sets the default domain for the resolver. When a domain name is entered without a fully qualified (FQDN), the resolver appends the domain option to complete the FQDN.

3. search: Similar to the domain option, the search option defines a list of domains that the resolver appends to incomplete domain names. This allows for easier access to resources without specifying the complete domain name.

4. options: The options option provides additional settings such as timeout values, the order in which the resolver queries DNS servers, and other resolver behaviors.

Analysis:

• • The nameserver is the IP address of the DNS server. In this case, 127.0.0.53 is listed because the “system-resolved” service is running. This service manages the DNS routing and local cache for this endpoint, which is typical for cloud-hosted endpoints. You can also have multiple nameservers listed here.
  • Options allow for certain modifications. In our example, edns0 allows for larger replies, and trust-ad is a configuration for DNSSEC and validating responses.

Now, look at your endpoint’s host file. This is a static mapping of domain names with IP addresses. Per the notice above, I have issued the command cat /etc/hosts. This file has not been modified and shows a typical configuration. If you were to send a request to localhost, an external DNS request is not necessary because a match already exists in the host’s file and will translate to 127.0.0.1.

The etc/hosts file, found in the root directory of Unix-based operating systems, is a simple text file that maps hostnames to IP addresses. It serves as a local DNS (Domain Name System) resolver, allowing the computer to bypass DNS lookup and directly associate IP addresses with specific domain names. Maintaining a record of these associations, the etc/hosts file expedites resolving domain names, improving network performance.

Finally, I modified the host’s file to redirect DNS to a fake IP address. This IP address does not exist. Notice that with the NSLookup command, DNS has been redirected to the fake IP.

**Final Points on DNS Tree Structure**

The DNS tree structure is a hierarchical organization of domain names, starting from the root domain and branching out into top-level domains (TLDs), second-level domains, and subdomains. It resembles an inverted tree, where each node represents a domain or subdomain, and the branches represent their relationship.

Components of the DNS Tree Structure:

a) Root Domain:

The root domain is at the top of the DNS tree structure, denoted by a single dot (.). It signifies the beginning of the hierarchy and is the starting point for all DNS resolutions.

b) Top-Level Domains (TLDs):

Below the root domain are the TLDs, such as .com, .org, .net, and country-specific TLDs like .uk or .de. Different organizations manage TLDs and are responsible for specific types of websites.

c) Second-Level Domains:

After the TLDs, we have second-level domains, the primary domains individuals or organizations register. Examples of second-level domains include google.com, apple.com, or microsoft.com.

d) Subdomains:

Subdomains are additional levels within a domain. They can be used to create distinct website sections or serve specific purposes. For instance, blog.google.com or support.microsoft.com are subdomains of their respective second-level domains.

A Distributed and Hierarchical database

The DNS system is distributed and hierarchical. Although there are thousands of DNS servers, none has a complete database of all hostnames/domain names / IP addresses. DNS servers can have information for specific domains, but they may have to query other DNS servers if they do not. Thirteen root name servers store information for generic top-level domains, such as com, net, org, biz, edu, or country-specific domains, such as UK, nl, de, be, au, ca.

13 root name servers at the top of the DNS hierarchy handle top-level domain extensions. For example, a name server for .com will have information on cisco.com, but it won’t know anything about cisco.org. It will have to query a name server responsible for the org domain extension to get an answer.

For the top-level domain extensions, you will find the second-level domains. Here’s where you can find domain names like Cisco, Microsoft, etc.

Further down the tree, you can find hostnames or subdomains. For example, tools.cisco.com is the hostname of the VPS (virtual private server) that runs this website. An example of a subdomain is tools.cisco.com, where vps.tools.cisco.com could be the hostname of a server in that subdomain.

How the DNS Tree Structure Works:

When a user enters a domain name in their web browser, the DNS resolver follows a specific sequence to resolve the domain to its corresponding IP address. Here’s a simplified explanation of the process:

– The DNS resolver starts at the root domain and queries the root name servers to identify the authoritative name servers for the specific TLD.

– The resolver then queries the TLD’s name server to find the authoritative name servers for the second-level domain.

– Finally, the resolver queries the authoritative name server of the second-level domain to obtain the IP address associated with the domain.

The DNS tree structure ensures the scalability and efficient functioning of the DNS. Organizing domains hierarchically allows for easy management and delegation of authority for different parts of the DNS. Moreover, it enables faster DNS resolutions by distributing the workload across multiple name servers.

The DNS structure serves as the backbone of the internet, enabling seamless and efficient communication between users and online resources. Understanding the hierarchical nature of domain names, the role of name servers, and the DNS resolution process empowers individuals and organizations to navigate the digital landscape easily. By grasping the underlying structure of DNS, we can appreciate its significance in enabling the interconnectedness of the modern world.