Dns on Miek Gieben

DNSSEC Too Complex

Sat, 04 Nov 2023 15:18:59 +0100

Deploying DNSSEC.

Even though I co-authored RFC 4641, laying out how you should run DNSSEC - I think in retrospect that BCP is way too complex, ah the sin of youth.

You should (if you want to run DNSSEC) run with a single key (called common-signing-key; CSK) and never roll your keys. This is what CoreDNS’ sign plugin implements and what I use.

Also see this Mastodon post.

A miekg/dns v2 package?

Fri, 15 Jul 2022 11:59:24 +0000

A DNS v2 library exists at https://codeberg.org/miekg/dns. And it’s fucking fast, ~~360K~~ 410K qps with UDP (on arm64) machines.

It:

Still uses Go structs (the naive thing I tested with a 100% binary format was dog slow), so no builder method.
Does the header/rdata split in RRs, with an rdata sub-package that contains the rdata. This solves the CopyWith and CopyWithout alluded below.
EDNS0 pseudo records are now also RRs.
Contains a Data []byte slice in Msg, to do reference wire-format.
Many, many, ease of use functions and sub packages, such as dnstest, dnsutil, dnsconf, etc.

While browsing, I stumbled upon https://pkg.go.dev/golang.org/x/net/dns/dnsmessage#Builder and I can see that is a way quicker way to create a DNS message. This made me think about a miekg/dns.v2 package again and what that should fix. I think it’s indeed better to just retain the wire format at all times as this is faster - although just working with a Go struct is very much a joy. Also begs the question: “Is it really that slow?” (compression on large messages is slow, memory use will def. be higher in current miekg/dns).

Internet Days

Thu, 02 Dec 2021 16:00:59 +0000

On the 22nd of November (2021) I gave a virtual presentation for the Swedish The Internet Days conference.

My talk was about CoreDNS: “Origin, Architecture and Usage”. Here is the PDF of that presentation.

CoreDNS: Origin, Architecture and Usage.

A Working Sign Plugin in CoreDNS

Sat, 03 Aug 2019 08:10:10 +0000

This sign plugin is working! I’m running it live for miek.nl on my servers to test it out. (See this branch or this one after it is merged into master.)

To use the sign plugin, I only need a few extra lines in my Corefile:

miek.nl {
    file /var/lib/coredns/db.miek.nl.signed
    sign /etc/coredns/zones/miek.nl {
        key file /etc/coredns/zones/keys/Kmiek.nl.+008+33694
        directory /var/lib/coredns
    }
}

This resigns the miek.nl zone ever so often. Logging will tell you what’s happening with your zonefile. In this case this it skips signing:

Signing in CoreDNS

Mon, 01 Jul 2019 17:27:12 +0000

I’m pondering adding a new plugin to CoreDNS that automatically signs DNS zones.

This new plugin will be called sign. I tried to prototype the README.md in that PR, as I like to start with the documentation when designing something new. It will do the bare minimum to give you “good DNSSEC” and will not implement key rollovers, nor the KSK/ZSK split. It will, however, add CDS records to your zone for easier interaction with your parent zone. Sign with a CSK, and use a proper new algorithm like ECDSA.

IETF 101 DNS Hackathon Results

Mon, 19 Mar 2018 07:27:00 +0000

The IETF 101 hackathon has come and gone. I wanted to write up the results of this. See my original plan for the hackathon.

Implement DOH (DNS over HTTPs). Go DNS already implements DNS over TLS, so this shouldn’t be too hard

This turned out to be “too hard” (who would have guessed?). Basically DNS over HTTPS (DoH) doesn’t map to proper DNS at all. See my write up to the DoH mailing list.

IETF 101 DNS Hackathon

Mon, 19 Feb 2018 10:27:00 +0000

The IETF 101 meeting is in London, and while I’m not going to the entire meeting, I thought it would be nice to go to the hackathon and work on Go DNS a bit.

This hackathon takes place in the weekend (and is free of charge, you’ll only need to register), so this leaves two days of ~~hacking~~^W careful coding.

I’m planning to work on the following bits:

Implement DOH (DNS over HTTPs). Go DNS already implements DNS over TLS, so this shouldn’t be too hard (famous last words). The plan here would be:

Extend the Net value in both Client and Server to include https variant.
Testing the client against one of the existing server implementations.
Getting Server side support going.
Unit tests

