Overview Of The DNS Information Technology Essay

2.  Introduction

The DNS, Domain Name Service, plays a vital role in supporting the infrastructure of what we know the internet to be today, this is achieved by providing a distributed and robust instrument that helps to resolve host names into IP addresses and the other way when it resolves IP addresses back into host names. Along with this role DNS also supports other the capability to retrieve information relating to DNS Name Servers. But like all services that we use on a daily basis to access the Internet there are many security vulnerabilities that surround Internet Protocol and also the numerous other protocols that are carried by IP. So DNS is not alone or even immune from these security vulnerabilities. The information that is contained within DNS must be accurate as this information is vital to numerous aspects that are used in Internet Protocol communications.

The threats that are found with the use of DNS are in part due to its lack of authenticity and the checking of the data which is contained within DNS and to a smaller degree to the other protocols that also make use of host names as an access control mechanism. To combat these threats the Internet Engineering Task Force, IETF, created a group to add DNS Security extensions to the DNS protocol.

3.  Overview of the DNS

DNS or Domain Name System was first introduced in 1983 in RFC 882 (http://tools.ietf.org/html/rfc882) and RFC 883 (http://tools.ietf.org/html/rfc883), it was introduced to address an important need and also problem that the ever growing internet threw up. Originally how computers connected to the internet were that they used a text file named HOSTS.TXT, which was stored on a computer at Stanford Research Institute, (DNS and BIND by Cricket Liu, Paul Albitz, Fifth Edition, O Reilly Media, May 2006), what this file contained was the hostnames and addresses that were in use. The HOSTS.TXT file mapped names to numerical addresses. Obviously as the number of hosts and addresses grew so did the size of the HOSTS.TXT. Also what was needed was a way to make host address translations, as humans use words while computers use numbers. How a computer works in finding a web site is that for example we want to access www.google.ie this is called a Uniform Resource Locator, URL, which contains the domain name google.ie, but a computer is not able to read the domain name as computers use numbers and not letters to process requests. So what then happens is every time you use a domain name, you use the Internet’s domain name servers (DNS) to translate the human-readable domain name into the machine-readable IP address in the case of google.ie which is 209.85.143.104. Without DNS, the only way to connect to other hosts on the Internet would be to use their network address which would be a series of numbers. Using this numerical representation of an IP addresses to connect is not a very user-friendly way of locating another system on the Internet and thus the reasoning why DNS is relied upon to do the job of retrieving the desired IP address.

So what came about from all this is a distributed database that can map computer systems with a numerical IP address. What enabled this concept of a lookup facility to prevail was that it no longer relied on one authority the responsibility of this task.

If you want to connect to a system that supports Internet Protocol, then the host machine that is establishing the connection must know what the IP address of the system that they are connecting to in advance. An IP address can be defined as a numerical label that is assigned to a device be it a PC, Laptop or Printer. An IP address is a made up of a 32-bit number and this represents the specific location of the system on a network. This 32-bit address is broke into four octets separated by a dot, (“.”), and each octet is represented by a decimal number. The octets are separated by a decimal point. It is a lot easier to remember four decimal numbers than it is to remember thirty two 1’s and 0’s which is how a computer sees it as it uses the binary system. But having said that it is easier to remember decimal numbers as we do with phone numbers there is a finite amount of numbers than one could remember without having to look them up, does anyone know every phone number that are available in even the smallest telephone directory. So using this analogy the directory that is created by DNS is essentially the same as a phone book, in that it assigns host names to their equivalent IP address.

3. Fundamentals of DNS

DNS works in two ways which are called forward resolution and inverse resolution. Forward resolution is the supporting of the host name to a network address, and as stated it also incorporates inverse resolution whereby it supports network address to host name resolution. This fact that DNS can map a human friendly host or system name with a computer friendly numerical address, that it is a distributed database and is extremely robust helped it to evolve into a core component of the Internet. If it hadn’t prevailed the user would be left with the arduous task of trying to connect remote systems to each other using just numerical address of the host, this simple reason is the reason that DNS is heavily relied upon to fetch an IP address by just looking up a computers FQDN (Fully Qualified Domain Name), An FQDN is a domain name that specifies its exact location in the tree hierarchy of the DNS.

3. Domain Name Space

DNS is made up of a hierarchical tree structure and at the top of this tree is a root node that is known as the root domain. Each node in DNS has a label, but the root node contains an empty label in that it is of zero length. With the root label being zero length, all Fully Qualified Domain Names then end with a dot [RFC 1034]. And each label directly corresponds with a node in DNS. Labels are made up of an alphanumeric string which like IP addresses are connected together with a dot (“.”) and are wrote from left to right

In DNS a tree is travelled in an ascending manner, in other words from the bottom to the top or from leaf node to the root. Each node then as you move to the right become less specific as you can see in the diagram the leftmost www to the furthermost right fred. Usually with FQDN the label on the far left is the host name in our case here that is Microsoft and then the next label moving to the right is the local domain that the host belongs to. We then could have a sub domain of the local domain and this continues until the root is reached.Description: Description: http://www.rhyshaden.com/images/domain.gif

Fig 1.  Domain Name Space example

Image source http://www.rhyshaden.com/dns.htm

With inverse resolution were DNS is being used to map an IP address to a host name, then what happens is that it uses the same concept of labels going again from left to right or most specific to the least specific. This is different to how IP addresses are represented which is the least specific to the most specific. (http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800a67f5.shtml) So what DNS does to handle this is that an IP address is represented in reverse, and it the uses what is called a Top Level Domain, TLD, and this is known as IN-ADDR.ARPA. “IN-ADDR” stands for “INternet ADDRess”. Recall that “.ARPA” was originally used to transition old Internet hosts to DNS, and is now used by the folks that run the Internet for variouspurposes.(http://www.tcpipguide.com/free/t_DNSReverseNameResolutionUsingtheINADDRARPADomain-2.htm). So in doing this it uses IP addresses to find host names just like it would “lookup” to find an IP address.

Description: Description: C:Userswebactivate51Desktopin-addr2.gif

Fig 2.  inverse domains and the Domain Name Space

http://www.inetdaemon.com/tutorials/internet/dns/operation/resolution/reverse/reverse.shtml

 

3. DNS Components

DNS consists of 3 major components which are the database, the server and also the client. http://www.ietf.org/rfc/rfc1034.txt [RFC 1034] The database contained in DNS is known as a distributed database and is made up of the Domain Name Space or in other words it is the DNS tree and also the domain names stored there which are called the Resource Records (RRs). The RRs describe the makeup of a zone or domain.(http://www.zytrax.com/books/dns/ch8/) The server in DNS is known as the name server and their job is to manage a part of the Domain Name Space and to help the client to find the relevant information it requires from within the DNS tree. The domain that a name server is in is their responsibility and they are the authority in the domain. They also identify other name servers that are located in subdomains.

The name server contains the RRs data to make up the domain, this is referred to as the zone information. And each name server has its zone of authority. The zones can be either an inverse zone or a forward zone. An inverse zone is used to map the IP address to the DNS host name were a forward zone contains the information relevant to a particular domain. You can have more than one name server in a zone but the primary server can only be one name server. The primary server is the server in the zone that makes the changes to the data.

RR

Value

RFC

Description

A

1

RFC 1035

IPv4 Address record. An IPv4 address for a host.

AAAA

28

RFC 3596

IPv6 Address record. An IPv6 address for a host. Current IETF recommendation for IPv6 forward-mapped zones.

CNAME

5

RFC 1035

Canonical Name. An alias name for a host.

HINFO

13

RFC 1035

Host Information – optional text data about a host.

KEY

25

RFC 2535

Public key associated with a DNS name.

NS

2

RFC 1035

Name Server. Defines the authoritative name server(s) for the domain (defined by the SOA record) or the subdomain.

SOA

6

RFC 1035

Start of Authority. Defines the zone name, an e-mail contact and various time and refresh values applicable to the zone.

http://www.zytrax.com/books/dns/ch8/

Table 1 Sample of some RRs 

3.2.  DNS zone transfers and queries

DNS zone transfers happen when a secondary server does an update on the copy of the zone in which it is an authority. The information contained on a secondary server is identical to the data contained on a primary server.(http://www.ntchosting.com/dns/primary-and-secondary.html) and so in fact if you were to query either primary or secondary servers you would get the same information as far as DNS is concerned there is no preference assigned to a server. What the secondary server does in this update is that it checks the data on the primary server to see if it has a more updated version than it has and if so it then goes and retrieve a new copy of the data of the zone.

When a client machine needs to look up the name it will query the DNS servers. A query from DNS is met with a response. The client side of DNS is called resolver, a resolver makes queries that are sent over a network to a name server then it makes an interpretation of the response and it returns information to the requesting server. It works off a list of name servers. It will go the first name server that it finds is available and to no others. If it finds that there are no name servers available it will try each one in turn until a response to the query is given. The name server that gets the query can then act on the clients behalf in resolving the query, the name server that has the answer to the query will transmit its response back to the name server that sent the request originally who will then cache the response given and in return give the answer back to the client. The caching of the responses makes the whole process more efficient but this caching can lead to security concerns.

A DNS message has is made up of five parts, they are the Header section, and a Question section, and an Answer section, an Authority section and an Additional section. The Header section contains fields that tell what type of message it is and the important information about it. Also it contains the amount of entries that are contained in the other four sections. The Question section contains queries for information that is being sent to the name server. The Answer section as the name suggests contains the answers to the Question section. The Authority section contains RRs that point it to the authoritative name server so as to all the continuation of the process of resolving the query. The Additional section also contained RRs that have additional data on the query that really needed to answer what is contained in the questions section. (http://www.tcpipguide.com/free/t_DNSMessageProcessingandGeneralMessageFormat.htm)

HEADER

QUESTION

ANSWER

AUTHORITY

ADDITIONAL

Fig 4.  DNS message format

 

 

4.  Vulnerabilities to the Domain Name System

By its very nature of being a public distributed database where no controls are placed restricting anyone access to the information contained in the DNS name lends itself to a serious vulnerability. The protocol was specifically designed to allow access without any constraints. This was later looked at by BIND, which is the most common DNS used on machines that use Unix, which implemented some access controls for zone transfers.

 There are numerous vulnerabilities in DNS which came about due to the use of “r” commands which put a lot of demands on how accurate the data contained within DNS. If information contained in DNS is false this could lead to dangers in its security. Such vulnerabilities can be found under the following headings, Cache poisoning, information leakage, dynamic update vulnerability and client flooding.

4.  Cache Poisoning

Cache poisoning is when there is a compromise to the integrity of the data in the Domain Name System. How this occurs is that when a DNS server is queried and it doesn’t have the answer in its cache, then what it does is that it passes the original query onto another server. If when passed to another server and that server contains incorrect information then this is what is called cache poisoning. The incorrect data might have been placed there intentionally to achieve the aim of cache poisoning or maybe it was there unintentionally. If the incorrect information was added intentionally this is also called DNS spoofing. So what happens in the process is that if a domain name server resolves a domain name such as itb.ie into its IP address if a poisoning has occurred it will return an incorrect IP address and as such it will divert traffic to another address.

4.1.1.  Cache Poisoning Methods

In the early versions of the DNS they were vulnerable to cache poisoning. As what would happen is that when the DNS server got a query it would give a hint by filling in some records of the DNS response with data that was not really relating to the answer. When this data was then sent back to the DNS server that made the query it didn’t carry out any checks to ensure that the data that was sent back was correct. So then the DNS server would accept this information and adds it to the cache thus perpetuating the problem.

Also another problem that could occur was that there wasn’t any type of mechanism to ensure that the answer that was received was actually related to the question that was asked in the first place. It would just cache the answer which also perpetuated the corruption of the cache. Thankfully the BIND implementation of DNS have addressed these problems but that doesn’t necessarily mean that other implementations are still not plagued with this problem.

An example of how this process works is we have a name server which is known as mydnsserver.example.com which is looking after a small network of computers. These computers are clients of mydnsserver.example.com. If a host called tony1 makes a DNS query to mydnsserver.example.com then what happens is that mydnsserver.example.com will check out its cache to see if it has the answer to the query from tony1. If mydnsserver.example.com does not have the answer to the query then being authoritative it will then send the query on. So it sends it to corruptdns.example.org and it so happens that the information contained on corruptdns.example.org is wrong, usually because simply a misconfiguration on it. Now mydnsserver.example.com is caching the responses that it receives it will then cache this incorrect information and then sends it back to tony1. But as long as this cache poisoning is undetected then not only tony1 can receive this incorrect information but so are any other client that is connected to the network along with tony1.

 4.Rogue servers

The use of a rogue DNS server is a very serious threat to all users of the internet as the information contained on a rogue DNS server might not be safe. A rogue DNS server can be used enable a malicious user to attack a host machine or network by the use of DNS spoofing or host name spoofing. A rogue server is essentially a server that lies, as it is no longer under the control of the network administrator. When a server has gone rogue instead of translating the domain names of the real websites into their correct IP address it will return the IP address of a malicious website that could be used in a phishing attack.

Below is an example of how DNS cache poisoning happens when the information placed onto the DNS Cache server. A host which is on the domain of the DNS cache server makes a request to be able to access a URL http://example.jp/ which has an IP address of 192.168.1.23, so essentially the host is looking for the IP address from the DNS cache server. A malicious user wants the host to access a URL that they have access to, for example it could be a phishing site set up to gather information such as bank details and passwords. So what the malicious user does then is that they hack into the DNS cache server and change the data that pertains to example.jp by now saying that the IP address of this site is 172.16.3.2. So now the DNS cache server responds to the host and tells it that the IP address that they are looking for is 172.16.3.2 and redirects the host to that site thus the host is now on a malicious site thinking they are on the legitimate site they were looking for and their detail entered on to this site can now be recorded.

C:Userswebactivate51DesktopcachePoisoning.png

Fig. 3 Example of rogue server redirecting to fake site http://www.ipa.go.jp/security/english/vuln/200809_DNS_en.html

4.  Cache Poisoning Attacks

A malicious user can take advantage of the vulnerabilities found due to cache poisoning if the use it in tandem with a rouge server and intentionally place incorrect data onto it. This data will then be forwarded that as either a helpful hint or in fact the answer which will in turn get cached by a DNS server which hasn’t been corrupted. A method of doing this is for a malicious user to send a query to a DNS server looking for information on the DNS zone that their DNS server is an authoritative server, then when this information is cached the hacked DNS server will then re direct hosts to malicious sites.

Early versions of the BIND implementaion of DNS were susceptible to this type of attack as they allowed a malicious user to insert fake information into the DNS cache as it didn’t worry about whether the query was even sent before issuing a response. This acceptence of cache responses allowed the malicious user to change things to suit their nefarious aims. But with later versions of BIND namely BIND version 4.9.6 this vulnerability was patched.(http://www.cert.org/advisories/CA-1997-22.html)

So why would a malicious user want to do this type of attack. Well once they are in control and have instigated cache poisoning onto the DNS server they then have options as two the type of attack that they wish to implement. The first could be that they would instigate a Denial of Service attack on a chosen target or else they can set up a phishing site in which they can then gather secure information such as login details or bank records.

4.1.4.1. Denial of Service

There are a few ways in which a Denial of Service attack can happen once a malicious user has control. What happens in an uncorrupted system is that if a query is made which can’t be resolved then it responds with a negative response. So if a corrupted system was to send back negative responses to queries that it could have resolved this will ensure a Denial of Service or if the malicious user works in tandem with their rouge server and instruct it to send the responses that will redirect a host to another system that the malicious user know doesn’t have the service that is required.

Another way a Denial of Service attack can be carried out is if for example the DNS contains a self-referential resource record in its cache

foo.example. IN A CNAME foo.example

It doesn’t matter what domain name is actually used just that the target of the CNAME is the same. The record could be cached because the server is recursive or because it was authoritative. So what a malicious user does is that they insert the record into the cache resulting in a Denial of Service. (http://www.cert.org/advisories/CA-98.05.bind_problems.html)

 

4. DNS  Flooding

DNS flooding works when a query is sent to the DNS server but in return instead of getting the answer the client is then flooded with thousands of responses to their query. The server is not able to handle the amount of replies it receives and as a result is unable to provide a service. Because there is no authentication on the response that are returned lends itself to the success of this type of attack. 

4.3.  DNS Dynamic Update Vulnerabilities

The specification outlined in RFC 1035 requires that DNS zones are to change slowly and usually through a manual process. This was modified in a later RFC 2136 that allowed for dynamic updates once certain conditions are met. This change came about to help other protocols such as DHCP, Dynamic Host Configuration Protocol to add or even to delete RRs. As these updates take place on the primary server this means that access to the primary server is open, if a malicious user was to employ IP spoofing, which is where they would forge the IP packets with a fake source address, it would allow them to breach the system and to compromise it. Then the malicious user could delete records that are cached and to redirect to nefarious sites. 

4.4.  Information Leakage

From time to time network administrators would start a zone transfer in which they would transfer DNS data across their DNS servers so that they can replicate the database as DNS is a distributed database. During this process some information could leak with vital information for a malicious user about the network. This information could contain hostnames on the network and also the IP addresses that are not assigned in the network thus allowing the attacker to use IP spoofing. 

4.5.  Compromise of DNS server’s authoritative data

Another type of threat is when a malicious user escalates their privileges to gain administrative control with the desire to modify zone information. To achieve the escalation of privileges it need not be done because of any vulnerability in DNS but more likely the malicious user will find some way usually threw a bug or design flaw that hasn’t been corrected or patched. To prevent this from happening the network administrator should ensure that they have migrated to BIND 9 or the latest version available. They should limit the amount of services that are on offer on the same machines and ensuring that proper restrictions are placed on users so that only administrators have access. Another essential ingredient in the administrators arsenal is the use of Domain Name System Security Extensions, DNSSEC, which is a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information.

 

5.  Domain Name System Security Extensions  [RFC 2535]

As I stated earlier when DNS was originally designed it didn’t include security but was designed to be a scalable distributed system. To resolve this in 1994 the Internet Engineering Task Force, IETF, set about providing some security extensions while also allowing it to maintain backwards compatibility. What they came up with a suite of specifications called Domain Name System Security Extensions or more commonly DNSSEC. The design of DNSSEC was that ability to protect resolvers from data on the DNS that is forged, as happens when the DNS is corrupted by cache poisoning. What DNSSEC does is that unlike previously the answers returned are now digitally signed. This allows the the DNS clients (resolvers) to the ability to check that the information in the answer to verify that the answer is correct and identical and also that it is a complete answer to the information that is cached on the DNS server that is authoritative. How this works is that DNSSEC use public-key cryptography. DNSSEC though doesn’t encrypt the answers so it doesn’t provide confidentiality. To ensure that Domain Name System Security Extensions would be accepted by the wider community working group that created DNSSEC knew that they would have to provide backward compatibility or it never would have gained acceptance and use. They also knew that DNSSEC must work with non-secure implantations of DNS. They achieved these goals thus allowing sites the ability to be able to migrate to DNSSEC without the need for a complex upgrade. For DNSSEC to work it had to add 4 new resource records these are Resource Record Signature (RRSIG), DNS public key (DNSKEY), Delegation Signer (DS) and Next Secure (NS). It also added to new message header bits Checking Disabled (CD) and Authenticated Data (AD) http://tools.ietf.org/html/rfc4033#page-7

 

5.1.  Domain Name System Security Extensions Purposes

As we know for DNS to function properly it needs to have the responses that are returned correct and at all times consistent. But as it is a public service the data contained is also public. This requires the need that the data returned is authenticated and that its integrity is intact. But with it being public it also cannot have controls on who can access it and that it is not encrypted. So obviously the main aim then of the ITEF working group that created DNSSEC was to provide authentication and integrity. This is done with the use of public key cryptography. That way now the server and clients and even the applications can use this to make sure that any information that they receive hasn’t been altered in any way and is authentic. Even though confidentiality wasn’t provided with DNSSEC it doesn’t preclude the chance to be able to provide it. So if an application wishes to use public keys so that the data becomes confidential when used in conjunction with the public keys that are contained within DNS. 

As with the addition of any extensions to an existing protocol they will always have an effect on the performance. To elevate the overhead that is inherent with the use of DNSSEC it adds that a need for an additional query to look for the signature of an RRs that it has just got by letting data that came from a secure zone to be contain the signature and key. 

5.3.  Domain Name System Security Extensions Services

The services that are provided by Domain Name System Security Extensions can be broke into these three services

Key distribution

Data authentication

Transaction and request authentication.

5.3.1. Key Distribution

For every zone that is signed then a pair of keys are created, public and a private. Both keys have different roles the private key is the one that is used to sign the zone and the public key is the one that is distributed to the resolver. The distribution of the public key will only take place when it is established a “trust anchor” by traversing the tree from parent to child. The root would be the ideal trust anchor. http://www.ripe.net/ripe/docs/dnssec-key-maintenance-procedure