Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

10/24/2018
10:30 AM
Paul Vixie
Paul Vixie
Commentary
Connect Directly
Facebook
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
50%
50%

Benefits of DNS Service Locality

Operating one's own local DNS resolution servers is one of the simplest and lowest-cost things an IT administrator can do to monitor and protect applications, services, and users from potential risks.

A non-networked computer is very rare now because most useful work involves data and services that are distributed across some kind of "internet" — that is, any network that speaks IP, public or private. Notably, most non-internet networks have failed — we won't be building or connecting to AppleTalk or DECnet or SNA or XNS networks ever again. Consider, then, that most useful work relies on TCP/IP, which itself relies on the Domain Name System (DNS). We should know as much as possible about our use of the DNS, but most IT administrators are much too busy learning their specialized craft to also become experts on every enabling technology.

In this article, I will describe the use of DNS by users and applications, which means DNS resolution. There's much more than this to say about DNS — for example, DNS content management and provision. But while providing DNS content is a specialized task, accessing that DNS content through resolution is a universal activity — no work of any kind can begin in TCP/IP networks until DNS has been accessed at least once and possibly many times. Importantly, for this discussion, among the kinds of "work" I refer to are online crime, network abuse, and surveillance.

Early DNS
In the 1980s, when TCP/IP's design was mostly finalized by the research and education communities, it was common to have only one or a few computers on a campus because computers were very large and expensive to acquire, operate, and maintain. This concentration caused many services and applications to share a single computer, which users would access using "dumb" terminals. Thus, when the DNS was created, the resolution service was installed on at least one computer on every campus. We learned to expect rapid answers to most DNS questions, usually receiving an answer within a millisecond or so. Networked applications such as e-mail or file service were operated under the assumptions that at least one DNS access would be necessary for every "transaction" but that DNS access would be fast enough that this would not reduce the performance of applications and services that depended on it.

Before the commercialization and privatization of the Internet in the 1990s, there was no online crime or abuse. When only scientists and engineers could access the Internet, and the goals were academic rather than commercial, we had safety by accident. Much of today's Internet crime and abuse is made possible by the total absence of security consideration in some of the Internet's oldest core protocols and services — and it has proved very difficult to address security considerations decades later to a network that was designed to accommodate only trusted users and trusted applications. One of the most serious security problems is that malicious actors can create DNS content to facilitate their online crimes, and they will receive the same excellent service for this malicious content as we get for non-malicious content.

Today's DNS
Continuous consolidation among Internet companies has created some dominant players, such as Google, Cisco, IBM, and Cloudflare, each of which offers a global DNS resolution service identical to the resolution service every network had to run for itself back in the early days. This is in some ways a natural progression because these external DNS resolution services (such as 8.8.8.8, 9.9.9.9, or 1.1.1.1) are free, convenient, and, perhaps unknown to most users, also a vital source of network intelligence for the companies that operate these resolution services. Many IT administrators working today were not working in the field when DNS resolution service was always provided on-campus, under local policy, by local staff. As a result of this trend and that generation gap, there are added costs and subtracted benefits, or losses, from the use of external DNS resolution servers, either the global kind (8.8.8.8, et al.) or the regional kind (as provided by one's own ISP).

Accounting of Losses
The first loss we experienced from externalizing the once-local DNS resolution service was privacy. Our external DNS transactions are rarely protected from surveillance, and while such protection is now being developed, that protection will come in the form of added complexity. The best way to avoid having one's DNS transactions observed, tracked, or analyzed by third parties is to not externalize those transactions in the first place. Most of us need not fear surveillance of traffic inside our own networks, which makes those "owned networks" a great place to keep data we don't want published.

The second loss from externalizing DNS resolution is performance. No matter how many DNS resolution servers are externally constructed, none will be reachable by our users and our applications in less than 1 millisecond. Thus, the number of transactions we can process per unit of time will be reduced by the need to wait for speed-of-light transmission delays across a distance greater than our campus. Most web browsers now contain an internal DNS "cache" to offset this penalty. Most other networked applications lack this cache. Again, I question the need for application-level caching when a simple local DNS resolution server would offer the same benefits to all networked applications across an organization.

(Column continues on next page.)

Dr. Paul Vixie is an Internet pioneer and thought leader who designed, implemented, and deployed several Domain Name System (DNS) protocol extensions and applications that are used throughout the Internet today. He is CEO of Farsight Security Inc. Previously, he served as ... View Full Bio
Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
Active Directory Needs an Update: Here's Why
Raz Rafaeli, CEO and Co-Founder at Secret Double Octopus,  1/16/2020
New Attack Campaigns Suggest Emotet Threat Is Far From Over
Jai Vijayan, Contributing Writer,  1/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-20399
PUBLISHED: 2020-01-23
A timing vulnerability in the Scalar::check_overflow function in Parity libsecp256k1-rs before 0.3.1 potentially allows an attacker to leak information via a side-channel attack.
CVE-2020-7915
PUBLISHED: 2020-01-22
An issue was discovered on Eaton 5P 850 devices. The Ubicacion SAI field allows XSS attacks by an administrator.
CVE-2019-20391
PUBLISHED: 2020-01-22
An invalid memory access flaw is present in libyang before v1.0-r3 in the function resolve_feature_value() when an if-feature statement is used inside a bit. Applications that use libyang to parse untrusted input yang files may crash.
CVE-2019-20392
PUBLISHED: 2020-01-22
An invalid memory access flaw is present in libyang before v1.0-r1 in the function resolve_feature_value() when an if-feature statement is used inside a list key node, and the feature used is not defined. Applications that use libyang to parse untrusted input yang files may crash.
CVE-2019-20393
PUBLISHED: 2020-01-22
A double-free is present in libyang before v1.0-r1 in the function yyparse() when an empty description is used. Applications that use libyang to parse untrusted input yang files may be vulnerable to this flaw, which would cause a crash or potentially code execution.