Subject: [DNSOP] tdns teachable from scratch authoritative server 'official launch'

From: bert hubert <[email-masked]>
Date: Fri, 20 Apr 2018 15:01:19 +0200

Hi everyone,

I'm happy to announce that RIPE Labs allowed me some prime space on their
site to announce 'tdns'. I posted about this before, but your help is really
welcome right now. 

https://labs.ripe.net/Members/bert_hubert/introducing-tdns-the-teachable-authoritative-dns-server
has the contents with clickable links.

[side note, also read Geoff Huston's excellent "Stuffing the Camel into the
Bikeshed": https://blog.apnic.net/2018/04/10/opinion-stuffing-the-camel-into-the-bikeshed/
]

"tdns is part of the 'hello-dns' effort to provide a good entry point into
DNS.  This project was started with my 'DNS Camel' presentation at the IETF
101 in London in which I showed that DNS standards have now grown to 2,500
pages, and that we can no longer expect new entrants to the field to read
all that.  After 30 years, DNS deserves a fresh explanation and hello-dns is
an attempt to do just that.

Even though the 'hello-dns' documentation describes how basic DNS works, and
how an authoritative server should function, nothing quite says how to do
things like actual running code.  tdns is small enough to read in one
sitting and shows how DNS packets are parsed and generated.  tdns is
currently written in C++ 2014, and is MIT licensed.  Reimplementations in
other languages are highly welcome, as these may be more accessible to
programmers not fluent in C++."

Of specific note are these paragraphs:

"That sounds like hubris

In a sense, this is by design.  tdns attempts to do everything not only
correctly but also in a best practice fashion.  It wants to be an excellent
nameserver that is fully compliant to all relevant standards and DNS
operational lore.

I hope that the DNS community will rally to this cause and pore over the
tdns source code to spot everything that could potentially be wrong or could
be done better.

In other words, where tdns is currently not right, we hope that with
sufficient attention it soon will be.  Bikeshed away!"

I kindly request your best bikeshedding efforts. What is not yet best
practice? What learnings have I missed? For example, there is debate how
malformed a packet must be before it is best not to answer it. QR=1 is
clear, but what about other forms of breakage? Not answering opens seconds
of room for Kaminsky spoofing etc.

To dive in, here is Doxygen annotated source: https://powerdns.org/hello-dns/tdns/codedocs/html/
Or the long form description: https://powerdns.org/hello-dns/tdns/README.md.html
Or GitHub: https://github.com/ahuPowerDNS/hello-dns

Thanks!

	Bert