[conspire] Internet Privacy: today's vote and measures to take

Rick Moen rick at linuxmafia.com
Tue Apr 4 18:15:55 PDT 2017


I must be distracted, because I meant to add:

Quoting Ivan Sergio Borgonovo (mail at webthatworks.it):

> Potentially I'm planning to serve up real _public_ authoritative DNS
> records.  It depends on if I'll be able to get a/some static IP and a
> fatter upstream.

If you happen to be new to the task of running authoritative DNS,
welcome to the gang, and prepare for a learning experience.

Quite a few years ago, when I was among the managing editors of _Linux
Gazette_ magazine, I did a series (well, a disconnected series of
articles about) doing DNS.  Somewhere in there, I got the notion that
it'd be easy to explain to the readership how to do all of the various
types of DNS service.  This was almost true -- true except for the one
variety that people most often do wrong.  Which is authoritative DNS.

I explained the heck out of the topic, in those articles, always leaving
authoritative DNS to cover later -- and never wrote that article,
because I slowly realised that a half-assed, breezy discussion of how to
do it right would poorly serve readers without also warning them about
how to avoid screwing it up in numerous ways.  Analogously and
exaggerating a good bit, this would be like sending 1912 transatlantic
ocean liner captains out saying 'OK, here's the steering wheel and
there's the coal.  Aim for New York and, oh, there might be icebergs.'

Each authoritative nameserver package has its own ideosyncratic way of
administering the daemon, managing the coming and going of 'zones',
which are more-or-less (usually) basically domains and domain-like
things.  Each has many details of daemon configuration.  And then there
is the management of the contents of zonefiles (or equivalent, like SQL
database tables in the case of PowerDNS Authoritative Server and some
similar packages).  The contents of zones have a whole bunch of fiddly
rules that really matter, but can be transgressed without the admin
being aware of having screwed up.  

And last, the management of the domains themselves (at the registrars)
has a bunch of best-practices constraints that closely tie in to the
DNS.  And this isn't well documented in a single place, let alone my
magazine articles, either.

Long ago, I started publishing a set of example, fully configured,
production BIND9 files that aim to help new DNS admins by giving them
a working example that they might choose to emulate.
http://linuxmafia.com/pub/linux/network/bind9-examples-linuxmafia.tar.gz
However, as I suggest above, the limitation of those example files
is that, although correct and well-formed (and carefully legible), 
they fail to specify _why_ they have the particular form and contents
they do, e.g., why they eschew almost entirely the CNAME record type, 
why there are always at least three authoritative namservers per domain
and no more than seven, and a bunch of other content decisions taken.

Sometimes, when I've checked other people's auth DNS setups including
their zonefile contents, I've been surprised by basic errors, but the
point is that these concern requirements I learned so long ago (often
back in the 1980s) and take so much for granted that it's difficult to
even remember them.

I've sometimes been asked where there's a good tutorial, and I don't at
this exact moment know of one.  I learned from experience, from some
judicious mentoring at the right times,  and from a lot of docs over a
lot of years.  http://linuxmafia.com/kb/Network_Other/ has _some_ stuff,
but I'm honestly not sure what's good to learn from (and modern in
coverage).





More information about the conspire mailing list