DNS

Knot DNS: One Tame and Sane Authoritative DNS Server

Thomas Golden — Fri, 24 May 2019 12:30:00 +0000

How to install and minimally configure Knot to act as your home lab's local domain master and slave servers.

If you were a regular viewer of the original Saturday Night Live era, you will remember the Festrunks, two lewd but naïve Czech brothers who were self-described "wild and crazy guys!" For me, Gyorg and Yortuk (plus having my binomial handed to me by tests designed by a brilliant Czech professor at the local university's high-school mathematics contests) were the extent of my knowledge of the Czech Republic.

I recently discovered something else Czech, and it's not wild and crazy at all, but quite tame and sane, open-source and easy to configure. Knot DNS is an authoritative DNS server written in 2011 by the Czech CZ.NIC organization. They wrote and continue to maintain it to serve their national top-level domain (TLD) as well as to prevent further extension of a worldwide BIND9 software monoculture across all TLDs. Knot provides a separate fast caching server and resolver library alongside its authoritative server.

Authoritative nameserver and caching/recursive nameserver functions are separated for good reason. A nameserver's query result cache can be "poisoned" by queries that forward to malicious external servers, so if you don't allow the authoritative nameserver to answer queries for other domains, it cannot be poisoned and its answers for its own domain can be trusted.

A software monoculture means running identical software like BIND9 everywhere rather than different software providing identical functionality and interoperability. This is bad for the same reasons we eventually will lose our current popular species of banana—being genetically identical, all bananas everywhere can be wiped out by a single infectious agent. As with fruit, a bit of genetic diversity in critical infrastructure is a good thing.

In this article, I describe how to install and minimally configure Knot to act as your home lab's local domain master and slave servers. I will secure zone transfer using Transaction Signatures (TSIG). Although Knot supports DNSSEC, I don't discuss it here, because I like you and want you to finish reading before we both die of old age. I assume you already know what a DNS zone file is and what it looks like.

Go to Full Article

VCs Are Investing Big into a New Cryptocurrency: Introducing Handshake

Petros Koutoupis — Thu, 02 Aug 2018 21:14:15 +0000

by Petros Koutoupis

The entire landscape of how we authenticate domain names likely will see a complete overhaul, all powered by blockchain technologies. Just released, Handshake brings with it the much needed security and reliability on which we rely. Backed by venture capitalists and industry-established blockchain developers, Handshake has raised $10.2 million to replace the current digital entities maintaining our current internet infrastructure.

The project and protocol has been led by Joseph Poon (creator of Bitcoin's Lightning Network), Andrew Lee (CEO of Purse), Andrew Lee (founder of Private Internet Access or PIA) and Christopher Jeffrey (CTO of Purse). The effort also is backed by 67 individuals with funding coming from A16z, Founders Fund, Sequoia Capital, Greylock Partners, Polychain Capital and Draper Associates.

The Handshake project pledges to donate its initial funding of $10.2 million to FOSS projects, university research departments and more. The list of recipients includes projects and foundations such as the Apache Software Foundation, FreeBSD, Reproducible Builds, GNOME, FSF, SFC, Outreachy, ArchLinux, systemd and many more.

What Is Handshake?

Handshake aims to be a wholly democratic and decentralized certificate authority and naming system. Handshake does not replace the Domain Name System (DNS). It is, however, an alternative to today's certificate authorities—that is, it uses a decentralized trust anchor to prove domain ownership. Although the primary goal of the project is to simplify and secure top-level domain registration while also making the root zone uncensorable, permissionless and free of gatekeepers.

A traditional root DNS supports the current infrastructure of the internet and, therefore, facilitates online access. The root servers hosting the internet publish root zone file contents, which are responsible for the internet's DNS functionality. DNS associates information with domain names and maps them to public-facing IP addresses.

The way Handshake differs from this is that it's all peer to peer. Every peer is responsible for validating and managing the root zone (via the use of "light clients"). All existing entries in the root zone file will form the genesis block of the blockchain supporting it. The same root zone will be distributed across the nodes forming the chain. The implementation allows for any participant to help host this distributed root zone and add to it.

Go to Full Article

Best of Hack and /

LJ Staff — Wed, 05 Apr 2017 11:40:59 +0000

by LJ Staff

Secure Server Deployments in Hostile Territory; Preseeding Full Disk Encryption; Own Your Own DNS; Learn How-to Secure Desktops with Qubes; What's New In 3D Printing

Secure Server Deployments in Hostile Territory
Would you change what you said on the phone, if you knew someone malicious was listening? Whether or not you view the NSA as malicious, I imagine that after reading the NSA coverage on Linux Journal, some of you found yourselves modifying your behavior. The same thing happened to me when I started deploying servers into a public cloud (EC2 in my case).

In this article, I discuss some of the techniques I use to secure servers when they are in hostile territory. Although some of these techniques are specific to EC2, most are adaptable to just about any environment.

Preseeding Full Disk Encryption
Usually I try to write articles that are not aimed at a particular distribution. Although I may give examples assuming a Debian-based distribution, whenever possible, I try to make my instructions applicable to everyone. This is not going to be one of those articles. Here, I document a process I went through recently with Debian preseeding (a method of automating a Debian install, like kickstart on Red Hat-based systems) that I found much more difficult than it needed to be, mostly because documentation was so sparse. In fact, I really found only two solid examples to work from in my research, one of which referred to the other.

Own Your Own DNS
I honestly think most people simply are unaware of how much personal data they leak on a daily basis as they use their computers. Even if they have some inkling along those lines, I still imagine many think of the data they leak only in terms of individual facts, such as their name or where they ate lunch. What many people don't realize is how revealing all of those individual, innocent facts are when they are combined, filtered and analyzed.

Go to Full Article

Dynamic DNS—an Object Lesson in Problem Solving

Shawn Powers — Tue, 21 May 2013 18:47:39 +0000

by Shawn Powers

The other day in the Linux Journal IRC room (#linuxjournal on Freenode), I was whining to the channel about no-ip.com deleting my account without warning. My home IP address hadn't changed in a couple months, and because there was no update, it appeared abandoned. The problem was, although the IP address hadn't changed, I was using the Dynamic DNS domain name to connect to my house. When the account was deleted, the domain name wouldn't resolve, and I couldn't connect to my house anymore.

The folks in the IRC channel were very helpful in recommending alternate Dynamic DNS hosting services, and although there are still a few free options out there, I was frustrated by relying on someone else to manage my DNS services. So, like any nerd, I tried to figure out a way to host a Dynamic DNS service on my own. I thought it would be a simple apt-get install on my colocated server, but it turns out there's not a simple Dynamic DNS server package out there—at least, not one I could find. So, again like any particularly nerdy nerd, I decided to roll my own. It's not elegant, it's not pretty, and it's really just a bunch of cheap hacks. But, it's a great example of solving a problem using existing tools, so in this article, I explain the process.

First, it's important to point out a few things. The purpose of this article is not really to explain the best way to make a self-hosted Dynamic DNS system. In fact, there probably are a dozen better ways to do the same thing. That's sort of the point. The more familiar you are with Linux tools, the more resourceful you can be when it comes to problem solving. I go through the steps I took, and hopefully most readers can take my method and improve on it several times over. That type of collaboration is what makes the Open Source community so great! Let's get started.

My Particular Toolbox

We all have a slightly different bag of tricks. I'm in the "extremely lucky" category, thanks to Kyle Rankin tipping me off about the free Raspberry Pi colocation service. A full-blown Linux box with a static IP on the Internet is truly the sonic screwdriver when it comes to these sorts of things, but perhaps someone else's solution won't require a complete server.

Along with the Raspberry Pi server, I have a Linux server at home, a home router and a handful of domains I own. I also have accounts on several Web hosting servers, and accounts with cloud-based storage like Dropbox, Google Drive and a handful of others.

First Problem—What's My IP?

The beauty of Dynamic DNS hosting is that regardless of what your home IP address is, the same domain name will resolve even if it changes. Granted, my home IP address hadn't changed for months, but I still used the DNS name to access it. Therefore, when my account at no-ip.com was deleted, I had no way to tell what my home IP was.

Go to Full Article