Routing DNS packets with Go.

Why are there 13 (logical) DNS root nameservers?

Some guidance on how put data in the DNS

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

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.

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.

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

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.

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.

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

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

(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 problem: you want to keep a historical reference of zone changes. This little script helps you do that, it: AXFRs the zone you want; Cleans the zone a bit, sorts it and feeds it through named-compilezone to make it look “nice”; Puts it in a git repository; Checks it in with a date tag (date -u '+%Y-%m-%d_%H%M%S'). You do need to define the directory where the git repository is located in the script ($gitdir).

.be [1] .de [1][4] .nl [2] .uk [2] .se [2] .fr [3] DNSSEC 2010-10-07:Expired signatures. Notice. Soon? Soon? 2010-09-13:Signing failure due to failover. Notice. Soon? 2011-02-12:Invalid signature on NSEC3 disproofing DS.5 Notice. BIND Bug. DNS Soon? 2010-05-12:Partial zone published. Notice. 2008-05-28:Partial zone published: missing glue. Notice (Google Translate). Soon? 2009-10-13:Corrupt zone published: .se appended twice. Notice. Soon? [1]Homebrew signer/key management [2]OpenDNSSEC [3]OpenDNSSEC + BIND [4]Not deployed DNSSEC yet [5]WTF?

And finally, after so many years miek.nl can be DNSSEC validated from the root down. Check it yourself.

I’ve extended the DNS filesystem a bit and added the possibility to WRITE to it. This only works for zones which utilize dynamic updates. You can now mount the world and write to it! Also TSIG should be supported (but I have not tested it - as I’m lazy). For TSIG you need a file (named “dynupdate” here with the following): # domain tsig-key name key miek.nl tsig-key awwLOTrFPge+rRKF2+DEiw== Code is still contained in a single Perl file.

This is the second time I’m writing this, but now its much better then the previous attempt. The idea is as follows, using Fuse and Perl this is an actual filesystem which maps the DNS to files and directories. You can now mount the world! :-) The following holds true for this filesystem: Uppercase named directories are zone-cuts, or; Uppercase named directories are labels; Lowercase named files are rrtypes (like txt, soa, etc.

Congrats to SIDN % dig +dnssec +multiline DNSKEY nl ;; ANSWER SECTION: nl. 6547 IN DNSKEY 256 3 8 ( AwEAAbXfJH0LevocrgMOI62Y0+oD02AxPrsXja59z11c cqgW527Ghac2f1aj32a4c1Wc+H6UhTy+daf6LkVytw0l lMmzDDVn/YHcfh7B+9DdbVjdBHvY6q+YTnZbsU3wGwod PMneYJZl8d47eFYmraKKl/endifNukan0z4GkaKYHuI1 ) ; key id = 37408 nl. 6547 IN DNSKEY 257 3 8 ( AwEAAekt0eDh+EmOVQMh1av++d5F6eS3B85YkFW9OBQN 8X9EA1rG8vl9TRHFBUfpu/vIaUJeuXV9tm/PO+qhNyIL WxI26W1t1/EKr1WhbaNsLXPMhjtuelPqpxuQL/onXvhB 83uPcF88pjnKmu73pcdhInLfYkf4JfARztj4e+xaddoL 5eJ0Fj3KMVd303NAsH0tmRPBi3EGMAOtM4Ic84Rn8ZkH bwmVUQ3n4qRYaLpgvmpX82RUpEkgPxhrrJGENp1QYGPv 0oWPWkcJcSUGsEBgjLSal5IzTJmOEFm7nzbvyrfq/KJX PZZRfJgPpFPwqNfY+GlTfb39kDEcB34z2LCNM2U= ) ; key id = 38420 nl. 6547 IN RRSIG DNSKEY 8 1 7200 20100902004149 ( 20100819064254 38420 nl. 0/C52WJ2OjQZOrP8y7relQWGVS5gmJLnwnrbic7dGNeJ PVjI7W2gXgt8vVTg36bQ6gVpX7GG2zwvNA/cYTGYnfvF n+0HpA8oZLqeVh1rbQR3oU+iym5F4vX1pka7pbJk358x O9B9KsMFXH9exCoHHXzu/SU3D/TPZ60imrNgvJp6iOci kPeomSQhwKmyyKBUheaOocdV/XIMtzFwOnKYV6bu9wCq PXtOj4Qhp8Ty7mGMnOSpgAzwWcksvqmSZeNpC/tLT/57 TxefWNNGlbdY7+fxvA0T+AQVn0xctsS1y194SAv92kZW azVQ9+ZYxQLVZqwSl1/ZBo8spxT1aiwMnw== )

Okay, I could not find this in the specs, but I do find this fishy. When querying a Windows DNS server it will give out an authoritative answer (aa bit set), but without an AUTHORITY section. dig +nocmd +noidentify +multiline @ns5.msft.net. soa hotmail.com ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;hotmail.com. IN SOA ;; ANSWER SECTION: hotmail.

If you ever administered a DNS server you are probably familiar with the IN (internet) class, as in localhost IN A 127.0.0.1 where you define an IP address for the name localhost. As you may, or may not, already know there are other classes defined (but hardly used) for the DNS. Two of those are the Chaos class (CH) and the Hesiod (HS) class. With these classes you can create some sort of parallel world where you can also define names.

I’ve done some work in the development of the DNSSEC protocol, this culminated (for me) in RFC 4641. At the time I was a big proponent of DNSSEC. I still think the DNS should be improved and also believe DNSSEC is one of the best solutions. I’m however not as sure about this as I once was. This is because of several reasons. The first one being the development of the NSECn record.

DSA 1617-1 a security update from Debian says they forgot to update the SE Linux policy that would allow BIND9 to randomize its source ports… I always found SE Linux to be too complex for my needs, but now it turns out you can actually be more vulnerable when you run SE Linux. I know enough.

.nl employs a system for registering a domain name that works as follows: you setup a zone you register the zone name .nl checks the zone from your nameservers if the zone is found to be OK, your name is registered if it is not ok, you have to fix your zone or the name is already claimed (you can check that before hand) This conflicts with how most ISPs work.