Almost Ready for DNS-SEC but Slightly Confused in Home Stretch

Kevin Oberman oberman at
Fri Dec 10 16:41:16 UTC 2010

> Date: Fri, 10 Dec 2010 10:17:57 -0600
> From: Martin McCormick <martin at>
> Sender: at
> On my test box, I am not seeing any errors so I think we are
> signing the test zone. The dnssec part of named.conf options
> looks like:
> dnssec-enable yes;
> dnssec-validation yes;
>            dnssec-lookaside auto;
> managed-keys-directory "/etc/namedb/working";
> 	In the actual zone, I have:
> zone "" {
> 	type master;
> file "/etc/namedb/dynamic/";
>    key-directory "/etc/namedb/dynamic/";
>    auto-dnssec maintain;
>             allow-update {
> key KEYNAME;
>  };
> #list of other DNS's that are not official slaves
> include "/etc/zoneconfigs/scnotify";
> 	notify yes;
>         allow-query { any; };
> };

Note that validation and signing are complementary functions and you
don't have to do both at the same time. I'd do one at a time, just to
limit the number of potential problems that hit at once.

> I see not one complaint but I know that only takes care of our
> zone signing.
> 	I did a dig on that box and looked up a host which
> worked but the results were identical to what one would have
> seen before any DNSSEC directives were added.
> 	Now for the dumb questions:
> 	Our chain of trust goes through Educause so I must get a
> signature from them and somehow, I send them a key, probably a
> ZSK that we then send them on a periodic basis as we also
> download their new key on a periodic basis.

No, you don't ever download their key. The only keys you would have to
download are those of the root zone and of the DLV. (That one will
probably go away before a new key is needed, though.) You don't need any
key from Educause or Verisign (which is manages .edu).

You do need to supply your KSK public key or it's DS (which is shorter)
to them.

> 	That part, I am still as confused as ever. The
> documentation I have found so far which one would hope would be
> almost a cook book set of instructions has been more like asking
> a passer-by on the street for the time and 18 hours later, he is
> still describing how he made watches before electronic ones came
> along. The theory is necessary, but this is a high priority
> project and folks all up and down the chain of command really
> wanted this done a long time ago but we first had to upgrade
> bind and the OS on our platforms so things got a bit behind.
> 	I think that where we are now is that we have taken care
> of the lookups for our zones and what is left is to secure the
> recursive lookups. On our site, recursive lookups are not
> allowed from outside our networks.
> 	Can we start signing our zones with the keys from
> dnssec-keygen without any fear of broken lookups for those who
> are not yet aware of dnssec?

Until you send you key (or DS) to be included in .edu, signing has no
effect unless you give your key(s) to people who installs it on their
servers. (You really should have a test system you can install this key
on to make sure it REALLY works.) You can also use
and to make sure that your stuff is correctly

Once you publish you KSK public key by putting it into .edu, validation
will start working (or not). "Not" is something you really want to

> 	Is there, somewhere, a linear description of this
> process that starts out like:
> 1.  Do this.
> and leading up to 
> x. Congratulations! you have dnssec working.
> None of these steps in the puzzle have been hard, so far, but
> for a totally externally-driven task, I just want to get it
> working.
> 	As a reminder, none of this is on our master DNS yet so
> we are still doing the normal activities. Our firewalls are
> supposed to be adjusted to allow the 4096-byte DNS packets in
> the next day or so so all the testing is being done on another
> box for now.
> Thanks for all the help from this list. I think we are more
> there than not, but we aren't home yet.

Go ahead and start signing your master data and making the signed data
available so you can test. Until the key is published, it has no
effect on the world at large but it allows you to test and be sure that
it really works and gives you a chance to fix problems before the
outside world can see them.
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

More information about the bind-users mailing list