By Jeff Kabachinski, MS-T, BS-ETE, MCNE

This column is the first of a two-part series about Internet domains and how cyber criminals are using techniques like domain tasting and domain generating algorithms (DGA) to surreptitiously control an army of robot computers, commonly referred to as bots. The bot armies can range in size from a few hundred to over a million. The bots sleep until awakened to carry out a mission such as a denial of service (DoS) attack. This type of attack uses thousands and thousands of requests for information to overload a web server to the point where it shuts down because it can’t keep up with the barrage.

To set the scene, this column, part 1, looks at all the basic aspects of domains, the domain name system (DNS) and DNS servers. It will cover basic function and the rules as laid down by the Internet Assigned Numbers Authority (IANA), the Internet Engineering Task Force (IETF), and the Internet Corporation for Names and Numbers (ICANN). Part 2 will look at how cyber criminals make use of domain functionality for their illicit purposes and offer some strategies for how to protect your network.

A Brief Look Back

The idea of domains goes all the way back to the beginnings of the Internet. All Internet locations are known by their Internet protocol (IP) or hostname addresses. Originally, when the Internet was rather, small everyone on the Internet had a copy of the hostnames list. Because it was much easier for humans to remember names or a naming structure than to remember each host’s Internet address, they needed a way to keep track of the host’s name as resolved to their Internet Protocol (IP)) address. The so-called “gold copy” or official version of the list was originally stored on a computer at Stanford Research Institute (now SRI International), an independent research institute.

The list of host names matched with their addresses quickly became too unwieldy to handle in a centralized manner. Consequently, a new DNS method was generated and announced in 1983.1

The resulting DNS server system connects browsers to web servers by translating the uniform resource locator (URL), such as google.com to an IP address, such as 74.125.239.35, so routers and servers can direct browser requests to the right place. If your browser doesn’t already have that information in its cache, it will reach out to its default DNS server on the Internet to get it.

Domain Name Structure

Domain names are arranged in a hierarchical or tree type of format. A domain can be anything from a group of Internet resources to a single computer residing on the Internet. The domain names are read from right to left with the top-level domain (TLD) read first. The original TLDs included .com for commercial purposes, .net for network providers, .mil for the military, .edu for educational institutions, .gov for government, and .org for non-profit organizations. More TLDs were added later (see Table 1 for a more complete list).

Domain Name

Description

aero

The air transport industry

biz

Business Use

cat

The Catalan culture

com

Commercial organizations

coop

Cooperatives

edu

Educational organizations

gov

US Government

info

Informational sites

int

International organizations

jobs

Employment related

mil

US Military

mobi

Mobile devices

museum

Museums

name

Family and individual sites

net

Network infrastructures

org

Non-profits

pro

Professional sites

travel

Travel industry

To the left of the TLD is the secondary domain or subdomain like nfl in nfl.com. The tree can have up to 127 sublevels, also called labels. Each label can be up to 63 characters in length. However, the entire fully qualified domain name (FQDN) cannot be more than 253 characters. Take for example the fictitious gbpackers.nfc.nfl.com. Here, nfl is a subdomain to .com, which a subdomain of the root, signified by the dot (.) (see Figure 1). Subsequently nfc is a subdomain of nfl.com. Finally the last label, gbpackers, is a subdomain of nfc.nfl.com. A FQDN is the entire identification string that leads you solely to the host in question.2,3

Figure1-2013-11Figure 1: A Fully Qualified Domain Name (FQDN) Example

DNS Function

The DNS is managed by a distributed database system. Each of the TLDs have name servers and routers that will forward the message to find where on the Internet this host exists also by reading the FQDN backward—or right to left. From the root, the message example gets forwarded to the .com DNS servers. The message is then forwarded upstream to the next level or recursive server. Authoritative servers only reply to requests about domain names that have been specifically configured by an administrator. They let other “recursive” name servers know the DNS information the hostname has.

The TLD name servers can be master or slave servers (see below for authoritative and recursive servers). These must be set up for every DNS zone. The master servers are generally TLD servers, and the slaves are further upstream, or getting more detail of the zone particular to where FQDN resides. Specifically there’s an authoritative answer (AA) flag that’s set in the IP header to indicate that the returned result is from an authority.4

Authoritative vs Recursive Servers

Authoritative name servers have been programmed by an authoritative source such as an ICANN-assigned administrator with the associated rights to make entries into the hostnames list. As mentioned above, there needs to be an authoritative name server for each zone in the FQDN. Authoritative servers can be either master or slave servers. The master keeps the ‘gold copy’ of hostnames and IP addresses for a specific zone. The slave authoritative servers get their copy from the master via a routine that automatically updates the listings. Recursive servers then handle the grunt work of answering browsers when asked how to connect to a specific FQDN. Reading from their cache decreases extra traffic to the authoritative servers.

Putting It All Together

