Do you know someone who deserves recognition for launching the Internet in their region or country? Or someone who made some major technical innovation that made the Internet faster or better? Or someone who is a passionate advocate who influenced other people to make the Internet better? Can you think of someone who helped the Internet reach new people? For example, in a new region or language? Do you know someone who made the Internet more inclusive and accessible to more people?
As the pandemic continues, the network operator community continues to meet online. NANOG held its 81st meeting on February 8 and 9, and these are my notes from some of the presentations at that meeting... Ethernet, developed in 1973 at Xerox PARC, was a revolutionary step in network architectures in many ways. The common bus architecture imposed several constraints on the network that have echoed through the ensuing four decades in all kinds of ways.
In previous posts in this series, I've discussed a number of applications of cryptography to the DNS, many of them related to the Domain Name System Security Extensions (DNSSEC). In this final blog post, I'll turn attention to another application that may appear at first to be the most natural, though as it turns out, may not always be the most necessary: DNS encryption. (I've also written about DNS encryption as well as minimization in a separate post on DNS information protection.)
In my previous post, I described the first broad scale deployment of cryptography in the DNS, known as the Domain Name System Security Extensions (DNSSEC). I described how a name server can enable a requester to validate the correctness of a "positive" response to a query -- when a queried domain name exists -- by adding a digital signature to the DNS response returned.
Dear Chief Financial Officers of tech giants, the internet is in crisis, and you can lead your organization to help solve the problem. You'll be well compensated, and you'll enjoy massive public relations benefits. I fear that if you don't, global governments will force your hand. There is a shortage of available IPv4 addresses but we are years away (possibly a decade or more) from IPv6 viability and adoption in North America.
Technical development often comes in short, intense bursts, where a relatively stable technology becomes the subject of intense revision and evolution. The DNS is a classic example here. For many years this name resolution protocol just quietly toiled away. The protocol wasn't all that secure, and it wasn't totally reliable, but it worked well enough for the purposes we put it to.
We used to think of computer networks as being constructed using two fundamental common infrastructure components: names and addresses. Every connected device had a stable protocol address to allow all other devices to initiate a communication transaction with this device by addressing a data packet to this protocol address. And every device was also associated with a name, allowing human users and human use applications to use a more convenient alias for these protocol addresses.
The DNS is a remarkably simple system. You send it queries, and you get back answers. Within the system, you see exactly the same simplicity: The DNS resolver that receives your query may not know the answer, so it, in turn, will send queries deeper into the system and collects the answers. The query and response process is the same, applied recursively. Simple. However, the DNS is simple in the same way that Chess or Go are simple...
Data privacy and security experts tell us that applying the "need to know" principle enhances privacy and security, because it reduces the amount of information potentially disclosed to a service provider -- or to other parties -- to the minimum the service provider requires to perform a service. This principle is at the heart of qname minimization, a technique described in RFC 7816 that has now achieved significant adoption in the DNS.
Three years ago, the first Internet-Draft on Registry Maintenance Notifications for the Extensible Provisioning Protocol (EPP) was published, which will become a Request for Comments (RFC). The IETF Registration Protocols Extensions (REGEXT) working group is the home of the coordination effort for standards track EPP extensions. They released eight RFCs over the last couple of years, and they are currently working on more than 15 Internet-Drafts.