[rescue] Fixed: BIND 9 rndc hints

[Loomis, Rip]

Here's what I *really* should have posted, with
all the fixes:
  - Put "key" before "controls" or "options" stanza
  - Ensure that the "secret" line is the same in both
	named.conf and rndc.conf (duh.)
  - Check for all the silly little semicolons
  - etc.

Note that when using Base64-encoded keying material like
this, watch out for dropped characters when cutting and
pasting.  A single dropped character (such as the missing
"I" in rndc.conf in the first version I posted) will cause
weird errors when rndc or named tries to decode the string...
but the string itself may look fine to the naked eye.
That's what caused the error that Bill was still seeing.

So does anyone still want to try to get rndc working?
Sheesh.  It *is* a little painful.

  --Rip

=-=-=-=-=
3.1	Create a configuration file for rndc to hold the required,
shared secret key.  The default location for the rndc configuration
file is /etc/rndc.conf (or /usr/local/etc/rndc.conf depending
on the options passed to configure)

A sample minimal rndc configuration file is as follows:
  key rndc_key {
    algorithm "hmac-md5";
    secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9y          
        IGEgd29tYW4K";
  };
  options {
    default-server localhost;
    default-key rndc_key;
  };

3.2	Modify the named.conf file to use the shared secret key, by
adding a new "control" directive.
  key rndc_key {
    algorithm "hmac-md5";
    secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9y          
        IGEgd29tYW4K";
  };
  controls {
    inet 127.0.0.1 allow { localhost; } keys { rndc key; };
  };


3.3	Note that the configuration files above will work verbatim
for initial testing, but that the secret keys listed in those files
should not be used on production systems.  New HMAC-MD5 secrets
should be generated for rndc on each DNS server system using
dnssec-keygen.  Note that since all you're using from the files
generated by dnssec-keygen (*.key and *.private files) is
the "raw" key string, you don't really need to worry about what
"entity name" you provide with the -n option to dnssec-keygen.

  ns1# dnssec-keygen -a hmac-md5 -b 128 -n HOST mytestkey
  ns1# start typing: [[TYPE AS REQUIRED UNTIL TOLD TO STOP]]
  ns1# stop typing.
  ns1# Kmytestkey.+157+NNNNN
  ** Adding dot to the name to make it fully qualified domain name**
  Generating 128 bit HMAC-MD5 Key for mytestkey.
 
  Generated 128 bit Key for mytestkey. id=0 alg=157 flags=513

  ns1#

For the example above, the file Kmytestkey.+157+NNNNN.key contains 

  mytestkey. IN KEY 512 3 157 MLenGxvcv1ClOvZ73JtZMg==

of which the last section ( MLenGxvcv1ClOvZ73JtZMg== ) is the actual
TSIG secret key.  Note that all of the key is important, including
any trailing "=" equal signs (which are used to pad the string for
Base64 encoding.)

3.4   If you're going to include the shared secret key in
	named.conf, and there are non-trusted users on
	the local system, make sure named.conf has restricted
	permissions.  Alternatively, you can put the key
	string in a separate file and $INCLUDE it.  For the setup above
	in 3.1/3.2, an "rndc.key" file could be created as follows:

  key rndc_key {
    algorithm "hmac-md5";
    secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9y          
        IGEgd29tYW4K";
  };

      and that file could then be $INCLUDE-d in both named.conf and
	rndc.conf.

=-=-=-=-=