Information assurance:
Protecting the Army's domain-name system

by Larry Barker

What�s in a name? For the domain-name system, a name is the virtual ability to translate hard-to-remember numbers like into an address like � something we can easily remember. DNS is the worldwide "phonebook" in the form of a huge distributed database that makes this happen throughout the Internet and the Defense Department�s nonsecure Internet protocol routed network.

DNS and the many private, public and military name servers used to deliver this global IP address book are vulnerable. DNS servers can be hacked directly. Service can also be denied because of an attack instigated by a remote agent. Also, DNS servers can be inadvertently misconfigured. When this happens, the IP addressing that hooks computers together fails. Electronic-mail servers, file servers and host computers that need the DNS phonebook to make their connections are isolated and ineffective, leaving missions that depend on their information delayed and impaired.

The Army�s vast sustaining-base networks and servers need a reliable, protected DNS. This article is about how Army Signal Command implemented the protected DNS program across the Army.

Domain-name service information assurance diagram Domain-name service information assurance involves protecting legacy networks and organization-level / installation-level DNS against hackers.

The ASC mission began in February 1998 as one of the corrective actions associated with "Solar Sunrise." Solar Sunrise was an attack against military networks that led to an extraordinary effort known as the "150-day mission," which the Army�s vice chief of staff directed. The 150 days was the rigidly monitored timeframe the vice chief imposed to complete the first round of essential network protections.

For the DNS defense, the 150-day effort resulted in defining a clear plan to address the worldwide scope and the hundreds of servers in the "" domain space. Because of the scope and complexity of the Army�s DNS, it would take more than two years to realize the objectives that emerged from this plan.

These are the objectives now implemented:

A protected architecture that recognized the requirements of the publicly accessible DNS;
A consistent systems environment that could be deployed and relied upon for protection; and
The ability to configuration-manage and sustain the resulting system.


Architecture was developed that permits the exchange of public DNS information and offers protection for the sources of that information. Two problems emerged that seemed small but grew in complexity as the architecture was perfected.

The first problem was the "liberal" protocols of the public-domain DNS. Because DNS is a massive distributed database, its size is the sum of the many small parts of domain information or zones. Each must permit the exchange of information across the system.

From a DNS perspective, these zones � as numerous as phonebooks � are hosted on legitimate name servers who together deliver the IP address and host name that starts information transport.

These DNS servers must necessarily interact with Army DNS servers. They could be those of a legitimate private company (with whom the Internet-based exchange of information is essential to meet Army objectives) � or they can be on servers controlled by a hostile foreign power or an enterprising domain user engaged in industrial espionage. The system is open to all to facilitate Internet connectivity and communication.

The goal was to lock down and protect these Army phonebooks. Tiers or layers of DNS accessibility were created that restricted the knowledge of where our DNS assets are and the ability to reach them. These regional servers were placed within a framework of protections associated with information-assurance computer-network defense as implemented under the Directorate of Information Systems for Command, Control, Communications and Computers� network-security-improvement program.

The second problem was how to control the software that makes DNS happen. It�s called BIND, for Berkeley Internet Name Domain, and is supported as a collective effort of vendors, users and DNS technicians through a private organization known as the Internet Software Consortium. Because BIND is public-domain software and is so pervasively used, many hackers have an expert understanding of it and can exploit its vulnerabilities.

Standardizing our use of BIND required our own consortium of ASC, Mitre and private-sector engineers. The result was a private version of BIND, tailored to support Army objectives, but one that kept pace with changes in its public-domain cousin.

As deployed, this commercial-off-the-shelf application can be effectively used to help cauterize the results of attacks based on BIND vulnerabilities. We also use this interface to standardize the practices and procedures regarding how BIND is used throughout the Army. This prevents the misconfiguration of DNS servers created by uninformed administrators and avoids the BIND vulnerabilities found in many earlier, now unauthorized, versions of the software.

The result is a more reliable, standardized and virtual assurance of compliance with DoD and regional computer-response team guidelines and directives. The ability to standardize also depends on an effective common operating environment.

Common operating environment

To deploy the architecture, ASC developed a consistent set of standardized protected DNS servers and software. Each server was preconfigured, tested and deployed within the context of top-level network protection and IA defenses on Army installations.

There wasn�t enough funding to replace every server, yet no single server could be allowed to remain the weak link that broke the linkage needed for DNS addressing. Thus, the entire Army domain space had to be treated as a cohesive system.

Control of the name space didn�t stop with hardware and software. ASC needed to know, authenticate, train and coordinate with the domain managers for nearly 500 Army servers. The information they managed had to migrate to the common operating environment and become a functional part of the protected DNS. This became a far greater effort than placing more secure hardware and software.

Over the last 10 years, the chaotic scaling and growth that followed the popularity of the Internet also increased the rampant, ad hoc use of DNS. Diversity of servers, software versions of BIND and an array of nonstandard practices, procedures and configurations had to be recognized and accommodated. And this had to be done without breaking the working DNS and its support to the Army.

The result was the creation of a massive inventory that captured and evaluated all Army domain information. This included the servers as they existed in their legacy configuration and the domain information itself.

Domain information from more than 400,000 DNS records had to be extracted and preprocessed to identify obsolete legacy conditions and outright errors no longer permitted in BIND�s current versions. To do this, 500 domain managers across 180 Army locations � from huge installations like Fort Hood, Texas, to small stations like an office of the Corps of Engineers � had to be contacted.

This Armywide migration effort is complete outside the continental United States and continues in CONUS as remaining legacy domains are imported into the protected DNS and their users homed to the protected infrastructure.

Configuration management

Controlling the domain space in terms of hardware, software, data and the standard practices of domain managers is the result of a creative architecture that effectively uses the COE ASC engineered. Configuration management is the key to preserving these gains.

ASC and its theater network operations and security centers throughout the world form the virtual and collaborative agents that bring meaningful IA enterprise management to the protected DNS. ASC established a central configuration-management board that oversees the change control and TNOSC standard practices as they apply to IA in general, and to the refinement and continuing enhancement of protected DNS in particular.

The Army continues to make IA a priority because of the importance of networks and systems that permit and sustain the exchange of critical information. Protected DNS is an important part of this larger effort. In keeping with the development of more secure DNS practices across the Internet community, ASC will continue to enhance fielded DNS protections and vigilantly support those protections across its operating centers.

Mr. Barker is the project officer for U.S. Army Networks, Engineering and Telecommunications Activity, Army Signal Command, Fort Huachuca, Ariz. USANETA manages the protected DNS program�s implementation on ASC�s behalf.

Acronym QuickScan
ASC � Army Signal Command
BIND � Berkeley Internet Name Domain
COE � common operating environment
CONUS � continental United States
DNS � domain-name system
DoD � Department of Defense
IA � information assurance
IP � Internet protocol
TNOSC � theater network operations and security center
USANETA � U.S. Army Networks, Engineering and Telecommunications Activity

dividing rule

Back issues on-line | "Most requested" articles | Article search | Subscriptions | Writer's guide

Army Communicator is part of Regimental Division, a division of Office Chief of Signal.

This is an offical U.S. Army Site |


This is an offical U.S. Army Site |