BIND DNSSEC Guide draft

[Timothe Litt]

On 31-Dec-14 21:00, Jeremy C. Reed wrote:
> ISC is seeking feedback and review for our first public draft of the 
> BIND DNSSEC Guide.  It was written in collaboration with DeepDive 
> Networking.
I haven't had a chance to look in detail, but a quick scan  resulted in
several
observations that I hope are useful.  Also, I posted your note to
dnssec-deployment, where there should be enthusiasm for the topic :-)

The private network section 6.5.4 doesn't talk about how to configure
views/stub zones so that authoritative (internal) zones on a shared
resolver/authoritative
server get validated.  (point 1 in the section dismisses the
possibility.)  This can be done.

Further, it's useful.  People are much more likely to experiment on
internal zones.
More important, consider a typical scenario: my web server on the
internal view
has a different address from the external view.  (Besides efficiency,
some commercial
routers don't do NAT on a stick  - e.g. allow an internal client to NAT
to an external
address served by that router, which is NATed to an internal server.)

So we want to train users to look for DNSSEC authentication.  Unless one
makes
this work, a notebook on the road will authenticate, but the same
notebook in the office
will not.  Don't bother trying to explain this to users; they'll simply
ignore the distinction.

Which is sort of a long way of saying: if the goal is to encourage
people to adopt DNSSEC,
your guide should make Private Networks and the corresponding recipes 
first class
citizens, not a 'don't bother with this' afterthought.  Both for admins
to feel freer to
experiment, and for users to have a consistent experience.

On key rollover - this is still a major hassle.  And while the recipes
look pretty, the process
is ugly.  Key rollover really needs to be automated.  There
are too many steps that require too much indirection.  And too many 'you
could do
this or you could do that' choices - that don't really matter,
especially for getting started. 
I don't see why a person should have to change parameters, dates,
manually generate
keys, etc.  You can work on the recipes, but I don't think they'll make
the problem
approachable - or safe.  Computers are good at this stuff - and people
aren't.

It really needs something like a daily cron job with a simple config
file that does all the work. 
Trigger based on dates, or a 'do it now' "emergency/manual" command. 
Key generation,
date setting, permissions, etc.  As for key uploads to external
registrars, it can mail the new keys/DS records
to the admin with 'please upload these by 'date'', and only proceed with
the roll-over when it can 'dig' them.
(The e-mail can - via the config file - include a hyperlink to the
upload page...)  For internal,
it can update the trusted keys include file, rndc reconfig, etc.
And the config file should come with reasonable default parameters, so
it 'just works' oob.
E.g. roll the zsks every 6 months and the ksks every 2 years. 
(Semi-random numbers, let's not fight about them.)

Also, RE TLSA - I think it's better to match just the subject public key
- there are several
cases where this reduces management overhead.  I know generating the
hash for that
with openssl isn't fun.  But, https://www.huque.com/bin/gen_tlsa is the
easiest way
that I've found to generate TLSA records. And it supports  SPKI
selectors...  So you might
want to point to it.

I'll try to have a closer look later.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

On 31-Dec-14 21:00, Jeremy C. Reed wrote:
> ISC is seeking feedback and review for our first public draft of the 
> BIND DNSSEC Guide.  It was written in collaboration with DeepDive 
> Networking.
>
> The document provides introductory information on how DNSSEC works, how 
> to configure BIND to support some common DNSSEC features, as well as 
> some basic troubleshooting tips.  It has lots of interesting content, 
> including examples of using ISC's "delv" tool and using a common 
> provider's web-based interface to manage DS records.
>
> This is a beta edition of the guide. We'd appreciate any feedback or 
> suggestions, good or bad. You may email me directly, or to our 
> bind9-bugs@ bug tracker email, or back to this list as appropriate (such 
> as needing further community discussion). Or you may use the GitHub to 
> provide feedback (or fixes).  We plan to announce the first edition of 
> this BIND DNSSEC Guide at the end of January.
>
> The guide also has a recipes chapter with step-by-step examples of some 
> common configurations. If you have any requests or would like to 
> contribute some content, please let us know.
>
> The beta of the guide is available in HTML and PDF formats at
>
> http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html
> http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.pdf
>
> The docbook source for the guide is at GitHub:
> https://github.com/isc-projects/isc-dnssec-guide/
>
> Happy New Year!
>
>   Jeremy C. Reed
>   ISC
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150104/d9f0929f/attachment.bin>