
Hello, and welcome to DNS - pjf
https://powerdns.org/hello-dns/
======
Annatar
Ahhh, PowerDNS! At the time I determined that BIND was completely unscalable
to perform configuration management on (no include directives in those days,
circa 2007), I determined that I needed a DNS server which supported ordinary
SQL and a relational database on the backend.

PowerDNS was the only DNS server at the time to use a relational database, and
they supported several, including Oracle, which is what won me over. I
embarked on an epic journey to make PowerDNS a first class citizen on Solaris
10. It took me five years, but boy did it pay off with massive dividends in
stability and scalability!

PowerDNS isn't a perfect piece of software though: it has two major
weaknesses, first that it is written in C++ as opposed to C and that made it a
bitch to port to Solaris, and second that it depends on Boost, which is also a
massive, bloated C++ monster which is a nightmare to get to build on any
platform, let alone Solaris.

However, the software itself is a damn good DNS server, resistant to most
attacks and constantly improving having had loving care from its user
community, some which could be core PowerDNS developers in their own right.
Finally it bears writing that the owners of PowerDNS are some of the kindest,
sweetest guys one ever had the pleasure of working with, and they are open to
considering suggestions and accepting contributions in patches and features.
They were an absolute blast to work with over the years and could serve as
poster children on how open source collaboration could work and make money off
of at the same time.

~~~
yipbub
How _did_ they make money?

~~~
ahubert
I did a talk on that at OHM2013 but sadly the recordings got lost. Will blog
it up one day. You can be a "good" open source company and still make money!
It does require a lot of planning though.

