What is a DNS server?

Whenever a user types a domain name (such as ‘refuge.com’) into their browser window, this triggers a DNS lookup. A series of remote computers known as DNS servers then find the IP address for that domain and return it to the user’s computer so that they can access the correct website.

Several different types of DNS servers must work in conjunction to complete a DNS lookup. A DNS resolver, DNS root server, DNS TLD server, and DNS authoritative nameserver must all provide information to complete the lookup. In the case of caching, one of these servers may have saved the answer to a query during a previous lookup, and can then deliver it from memory.

What is a DNS query?

A DNS query (also known as a DNS request) is a demand for information sent from a user’s computer (DNS client) to a DNS server. In most cases a DNS request is sent, to ask for the IP address associated with a domain name. An attempt to reach a domain, is actually a DNS client querying the DNS servers to get the IP address, related to that domain.

Types of queries

In general, there are two ways of resolving a host or a domain name to an IP address, using the domain name system – a Recursive query and a non-Recursive query.

The Recursive query is, when a DNS client directly gets the IP address of a domain, by asking the name server system to perform the complete translation.

The non-Recursive query is, when a DNS client contacts the name servers, one by one, until it finds the server, containing the needed information.

How do they work?

The process behind Recursive queries, can be explained by the following example:

1. A user opens up his favorite browser and enters https://www.somedomain.com in the address bar. His computer does not know the IP address for www.somedomain.com, so it sends a request to the user’s DNS resolver.
2. The resolver does not know the IP address for www.somedomain.com, so it will query one of the root DNS servers.
3. The root servers know the locations of all the TLDs, such as .com, they do not know the IP of www.somedomain.com, so they return the location of the .com servers.
4. Once the query reaches the .com TLD servers, it will find the Authoritative DNS server of www.somedomain.com and will reply to the resolver with that server.
5. The resolver will send a query to the Authoritative DNS server of the domain and will resolve it.
6. The Authoritative DNS server of the domain will check within its database and will find an entry for www.somedomain.com, which has an IP address.
7. Finally the resolver will know the IP address for www.somedomain.com and will send the result to the user’s computer.

The process behind non-Recursive queries, follows the same procedure, but the DNS client (the machine from which the user tries to resolve the domain) will have to find the authoritative DNS server for the domain, by itself.
The DNS client will have to ask by itself, first the root servers, then the TLD servers and finally the Authoritative DNS server to be able to resolve the domain.

What is recursive DNS?

A recursive DNS lookup is where one DNS server communicates with several other DNS servers to hunt down an IP Address and return it to the client. This is in contrast to an iterative DNS query, where the client communicates directly with each DNS server involved in the lookup. While this is a very technical definition, a closer look at the DNS system and the difference between recursion and iteration should help clear things up.

What is the difference between recursion and iteration?

Recursion and iteration are computer science terms that describe two different methods to solve a problem. In recursion, a program repeatedly calls itself until a condition is met, while in iteration, a set of instructions is repeated until a condition is met. This subtle difference is hard to illustrate without getting into code, but the key takeaway is that recursion is a solution that repeatedly calls upon itself.

For example, imagine that Jim lost his keys at home and is looking for a systematic way to find them. A recursive solution would be for Jim to keep looking for his keys until he finds them. Jim will start looking, and if he doesn’t find his keys, he will return to his original instruction to keep looking until he finds them. An iterative solution would be for Jim to to search one room for five minutes, then go back to his instructions and search the next room for five minutes, and continue this cycle until he either finds his keys or has gone through the entire list of rooms to search.

A deep understanding of recursion and iteration isn’t necessary to comprehend the difference between recursive and iterative DNS lookups: In a recursive lookup, a DNS server does the recursion and continues querying other DNS servers until it has an IP address to return to the client (often a user’s operating system). In an iterative DNS query, each DNS query responds directly to the client with an address for another DNS server to ask, and the client continues querying DNS servers until one of them responds with the correct IP address for the given domain.

Put another way, the client does a form of delegation in a recursive DNS query. It tells the DNS resolver, “Hey, I need the IP address for this domain, please hunt it down and don’t get back to me until you have it.” Meanwhile, in an iterative query, the client tells the DNS resolver, “Hey, I need the IP address for this domain. Please let me know the address of the next DNS server in the lookup process so I can look it up myself.”

WHAT IS RECURSIVE QUERY IN SQL?

If you are an SQL programmer, learning recursive SQL techniques can be a boon to your productivity. A recursive query is one that refers to itself. I think the best way to quickly grasp the concept of recursion is to think about a mirror that is reflected into another mirror and when you look into it you get never-ending reflections of yourself. This is recursion in action.

Different DBMS products implement recursive SQL in different ways. Recursion is implemented in standard SQL-99 using common table expressions (CTEs). DB2, Microsoft SQL Server, Oracle and PostgreSQL all support recursive queries using CTEs. Note that Oracle also offers an alternative syntax using the CONNECT BY construct, which we will not discuss here.

A CTE can be thought of as a named temporary table within a SQL statement that is retained for the duration of that statement. There can be many CTEs in a single SQL statement but each must have a unique name. A CTE is defined at the beginning of a query using the WITH clause.

Now before we dive into recursion, let’s first look at some data that would benefit from being read recursively. Figure 1 shows a hierarchic organization chart.

Figure 1. A sample hierarchy.

A table holding this data could be set up as follows:

    CREATE TABLE ORG_CHART

      (MGR_ID        SMALLINT,
       EMP_ID        SMALLINT,

       EMP_NAME      CHAR(20))
    ;

