Tag: DNS

  • Internet Pioneer Discusses Creation, Expectations and Security of DNS on its 33rd Birthday

    “The Internet community has let legacy infrastructure designs constrain the future.”

    Carlsbad, CA – June 23, 2016 – 33 years ago today, Paul Mockapetris, inventor of the Internet Domain Name System  watched the DNS take its first steps.  This critical development would open up what may be the world’s most utilized and important technological development for a mass audience. Did he understand the importance or impact that DNS would have when it was created?

    “I think I saw the potential importance more clearly than the traditional ARPAnet era folks, who were busy replacing the old NCP protocols with IP and TCP,” noted Mockapetris, now Chief Scientist at ThreatSTOP.  “So I was very happy to take on the design job and build something quite beyond the task given me.”

    By 1983, he had already spent 15 years designing distributed systems at what would become the Media Lab at MIT, Draper Labs, IBM, and the Distributed Computer System at UC Irvine. So he did expect his creation to be used across the Internet to manage a distributed operating systems and applications. DNS was really meant to manage a heterogeneous distributed, federated cloud and its services.

    Something Mockapetris did not expect was the whole marketing and branding of names. “I guess I should have taken some classes in business and marketing,” he joked.  His biggest surprise was that the research agencies in the late 80s and 90s didn’t see naming systems and DNS in particular as merely the first steps in an Internet naming architecture. The original design had many places where next steps and additional mechanisms were indicated, and never were taken.  Recent work in named data networking has revived this field a bit.

    “If I’d been told in 1988 what the DNS would eventually be used for, I would have said it wasn’t possible,” said Dr. Paul Vixie, Internet pioneer and CEO of Farsight Security, Inc. “Almost all Internet activities, whether for good or evil, begin with a DNS lookup.  Defenders who can monitor, and control, and investigate their use of DNS can by extension monitor, and control, and investigate their relationship to the Internet itself.”

    The DNS was introduced during the transition from the ARPAnet to the IP/TCP based Internet, and was the largest single architectural innovation of that transition. As a critical infrastructure, DNS has been subjected to many attacks and misuse, but in today’s hardened form, it is seen as an essential tool for implementing security.

    Security was intentionally left out of the initial design, along with several other functions.  DNSSEC is a next step, but is very heavy weight and doesn’t solve current problems like DDoS. 

    “The Internet community has let legacy infrastructure designs constrain the future,” notes Mockapetris. “For example, the 512 byte datagram limit of 1983 should be more like 500 Megabytes if we adjust for the million-fold increase in transmission speed in today’s Internet, though I’d settle for 512K bytes.  We are giving up on datagrams because of DDoS – while I understand the argument, I’m not ready to surrender yet.  There’s a lot of room for innovation here.  It’s as if we are requiring DNS to support paper tape and floppy disks.”

    Mockapetris now provides guidance to the ongoing product innovation process for ThreatSTOP, and leads research into DNS-based security. “Effective security requires real-time threat intelligence that is distributed to all of an enterprise’s enforcement devices whether they are routers, firewalls, application delivery controllers, or servers. DNS is an ideal vehicle,” said Mockapetris. “Fielding powerful, scalable security tools that leverage the ubiquity of DNS to protect organizations of all sizes is critical.”

    About ThreatSTOP

    ThreatSTOP is a network security company offering a cloud-based threat protection service that protects every device and workload on a network from cyberattacks and data theft. It can protect any network, from virtual cloud networks to branch LANs to the largest carrier networks. The service leverages market-leading threat intelligence to deflect inbound and outbound threats, including botnet, phishing and ransomware attacks, and prevents data exfiltration. For more information visit www.threatstop.com.  

    CONTACTS:   Michael Becce, MRB Public Relations, Inc.
    mbecce@mrb-pr.com | (732) 758-1100 x104

  • DevOps and the Challenge with Services

    DevOps and the Challenge with Services

    At RackN, we’ve been working for years to make DevOps portable across platforms. For us, that means the ability to move between clouds and from cloud to metal. Of the several challenges to portability—composability, API heterogeneity, sequence, cross-system dependencies—making configuration management tools work with services has been particularly important, as significant parts of building systems rely on services that are not directly configurable.

    Let’s look at DNS as an example. Whenever we configure services on a node, there are DNS implications. If we bring up a web server, we want to use a logical name for the node. If it’s a secure web server, that name should match our certificate. If we want to make that service discoverable, we likely want to add a logical name for that node, such as “clustermanager6.example.com” or similar. If you include names for BMC and rack location—not to mention IPv6 naming—it’s easy to image nodes with 10 names. Even cloud nodes have similar issues. That’s a lot of entries to manage!

    The problem with all those DNS names, and similar services, is that they are NOT configurable from the node. They are services with APIs that require restricted authorization.

    Services and Automation

    DNS is just one simple example.  System-level DevOps has many places where the configuration workflow needs to include external service actions. In cloud environments, generally that means either writing pre- or post-configuration steps that talk to the specific cloud API or using one of the cloud-specific template files. In physical environments, generally that means a lot of added manual steps or tightly constraining automation to inventory map files. No matter what, nodes don’t own DNS configuration—it’s a node external service with the API elements that are site specific.

    All of these approaches make DevOps brittle and site-locked. Five years ago that was okay, when choices were more limited and scripts were hand-crafted by DevOps artisans. Today, we need our automation to be robust, portable and transparent.

    We realized system automation needed to treat services interactions as equal to configuration. That means when we’re working on provisioning, we make sure service steps can be woven into the sequence of configuration steps. They must not be assumed correct or delegated to pre- or post-conditions because that makes it impossible to test and re-create working environments.

    What can you do? We’ve found service registration tools (we like Consul.io) are essential and relatively easy to implement to help track services that we manage or proxy. More broadly, we’ve been working in the open on Digital Rebar to blend configuration and services into a single workflow.

    The first step is to re-examine your configuration management scripts (and their prerequisites) for hidden service API interactions. Exposing those external dependencies will help you improve your automation repeatability and portability.