In 2008, Karen Evans, administrator of the Office of Government and Information Technology at the White House’s Office of Management and Budget (OMB), wrote a memo to all government chief information officers that read, in part: “The Government’s reliance on the Internet to disseminate and provide access to information has increased significantly over the years, as have the risks associated with potential unauthorized use, compromise, and loss of the .gov domain space.”
Consequently, the OMB soon issued a mandate to all federal information systems, including those at Sandia and others with a .gov domain name, to deploy a new security feature, Domain Name System Security (DNSSEC). That new policy required that “the top level .gov domain will be DNSSEC-signed, and processes to enable secure delegated sub-domains will be developed.”
The mandate made perfect sense, says Sandia computer scientist Casey Deccio (8966), but there soon emerged a problem when .gov organizations actually began deploying DNSSEC.
“It (DNSSEC) is hard to configure correctly and has to undergo regular maintenance,” says Casey. “It adds a great deal of complexity to IT systems, and if configured improperly or deployed onto servers that aren’t fully compatible with it, it keeps users from accessing .gov sites. They just get error responses.”
When Sandia started to experience such problems due to other sites’ DNSSEC misconfigurations, Casey decided to take matters into his own hands. Using internal funding, he began to develop a visualization tool, now known as DNSViz, to help network administrators in the federal government and global community better understand DNSSEC and to help them troubleshoot problems.
The still-new DNSSEC security feature, in an ideal world, will allow user applications like web browsers to ensure that the IP addresses they have received from the DNS have not been “spoofed” by anyone with ill intent. As such, Internet-connected systems within the government can verify that the responses are authoritative and have not been altered. Still, the hiccups with implementing DNSSEC have been enough for Casey to develop DNSViz.
The trouble with DNS
When you type in a Uniform Resource Locator (URL) into a web browser on your workstation, magic seems to happen.
Essentially, you might notice a few commands that appear at the bottom of your screen, then just sit back momentarily while the Internet gremlins do their thing and miraculously find and display the web page you’re seeking.
But in reality, for every URL your browser accesses — including web pages, embedded images, and other content — your computer has to first translate the hostname of the URL into an Internet Protocol (IP) address. The entity doing much of that work is known as a Domain Name System (DNS) server. A DNS “lookup” — whereby the server is asked for the IP address that corresponds to the hostname of the URL you’ve typed — is a prerequisite for doing almost anything on the Internet, including web browsing, emailing, or videoconferencing.
The DNS functions in many ways like a telephone book, translating hostnames (like www.sandia.gov) into numerical addresses that your computer can subsequently identify and “dial up” to access the remote servers.
There is a natural hierarchy within the DNS, each domain name identifying its own ancestry. For example, sandia.gov is a “child” of .gov, which is a child of the DNS root. Each parent refers clients to other servers that can give answers for their “children.” This ancestral line is the backbone for building a chain of trust that must exist for authenticating a DNS lookup with DNSSEC. Each link in the chain vouches for the link below it.
In this way the DNS might be described as a sort of referral-based system analogous to meeting someone through a mutual friend. A user trusts a DNS answer because he or she trusts the source it came from, trust gained first through another referral source. This process continues for each “link” in the chain up to the DNS root.
DNSViz — helping the IT professional ‘see’ the problems
Without DNSSEC, the “trust” of referrals and answers is superficial, and tampering by third-party attackers could go undetected, thus redirecting online communications to unwanted destinations. This represents a particularly troublesome vulnerability for .gov addresses owned by government organizations guarding national security information and other vital data. But DNSSEC is of little use if network administrators don’t know how to configure or use it.
Casey describes DNSViz as a “tool for visualizing the status of a DNS zone.” It provides a visual analysis of the DNSSEC authentication chain for a domain name and its resolution path in the DNS namespace, made available via a web browser to any Internet user (http://dnsviz.net/). It visually highlights and describes configuration errors detected by the tool to assist administrators in identifying and fixing DNSSEC-related configuration problems.
The primary contribution provided by DNSViz is the ability to bring together all the components that work together for DNSSEC to function properly into a single graphical representation. The resulting visualization is a collection of configuration data and relationships that are otherwise difficult to assemble, assess, and understand.
Tool functions in two primary ways
To help network administrators in their DNSSEC deployment, Casey’s DNSViz tool functions in two primary ways: it actively analyzes a domain name by performing pertinent DNS lookups, and it makes the analysis available via the web interface. The active analysis occurs periodically to build a history of DNSSEC deployment over time and provide a historical reference for DNS administrators.
The means for making the data available to users is currently the web interface, though Casey intends to expand DNSViz functionality to allow access via other means. For example, alert mechanisms might be used to inform affected parties, and application programming interfaces (API) can be designed to allow administrators to programmatically access the information instead of manually browsing to the DNSViz web site.
Currently, Casey has the tool running in the background on Sandia/California’s servers, monitoring a list of some 100,000 DNS names. It performs an analysis a couple of times each day and offers a situational awareness of what the DNS configuration for each name looks like from top to bottom. He has demonstrated the challenges of DNSSEC deployment, as measured by his tool, in international DNS forums and workshops. He hopes to use these results to identify practices contributing to DNSSEC mishaps and suggest changes to improve DNSSEC deployment in practice.
Though the functionality provided by DNSViz could potentially be included in a marketable software product that’s sold by a for-profit company, Casey says he envisions it as an open-source tool available to anyone who needs it. With further funding, he hopes to expand the tool so that it can analyze DNS health and security on a continuous basis, essentially creating a full-blown monitoring system that is scalable, versatile, and more informational.