Time permitting implement gRPC in Go DNS in a “plug in my own transport” fashion. We use gRPC in CoreDNS and having it move to Go DNS would make life simpler. Of course DNS over gRPC is not a standard, so this needs to be pluggeable (there is not exact plan for this).
As these things all use TCP, it might also be worth looking a connection pooling. This is implemented in a CoreDNS plugin, called forward.
- Check if it makes sense to do in the Go DNS library.
- Make a plan.
- Implement.
- Profit.

If you are in the neighborhood and know a bit of Go, you’re welcome to help!

Debian Package For Coredns 1.0.0

Sat, 02 Dec 2017 07:59:36 +0000

With the deployment repo you can easily make your own Debian packages for CoreDNS; i.e. make debian should create packages for amd64, arm64 and armhf. It just did that for our 1.0.0 release and you can download them here:

Switching to Vodafone Uncovered a Bug

Fri, 17 Nov 2017 20:55:08 +0000

Recently I’ve switched to Vodafone for all my cellular needs, in a twisted turn of events this uncovered a goroutine leak in miekg/dns.

First some background on the setup I have at home (where this first showed up). I have your run-of-the-mill LAN + Wifi and a Raspberry Pi running CoreDNS for my DNS (proxy) needs. This CoreDNS instance forwards all DNS traffic to https://dns.google.com which uses a non-standard DNS protocol implemented as JSON over HTTPS. I use this so that my DNS traffic is encrypted. Note that CoreDNS makes heavy use of miekg/dns.

CoreDNS monitoring with stunnel

Mon, 28 Nov 2016 22:24:10 +0000

This article can be seen as a follow up to Monitor with SSH and Prometheus, but in a different, hopefully, more simple way.¹

Now I want to monitor CoreDNS running as a DNS to HTTPS proxy in my home network.

In one word: stunnel. (I had to upgrade Raspbian to Debian Testing to get an up to date stunnel though.)

I’ve setup a simple TLS tunnel with a pre-shared-key between my prometheus server and the NATted Raspberry Pi running in my homenetwork.

CoreDNS.io

Sun, 07 Aug 2016 09:58:01 -0700

I’ve created an official home for CoreDNS: https://coredns.io.

Still working on filling in the blanks and touching up on the “design”, but so far, so good. It features a bit of a startup vibe, and as with design of miek.nl we’ll see how it goes.

Most content will be linked from Github, and the Wiki that will eventually show up there.

I’ve also created a twitter account for @corednsio.

Debug Queries in CoreDNS with the etcd Middleware

Sun, 22 May 2016 21:32:35 +0100

Let’s say you have some data in etcd and use CoreDNS for service discovery. The Corefile looks like this:

.:53 {
    etcd skydns.local {
        stubzones
        path /skydns
        endpoint http://localhost:2379
        upstream 8.8.8.8:53 8.8.4.4:53
        debug  # <-- new, purpose of this blog
    }
}

You test with dig and you get the result below and you’re asking yourself wth is this happening? If you have access to etcd directly you can use etcdctl, if not you’re basically stuck.

Starting with CoreDNS

Wed, 27 Apr 2016 07:30:39 +0100

This post talks you through getting and setting up CoreDNS with a small zone file that it will serve. CoreDNS is a nameserver that is very flexible because it can chain different kinds of middleware. From the README:

CoreDNS aims to be a fast and flexible DNS server. The keyword here is flexible, with CoreDNS you are able to do what you want with your DNS data. And if not: write a middleware!

Caching in CoreDNS

Wed, 20 Apr 2016 07:54:08 +0100

In the last couple of evenings I’ve implemented a caching middleware in CoreDNS. It has a only a few knobs and should be simple to use.

Take a simple Corefile and add caching, via the cache directive.

.:1053 {
    proxy . 8.8.4.4:53
    cache 10 miek.nl
    log stdout
    errors stdout
}

Which defines CoreDNS to be a proxy, and only cache responses for the miek.nl zone. This cache only caches for up to 10 seconds. Lets send some queries and looks at the logs:

CoreDNS Dogfood, part 2

Fri, 15 Apr 2016 22:28:17 +0100

CoreDNS is running as my DNS server for at least a week.

That post was a bit light on the details, so find the complete Corefile that I’m using attached to this post below.

EDNS is now fixed and zones are reloaded when they changed on disk, i.e. DNSSEC signing with a simple CRON job:

2016/04/15 22:42:41 [INFO] Successfully reloaded zone `miek.nl.'
2016/04/15 22:42:41 [INFO] Sent notify for zone miek.nl. to 37.97.149.87:53
185.49.141.42 - [15/Apr/2016:22:42:41 +0100] "SOA IN miek.nl. udp false 2048" NOERROR 94 181.859µs
2016/04/15 22:42:41 [INFO] Sent notify for zone miek.nl. to 185.49.141.42:53
2016/04/15 22:42:41 [INFO] Outgoing transfer of 42 records of zone miek.nl. to 37.97.149.87 started

Monitoring works well and will be even further extended in the future.

CoreDNS Dogfood

Fri, 08 Apr 2016 19:31:02 +0100

Reading this means CoreDNS has done its job!

…And CoreDNS is live:

% dig @linode.atoom.net TXT CH version.bind +short
"CoreDNS"

This is quite nice, because it allows me test it properly with 3rd party tools, like zonemaster. That turned up one issue with EDNS which needs fixing. It would also be nice to have an automatic update and reloading of zones (after a signal).

The EDNS stuff will be fixed real soon (TM). The other stuff is less important. I will now also focus on performance, testing and fixing issue with the current set of middleware. (Although super awesome middleware is welcome!)

CoreDNS: almost ready to dogfood

Wed, 06 Apr 2016 22:24:45 +0100

I need to test AXFR and how it responds to notify, and yes this will get some proper *_test.go files in the near future, but for know I just need to know if it works just this once (TM). For this I need to transfer a zone and need to have a proper primary setup so that I can send notifies that CoreDNS will respond to.

So I ended up with the following Corefile, where 176.58.119.54 is the real primary, 127.0.0.1 is a fake one which allows me to send notifies with kdig.

Running CoreDNS

Sun, 03 Apr 2016 09:44:34 +0100

CoreDNS is now running on linode.atoom.net on port 1053 (yes not yet on 53..). It should implement most protocol features and allows for AXFR (to everyone) and is able to act as a secondary. Not bad after ~2 weeks of programming. ;-)

Recipe for writing a DNS server in 2 weeks:

Study the DNS for 15+ years.
Start an easy to use DNS library 5 years ago.
Write DNS server in ~2 weeks.

The current version of CoreDNS works, but isn’t fully standards compliant (in a few corner cases, mostly DNSSEC related). It is also optimistic about operational errors, i.e. it assumes everything will work as expected.

Almost ready to dogfood CoreDNS

Mon, 28 Mar 2016 21:47:02 +0100

CoreDNS is gaining more and more features, and bug #15, allowing CoreDNS to replace BIND9 in my home setup, is almost attainable. With a pre-signed DNSSEC zone (I just use CRON, don’t do key rollovers) and the following Corefile, CoreDNS is acting standards compliant already:

.:1053 {
    errors stdout
    log stdout
    file miek.nl.signed miek.nl {
        transfer out
    }

Start it, query it:

% dig @localhost -p 1053 SOA miek.nl +short
linode.atoom.net. miek.miek.nl. 1459138381 14400 3600 604800 14400

And! DNSSEC:

Writing CoreDNS Middleware

Fri, 25 Mar 2016 08:37:02 +0000

If it is not for me, give it to the next one.

Writing CoreDNS middleware consists out of four parts:

The actual middleware; the ServeDNS method that gets the request.
The setup part, the gets the Corefile configuration and creates the middleware.
Documentation.
Registration.

Note that part 1 and 2 also need tests!

Middleware

Let’s take a look at the chaos middleware that returns author and version information in the CH class. The main entry point for the whole thing is the Chaos structure. That structure holds some information and most importantly the Next middleware.Handler for chaining it to the next middleware:

SkyDNS in CoreDNS

Thu, 24 Mar 2016 18:31:18 +0000

The etcd middleware is shaping up nicely. With the following Corefile you already have a big chunk of the SkyDNS funcionality:

.:1053 {
    errors
    etcd skydns.local
    proxy . 8.8.8.8:53
}

Which says, run on port 1053, accept queries for all zones, if the zone matches skydns.local. go look in etcd, if it doesn’t forward to GOOG. Multiple zones should work as well, but this is not tested as of yet.

Let’s test this with the examples from SkyDNS' README. Let’s add all the rails production sites. (Why does this use rails btw?)

CoreDNS Chaining Middleware

Sat, 19 Mar 2016 20:59:53 +0000

CoreDNS is shaping up nicely and of course the middleware (taken from Caddy) is working great.

Take for instance the following. We want to rewrite ANY queries to HINFO (because DDoS) and then proxy them to Google. We also need some logging. So after downloading and compiling CoreDNS, create the following Corefile:

.:1053 {
    log stdout
    rewrite ANY HINFO
    proxy . 8.8.8.8:53
}

By default CoreDNS will read a file called Corefile, so we can just start it with:

Announcing CoreDNS

Fri, 18 Mar 2016 20:50:21 +0000

After some soul searching and help on twitter, I settled on “CoreDNS” as a name for my Caddy fork. CoreDNS, as it is just a shell to run middleware.

The code is up on Github.com. A little warning: The zone implementation is poor, the current middleware is lightly tested, etc., etc. The one thing it does well is chaining the middleware, currently implemented:

errors:: log errors, not tested, it compiles, no idea if it actually works.
log:: same story as errors.
proxy:: proxy request to a remote server, works, although flaky (prolly).
prometheus:: metrics; works. Not tested (i.e. full scraping with Prometheus).
reflect:: reflection service whenever you query for who.<domain>. Mainly used for testing.
rewrite:: can rewrite types in the request. Lightly tested.
file:: horrendous implementation that sort of works (some of the time).
etcd:: etcd backend (ala SkyDNS): not implemented.

Also the tests don’t compile :) This seems like a large list, but it is mostly fixing the details (a proper zone implementation will take some time though). In other words:

Caddy DNS update

Thu, 17 Mar 2016 22:13:29 +0000

More light!

My “Port Caddy to be a DNS server”-project is alive and kicking. Code will be published soon-ish, mostly waiting for actually naming the bloody thing. Code is also littered with TODOs.

I’ve implemented the following middlewares, the all need tests and actual use, but here we go:

log, for logging (as in Caddy)
error, for error logging (as in Caddy). These both include the {{placeholder}} syntax, so you can use {{port}} and even {>} for logging header bits.
file, really, really stupid zone file backed zone implementation, more a proof of concept
reflect, reflect (test) middleware
proxy, proxy requests to an upstream nameserver/resolver

I also want to add a rewrite middleware that will, for instance, rewrite ANY queries to HINFO ones.

First Light

Mon, 14 Mar 2016 21:31:01 +0000

So I did fork Caddy, and converted it into something that almost resembles a DNS server.

This is Caddy DNS (need an name!) without any configuration, i.e. an empty Caddyfile. It will then fallback and be a reflection server (couldn’t think of something better…). It will respond to queries that ask for who.<name> and will respond with your IP, port and transport.

So the first light query and answer would be:

dig @localhost -p 1053 A who.miek.nl

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62561
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;who.miek.nl.			IN	A

;; ANSWER SECTION:
who.miek.nl.		0	IN	AAAA	::1

;; ADDITIONAL SECTION:
who.miek.nl.		0	IN	TXT	"Port: 1234 (udp)"

And slightly later with the port number properly fixed:

Caddy DNS

Thu, 10 Mar 2016 21:41:08 +0000

Lately I’m thinking to use Go DNS to create a DNS server that is completely modelled after Caddy.

There is no code and no name, nothing. Just an idea.

So this magical new DNS server would be billed similar to Caddy, which has the tag line “Serve The Web Like It’s 2016”. Caddy for instance will automatically fetch certs from Let’s Encrypt and configure HTTP/2 and HTTPS. In the case of a DNS server that would translate to good core functionally, support for DNSSEC and key rotation, ala Knot DNS. Also note that now that DNS over TLS is a thing one could even image this server doing the exact same thing as Caddy and automatically getting certs from Let’s Encrypt. Same thing for the above mentioned DNSSEC key maintenance, <unamed server> will take care of it. (This is a non-trivial amount of work, I might add)

IDN and Private RR in Go DNS

Sun, 21 Sep 2014 19:45:00 +0000

Thanks to the excellent work from Alex Sergeyev, Go DNS has gotten some new features. I want to highlight two: IDN (https://www.ietf.org/rfc/rfc3492.txt) and Private RR support (http://tools.ietf.org/html/rfc6895).

IDN

This adds support for converting from and to Punycode. There is no explicit support, you will need to call idn.ToPunycode and idn.FromPunyCode yourself if you are dealing with IDNs.

The examples give in the code:

name := "インターネット.テスト"
fmt.Printf("%s -> %s", name, idn.ToPunycode(name))

Which outputs:

Go DNS package

Sat, 16 Aug 2014 09:33:00 +0000

Go DNS is a package that implements a DNS interface in Go. This library ~~takes a new, innovative and enterprise ready approach~~ sends and receives queries to and from the DNS. It is licensed under the same license as the official Go code, as this is a fork of that code.

The aim is to be powerful, simple and fast.

Supported:

All RR types;
Synchronous and asynchronous queries and replies;
DNSSEC: validation, signing, key generation, reading .private key files
(Fast) sending/receiving/printing packets, RRs;
Full control over what is being send;
Zone transfers, EDNS0, TSIG, NSID;
Server side programming (a full blown nameserver).
(Fast) reading zones/RRs from files/strings.

Code

The git repository is hosted on github.

SkyDNS running live

Sat, 28 Jun 2014 09:02:00 +0000

SkyDNS is able to do DNSSEC. It generates signatures and NSEC3 records on the fly. For authenticated denial of existence SkyDNS uses NSEC3 white lies, of course implementing (and testing!) this isn’t completely trivial.

To aid in debugging I’ve setup a live version of SkyDNS on voordeur.atoom.net, under the name the zone http://dnssex.nl:

% dig +mul +noall +answer @voordeur.atoom.net soa skydns.dnssex.nl
skydns.dnssex.nl.    3600 IN SOA ns1.dns.skydns.dnssex.nl. hostmaster.skydns.local. (
                            1403942400 ; serial
                            28800      ; refresh (8 hours)
                            7200       ; retry (2 hours)
                            604800     ; expire (1 week)
                            60         ; minimum (1 minute)
                            )

To help getting DNSSEC support 100% working this zone has been delegated and has an DS record in the parent zone. With unbound-host you can see the validation status of this zone:

SkyDNS version 2

Sun, 08 Jun 2014 12:46:00 +0000

SkyDNS version 1 was announced some time ago, since then it has seen some developments, which resulted in SkyDNS version 2. This new version uses Etcd as its backend. This blog post will walk you through the installation and shows how to use it.

What?!

SkyDNS(2) is a service discovery tool that utilizes the DNS to find hosts in a distributed environment. But using DNS means “legacy” clients can be used. Want to know if you MariaDB cluster is still up? ping mariadb.skydns.local can be used for that. By default SkyDNS will use skydns.local. as the domain to anchor all names.

DNS Router

Sat, 17 May 2014 10:35:00 +0000

Say you have a zone that does not fit in the memory of one machine. Who hasn’t these zones nowadays? How would you solve such a problem? With a DNS router of course!

Dns router is a small Go program I whipped together that acts as a DNS router. Clients register an <ip:port, regexp> combination and will then only receive queries that match that regular expression. The registration happens in Etcd. Of course “Dns router” (I need a better name), has some features, it will:

Why 13 DNS root servers?

Sun, 10 Nov 2013 20:11:00 +0000

Updated. Thanks to Carsten Strotmann, who chimmed in. The maximum packet is 576 octects as specified in RFC 791. Removing the headers, leaves ~512 octets for the payload. See https://ripe67.ripe.net/presentations/112-2013-10-16-dns-protocol.pdf. Numbers slightly updated.

So why are there (only) 13 root-nameservers? See the updates below, this scheme came into use in the 90ies.

A priming query is a query that a nameserver performs when it starts up to get a list of the root nameserver IP addresses. This is done to validate (and possibly update) the built-in list of the addresses it has. In the early days of the DNS, the maximum packet size was set to 512 bytes, so this list needed to fit in 512 bytes.

Do's and dont's for (ab)using the DNS

Sat, 12 Oct 2013 11:31:00 +0000

So you want to (ab)use the DNS for your usecase?

Here are some do’s and dont’s. For those inclined here is some background documentation on this subject:

Do not

Invent your own new TLDs. If you must, use something like .local, or .home, or use a domain that you actually own;
Use the TXT RR to cram it with your stuff (like the SPF guys did);
Store large data blobs in the DNS;
Use a new DNS class.

Do

Reuse existing RR types, there are some weird ones out there that might suite your use case, like NAPTR, or the well supported SRV record.
Register a new RR type if you think you’ll need one. Fill out the template detailing the new RR.
Store small data blobs in the DNS. Let them point to services where you can retrieve the data you’ll need.

Printing MX records with Go DNS, take 3

Fri, 07 Dec 2012 08:15:00 +0000

I’m starting to get really happy about the Go DNS API, so invasive API changes are less and less likely.

We want to create a little program that prints out the MX records of domains, like so:

% mx miek.nl
miek.nl.        86400   IN      MX      10 elektron.atoom.net.

% mx microsoft.com
microsoft.com.  3600    IN      MX      10 mail.messaging.microsoft.com.

We are using my Go DNS package. First the normal header of a Go program, with a bunch of imports. We need the dns package:

NSEC3

Mon, 03 Dec 2012 22:48:00 +0000

NSEC3 - A shadowy flight into the dangerous world of a record who does not exist.

Denial of Existence, a young loner on a crusade to champion the cause of the innocent, the helpless, the non-existent, in a world of records who operate above the law.

.NL DNSSEC error on 28th of October 2012

Wed, 31 Oct 2012 19:23:00 +0000

This is an official announcement from SIDN also published here.

Summary

In the course of Sunday 28 October, an error occurred during the publication of a new ZSK (with key tag 20331). Because of the error, the new ZSK was not published in the DNS when it should have been. However, the software used by SIDN (OpenDNSSEC) continued to work on the basis that the ZSK had been published successfully.

Lord of the DNSSEC

Thu, 22 Mar 2012 20:58:00 +0000

“One Key to rule them all,
one Key to find them,
one Key to bring them all
and in the Resolver bind them."

Modified from Lord of the Rings.

Yes, this quote is mine. And I think this Internet Protocol Journal has its first use.

Why not ZIP the damn thing

Sat, 17 Mar 2012 20:09:00 +0000

See this code in github, where I’ve implemented zipping DNS messages. A modified q prints the compression rate at the first line. It only shows how much compression you would get when you compress the answer.

For compression we use DEFLATE as described in RFC 1951. A typical example:

q @open.nlnetlabs.nl MX miek.nl
;; Uncompressed/Compressed 253/142 (1.781690)
;; bla bla bla bla

That’s not bad a compression factor of almost 1.8! Some more examples:

DNSSEC message checking

Sat, 21 Jan 2012 12:33:00 +0000

When using dig to debug DNS/DNSSEC errors, you (I have the need, I’m assuming you have it too) often want to know:

Are the signatures in the message correct?
Does the NSEC3 authenticated denial of existence proof look OK? (this is a work-in-progress)

With dig this is next to impossible, because we humans can not validate RSA signatures, nor hash names for NSEC3 validation.

This is why I added a little feature to q, the query-tool found in godns. The tool looks very much like dig or drill (from ldns).

NSEC3 white paper v2

Mon, 16 Jan 2012 13:02:00 +0000

(This is an English translation of this blog article over at sidnlabs.nl)

After the publication of the SIDN NSEC3 white paper we received feedback of a number of people. The most constructive feedback was from Karst Koymans of the University of Amsterdam. This, together with the other feedback has led to a version 2 of the white paper.

This version has the following differences with respect to version 1:

A number of corrections;
The NSEC3 example now returns three NSEC3 records in stead of two;
Two figures are added;
Empty non-terminals are explained (a little).

Version 2 of the white paper can be found here. Or here locally.

NSEC4

Mon, 09 Jan 2012 09:35:00 +0000

(This is a English translation of this Dutch blog article)

By writing the NSEC3 whitepaper, we gained a lot of insight in how “authenticated denial of existence” works. But some new questions popped up:

Is NSEC3 the most efficient way to do (hashed) authenticated denial of existence?
Are there ways to optimize the NSEC3 record that asserts or denies the wildcard?
Can’t we use Opt-Out for unhashed names too?

Answering these question led to the birth of NSEC4, which is documented in this internet draft.

NSEC3 Whitepaper

Wed, 09 Nov 2011 15:12:00 +0000

(This is an English translation of this blog article over at sidnlabs.nl)

In theory DNSSEC isn’t really that complicated, but in practice some parts can be pretty intimidating.

One such part is “Authenticated denial of existence”. In short this is communicating, with certainty, to a resolver that a name does not exist in the DNS.

The DNSSEC specification uses two records (and thus actually two different methods) for this purpose:

The NSEC record and;
The NSEC3 record.

In this white paper (local copy) we explain how NSEC and NSEC3 work and what the main differences are. We also show the evolutionary path of NSEC to NSEC3.