When you ask your browser to surf to a specific FQDN like gbpackers.nfc.nfl.com, your browser will first look into its local cache to see if it has been there recently and already knows the IP address. If not, it will ask its default recursive name server for the IP address. The recursive server will check its cache for the address before going back to the root and .com authoritative servers. The recursive server may have to go all the way up the line to get to it by checking each zone’s authoritative server. There is also a time-to-live (TTL) marker in the message that will be decremented each time it hits a name server. In this way a bogus web server with a bogus domain will not be forever chasing around the Internet trying to find the IP address of the bogus mythical web server. Also caches will expire and need to refresh. Refresh periods can last a few seconds to a few hours, days or even weeks. There is also an opportunity for one of the name servers to override the TTL to allow caching for up to 68 years—although that too can be overridden.5

It’s Fully Documented

The details of the DNS system encompass several request for comment documents (RFCs) and can get confusing the deeper you delve into the controlling RFCs managed by the Internet Engineering Task Force (IETF) and their Internet standards. There are over 50 separate documents that spell out every grim detail of the DNS. See the sidebar to get an idea of the depth of the DNS.

In part 2, we’ll see how cyber criminals can take advantage of how these standards spell out the use of the DNS.

Jeff Kabachinski, MS-T, BS-ETE, MCNE, has more than 20 years of experience as an organizational development and training professional. He is the director of technical development for Aramark Healthcare Technologies in Charlotte, NC. For more information, contact jbethune@allied360.com.

 

References

1. IETF. (2003, February). Role of the Domain Name System (DNS). Retrieved Oct 3, 2013, from IETF – Internet Engineering Task Force: http://tools.ietf.org/html/rfc3467

2. IETF – Internet Engineering Task Force. (1983, November). RFC882: DOMAIN NAMES – CONCEPTS and FACILITIES. Retrieved October 5, 2013, from IETF: http://tools.ietf.org/html/rfc882

3. IETF – Internet Engineering Task Force. (1983, November). RFC883: DOMAIN NAMES – IMPLEMENTATION and SPECIFICATION. Retrieved October 5, 2013, from IETF: http://tools.ietf.org/html/rfc883

4. Wikipedia. (2013, October 5). Domain Name System. Retrieved October 6, 2013, from Wikipedia: http://en.wikipedia.org/wiki/Domain_Name_System

5. IETF – Internet Engineering Task Force. (1996, February). RFC1912: Common DNS Operational and Configuration Errors. Retrieved October 6, 2013, from IETF: http://www.ietf.org/rfc/rfc1912.txt

SIDEBAR: DNS-Related Requests for Comment Documents from the IETF

RFC 920, Domain Requirements – Specified original top-level domains

RFC 1032, Domain Administrators Guide

RFC 1033, Domain Administrators Operations Guide

RFC 1034, Domain Names – Concepts and Facilities

RFC 1035, Domain Names – Implementation and Specification

RFC 1101, DNS Encodings of Network Names and Other Types

RFC 1123, Requirements for Internet Hosts—Application and Support

RFC 1178, Choosing a Name for Your Computer (FYI 5)

RFC 1183, New DNS RR Definitions

RFC 1591, Domain Name System Structure and Delegation (Informational)

RFC 1912, Common DNS Operational and Configuration Errors

RFC 1995, Incremental Zone Transfer in DNS

RFC 1996, A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)

RFC 2100, The Naming of Hosts (Informational)

RFC 2136, Dynamic Updates in the domain name system (DNS UPDATE)

RFC 2181, Clarifications to the DNS Specification

RFC 2182, Selection and Operation of Secondary DNS Servers

RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)

RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)

RFC 2671, Extension Mechanisms for DNS (EDNS0)

RFC 2672, Non-Terminal DNS Name Redirection

RFC 2845, Secret Key Transaction Authentication for DNS (TSIG)

RFC 3225, Indicating Resolver Support of DNSSEC

RFC 3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements

RFC 3597, Handling of Unknown DNS Resource Record (RR) Types

RFC 3696, Application Techniques for Checking and Transformation of Names (Informational)

RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification

RFC 4592, The Role of Wildcards in the Domain Name System

RFC 4635, HMAC SHA TSIG Algorithm Identifiers

RFC 4892, Requirements for a Mechanism Identifying a Name Server Instance (Informational)

RFC 5001, DNS Name Server Identifier (NSID) Option

RFC 5452, Measures for Making DNS More Resilient against Forged Answers

RFC 5625, DNS Proxy Implementation Guidelines (BCP 152)

RFC 5890, Internationalized Domain Names for Applications (IDNA):Definitions and Document Framework

RFC 5891, Internationalized Domain Names in Applications (IDNA): Protocol

RFC 5892, The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)

RFC 5893, Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)

RFC 5894, Internationalized Domain Names for Applications (IDNA):Background, Explanation, and Rationale (Informational)

RFC 5895, Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 (Informational)

RFC 5966, DNS Transport over TCP – Implementation Requirements

RFC 6195, Domain Name System (DNS) IANA Considerations (BCP 42)

RFC 4033, DNS Security Introduction and Requirements

RFC 4034, Resource Records for the DNS Security Extensions

RFC 4035, Protocol Modifications for the DNS Security Extensions

RFC 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records

RFC 4470, Minimally Covering NSEC Records and DNSSEC On-line Signing

RFC 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors

RFC 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence

RFC 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC

RFC 5910, Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)

RFC 5933, Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC