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 > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