------
ahubert
Hi! Author of that page here. Let me know your thoughts, or express your
feelings in a pull request! [https://github.com/ahupowerdns/hello-
dns/](https://github.com/ahupowerdns/hello-dns/) \- you might also appreciate
the DNS RFC viewer on [https://powerdns.org/dns-
camel](https://powerdns.org/dns-camel) . Finally, this all started based on
this IETF presentation: [https://blog.powerdns.com/2018/03/22/the-dns-camel-
or-the-ri...](https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-
in-dns-complexit/)

~~~
bogomipz
This is great! I look forward to reading more in this series. Cheers.

------
hliyan
It's a rarity to see websites where form follows function these days: table of
contents, heading, and content. This is what the web should be...

~~~
captn3m0
Looking at the source, it feels like it should work without JS, but it doesn't
(Firefox 60 beta, Linux)

Neither of elinks/lynx renders it correctly either.

~~~
feelin_googley
It does work without JS. For elinks, try pressing the backslash key.

~~~
JdeBP
captn3m0 is right. It does not. Chrome renders it as a long but entirely blank
page.

~~~
feelin_googley
It works with elinks. When the page is loaded, press backslash key (view page
source). See below for sample.

I dont use Chrome. Cant comment on that.

    
    
                    <meta charset="utf-8" emacsmode="-*- markdown -*-">
                                **A warm welcome to DNS**
    
       # Hello, and welcome to DNS!
    
       This series of documents attempts to provide a correct introduction to the
       Domain Name System as of 2018.  The original RFCs remain the authoritative
       source of normative text, but this document tries to make this venerable
       protocol more accessible, while maintaining full alignment with all relevant
       and useful RFCs.

~~~
JdeBP
If you have to view the source to even see anything with elinks, then "it
works" is not a correct description.

~~~
feelin_googley
You see something before hitting backslash. I guess you didnt even bother to
try it? Why are you even commenting then? When you hit backslash it simply
changes the formatting, making what you see easier to read. If I can read the
content as text, then it works. Its a text-only browser. Its for reading text,
not executing Javascript.

If I recall correctly many years ago on the djbdns mailing list djb said you
did not know what you are talking about or something to that effect. At the
time I thought maybe he was being a little harsh. As usual, he was right. You
are annoying.

------
ChrisSD
> In order to squeeze as much information as possible into the 512 bytes...

I appreciate that this is a work in progress but this section is misleading.
As all too briefly mentioned elsewhere on the page, EDNS allows extending
this. In practice most of the resolvers I connect to do support EDNS and a
buffer of 4096. So yes 512 may be needed as a fallback (depending on what
you're doing) but you'll almost certainly have more room to breathe than that.
IPv6 and DNSSEC practically make the extra space a necessity.

> DNS names can (and often MUST) be compressed.

I don't think I've ever seen label compression in actual use? RFC 6891
([https://tools.ietf.org/html/rfc6891](https://tools.ietf.org/html/rfc6891))
seems to suggest they're obsolete.

That critique aside, it seems like this will become a good tutorial. And if
you're looking for a reference I'd point to the IANA's page on DNS parameters
([https://www.iana.org/assignments/dns-parameters/dns-
paramete...](https://www.iana.org/assignments/dns-parameters/dns-
parameters.xhtml)) it lists and organises most of the relevant RFCs. RFC 6895
([https://tools.ietf.org/html/rfc6895](https://tools.ietf.org/html/rfc6895))
is a particularly useful resource for best practices.

~~~
colmmacc
Label compression is pretty common, I think all of the big name server
implementations do it by default. Amazon Route 53 definitely does it - I wrote
the code! But my favorite thing about DNS label compression is probably this
quote from DJB's code where he implemented it ...

[https://github.com/abh/djbdns/blob/0715ca5de14ad5eae2c779c53...](https://github.com/abh/djbdns/blob/0715ca5de14ad5eae2c779c536beee2ef56d07a2/dns_packet.c#L2)

~~~
bluejekyll
Yeah, label compression is very much in use. It is annoying though, it’s one
of the slower pieces during serialization.

------
DyslexicAtheist
_" The original RFCs remain the authoritative source of normative text, but
this document tries to make this venerable protocol more accessible, while
maintaining full alignment with all relevant and useful RFCs"_

so if anyone has lost their mind looking for a complete list of DNS RFC's and
their relationship / timeline, ... knock yourselves out:
[https://emaillab.jp/dns/dns-rfc/](https://emaillab.jp/dns/dns-rfc/)

~~~
ahubert
Another viewer is [https://powerdns.org/dns-camel](https://powerdns.org/dns-
camel) \- where you can select obsoleted, informational, experimental,
historic, and standards (track) RFCs. And drafts!

~~~
jlgaddis
FWIW, this is completely unusable on an iPad.

------
DanielDent
It looks like RFC 7873 (May 2016) came up with a very different meaning for
"DNS cookies" than I did in 2015.

It's an unfortunate naming collision.

My meaning: [http://dnscookie.com/](http://dnscookie.com/) RFC 7873 meaning:
[https://tools.ietf.org/html/rfc7873](https://tools.ietf.org/html/rfc7873)

------
justaj
Is there any particular reason why Javascript has to be enabled just to view
this page? Or even have a minified JS file in the first place?

~~~
guessmyname
The author is using Markdeep [1] to render the plain text content of that page
as HTML.

Disabling JavaScript will leave the entire page in plain text again, which
should still work.

[1] [http://casual-effects.com/markdeep/](http://casual-effects.com/markdeep/)

------
arca_vorago
I've implemented powerdns in prod a few times and really like it. There are
some quirks but it has good documentation and a huge point for me is it is gpl
(or gpl compat, I can't remember which)

~~~
koffiezet
Same, I use it as the central authoritative DNS server for our internal
domains, backed by a simple sqlite datbase which seems to be able to handle it
without a single issue. Local Bind9 instances are configured on all our sites
to ASFR all zones, and handle the client-facing traffic. All this is managed
using Ansible, and works like a charm.

------
feelin_googley
"When in doubt: authoritative servers 'host' DNS data, 'resolvers' look up
things over at authoritative servers and clients run 'stub resolvers' to look
things up over at resolvers."

What about programs run by clients that look things up over at authoritative
servers? (Programs that do _not_ look things up over at resolvers.)

"Zone files are one way of storing DNS data, but these are not integral to the
operation of a nameserver. The zone file format is standardized, but it is
highly non-trivial to parse.

...

Of specific note, many people have attempted to write a grammar (parser) for
zonefiles and it is almost impossible."

I am guessing this statement is only referring to "BIND" zone file format.

I wonder how that could be a desirable or even acceptable state of affairs:
having a "standardized" format that is "almost impossible" to parse.

The author suggests zone files are "not integral" to operation of a
nameserver.

If zonefiles are optional does that also leave the programmer the option to
use a zonefile format of their own choosing?

IME, parsing a tinydns zonefile is not difficult at all, because the author
did not use the "standardized" BIND zonefile format.

~~~
inopinatus
> What about programs run by clients that look things up over at authoritative
> servers?

Aside from the utilities like dig, I call those “resolvers” too. Doesn’t
matter if they’re client-specific. The term still fits, it describes what the
code is doing.

~~~
feelin_googley
Heres Wikipedia:

"Stub resolvers are "minimal DNS resolvers that use recursive query mode to
offload most of the work of DNS resolution to a recursive name server."

A stub resolver will simply forward a request to a recursive name server..."

dig can send both recursive and non-recursive queries.

This appears to meet the definition of a "stub resolver" according the
definition above.

However I am asking about programs that send _only_ non-recursive queries and
only send them to _authoritative nameservers_.

(FWIW I do not consider caches to be authoritative for any name.)

Is there a well-understood term to describe this type of program?

~~~
inopinatus
You seem to be trying to classify DNS clients by what they do mechanically.
But that isn't the case. DNS software is classified according to its role and
expected capabilities. There's a relationship between role and action, but
it's the former that matters much more when it comes to naming of parts.

Rather than looking at Wikipedia I suggest consulting RFC 7719 "DNS
Terminology",
[https://tools.ietf.org/html/rfc7719](https://tools.ietf.org/html/rfc7719)
where you will find that your program is simply called a "resolver": "A
program that extract[s] information from name servers in response to client
requests."

That RFC further describes some specific classes of resolver, but dig is most
definitely not a "stub resolver" because these are characterised by what they
_cannot do_ , whilst dig is a swiss-army knife utility that can do a great
deal - which merely happens to include, amongst other things, sending the same
queries that a stub resolver might send.

In terms of implementation details, your specific description: "programs that
send only non-recursive queries and only send them to authoritative
nameservers" describes the principal activity of the resolver side of most
implementations of a full-service resolver. However if you read that RFC
you'll see that it equivocates about the implementation details of full-
service resolvers in general, because in classification the role and outcome
matters more than the action.