Of course, this is a simple implementation and many more columns would likely be needed for a production hierarchy. But the simplicity of this table will suit our purposes for learning recursion. To make the data in this table match our diagram, we would load the table as follows:

MGR_ID             EMP_ID         EMP_NAME

  -1                 1            BIG BOSS

  1                  2            LACKEY

  1                  3            LIL BOSS

  1                  4            BOOTLICKER

  2                  5            GRUNT

  3                  6            TEAM LEAD

  6                  7            LOW MAN

  6                  8            SCRUB

The MGR_ID for the top-most node is set to some value indicating that there is no parent for this row, in this case –1 is used. Now that we have loaded the data we can code a query to walk the hierarchy using recursive SQL. Suppose we need to report on the entire organizational structure under LIL BOSS. The following recursive SQL using a CTE will do the trick:

     WITH EXPL (MGR_ID, EMP_ID, EMP_NAME) AS

     (

      SELECT ROOT.MGR_ID, ROOT.EMP_ID, ROOT.EMP_NAME

      FROM   ORG_CHART   ROOT

      WHERE  ROOT.MGR_ID = 3

      UNION ALL

      SELECT CHILD.MGR_ID, CHILD.EMP_ID, CHILD.EMP_NAME

      FROM   EXPL PARENT, ORG_CHART CHILD

      WHERE  PARENT.EMP_ID = CHILD.MGR_ID

     )

     SELECT   DISTINCT MGR_ID, EMP_ID, EMP_NAME

     FROM     EXPL

     ORDER BY MGR_ID, EMP_ID;

The results of running this query would be:

MGR_ID             EMP_ID         EMP_NAME

  1                  3            LIL BOSS

  3                  6            TEAM LEAD

  6                  7            LOW MAN

  6                  8            SCRUB

Let’s break this somewhat complex query down into its constituent pieces to help understand what is going on. First of all, a recursive query is implemented using the WITH clause (using a CTE). The CTE is named EXPL. The first SELECT primes the pump to initialize the “root” of the search. In our case, to start with EMP_ID 3, that is LIL BOSS.

The next SELECT is an inner join combining the CTE with the table upon which the CTE is based. This is where the recursion comes in. A portion of the CTE definition refers to itself. Finally, we SELECT from the CTE.  Similar queries can be written to completely explode the hierarchy to retrieve all the descendants of any given node.

Recursive SQL can be very elegant and efficient. However, because of the difficulty developers can have understanding recursion, it is sometimes thought of as “too inefficient to use frequently.” But, if you have a business need to walk or explode hierarchies in your database, recursive SQL will likely be your most efficient option. What else are you going to do? You can create pre-exploded tables, but this requires denormalization and a lot of pre-processing which will not be efficient. Or you might write your own code to walk a hierarchy. This, too, is fraught with potential problems. You will probably retrieve more data than you need, causing inefficient I/O. And how will you assure that your code is more efficient than the DBMS?

If every row processed by the query is required in the answer set (“find all employees who work for LIL BOSS”), then recursion will most likely be quite efficient. If only a few of the rows processed by the query are actually needed (“find all flights from Houston to Pittsburgh, but show only the three fastest”) then a recursive query can be quite costly. The bottom line is that you should consider recursive SQL when business requirements call for it. But be sure that suitable indexes are available and always examine your access path

ADVANTAGES AND DISADVANTAGES OF RECURSIVE QUERY IN DNS

What are the advantages of recursive DNS?

Recursive DNS queries generally tend to resolve faster than iterative queries. This is due to caching. A recursive DNS server caches the final answer to every query it performs and saves that final answer for a certain amount of time (known as the Time-To-Live).

When a recursive resolver receives a query for an IP address it already has in its cache, it can rapidly provide the cached answer to the client without communicating with any other DNS servers. Quickly serving responses from the cache is very likely if a) the DNS server serves a lot of clients and/or b) the requested website is very popular.

What are the disadvantages of recursive DNS?

Unfortunately, allowing recursive DNS queries on open DNS servers creates a security vulnerability, as this configuration can enable attackers to perform DNS Application Attacks and DNS Cache poisoning

Recursive DNS servers and DNS amplification attacks

In a DNS amplification attack, an attacker typically uses a group of machines (known as a botnet) to send a high volume of DNS queries using a Spoofed IP  address. A spoofed IP address is like a forged return address; the attacker is sending requests from their own IP, but asking for the responses to go to the victim. In order to exacerbate the attack, the attacker also uses a technique called amplification, in which the spoofed request asks for a very long response. The victimized service will receive a flood of lengthy and unwanted DNS responses that can disrupt or even take down their servers. This is a type of DDos attack.

This is kind of like a group of teenage pranksters calling a pizza place and each ordering a dozen pizzas. Instead of giving their own address for delivery, they give the address of an unsuspecting neighbor. The victim, who then receives a stream of large and unwanted pizza deliveries, will likely experience a lot of disruption in their day.

A DNS server that accepts recursive queries is needed to carry out this kind of attack, because the amplified DNS packets are responses to recursive DNS queries.

Recursive DNS servers and DNS cache poisoning attacks

In a DNS cache poisoning attack, when a recursive DNS server requests an IP address from another DNS server, an attacker intercepts the request and gives a fake response, which is often the IP address for a malicious website. Not only does the recursive DNS server send the original client this IP address, but the server will also save the response in its cache. Any user that requests an IP for the same domain name will be sent to the malicious website. If it’s a popular domain name and a popular DNS resolver, this attack could affect thousands of users.

In an iterative DNS query, the client directly asks each DNS server for the answer. Even if an attacker is able to send a forged response to the query, it will only affect a single client, which is generally not worth the attacker’s time.

Drop your comment