Dns on Miek Gieben

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.

DNS with K3s and systemk

Mon, 18 Jan 2021 09:38:37 +0000

In a DNS zone that I had laying around, I’ve come with the following scheme to have a working DNS with systemk. Note this does not deal with the control plane, those are routed via tailscale and I’m using IP addresses there. If naming is required here, it can be fitted in the scheme as well.

Using example.org as the domain here.

Scheme

An m “subdomain” (it’s not delegated) holds all the names and IP address of the machines of interest.

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!

Running CoreDNS as a Forwarder in Kubernetes

Sat, 13 Jan 2018 10:38:37 +0000

This post details how I got CoreDNS running as a forwarder in a Kubernetes cluster. There were several problems that stood in the way of this goal:

Having (and building) a cluster out of Raspberry PIs.
Making load balancing possible in a non-cloud environment.
- See https://github.com/google/metallb.
Extending CoreDNS with a plugin that could communicate with 9.9.9.9 using DNS-over-TLS.
- See https://github.com/coredns/forward.
Building arm docker containers on amd64.
- See https://github.com/miekg/dxbuild.
Having a (simple) CI system to build (Docker) images and version the k8s manifests.
- No published repository, see various gists referenced in this document.

Cluster

I bought 4 PIs, some nice Corkea cases, an Anker USB power supply and power- and network cables. Then it is just a matter if putting everything together and building the cluster.

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.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.

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)

Monitoring with SSH and Prometheus

Wed, 24 Feb 2016 11:35:01 +0000

I just wanted to see some qps metrics from BIND9.

This is a bit of hand wavey post on how to set up remote monitoring with Prometheus, Grafana and SSH tunnels.

Initially I just wanted to monitor BIND9 because it actually exports some reasonable metrics, that can be made usable with bind_exporter. But of course BIND is BIND so this is different in BIND 9.10 which is what I have on my server…. sigh. @jpmens also has some interesting tidbits about this BIND9 feature.

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.

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.