Notes on working with BIND v9:

 RNDC: Making the damned this work!
 ----------------------------------

	First off, it won't work untill you fix /etc/rndc.conf,
make some changes to /etc/named.conf, and stop/restart named.
Only then will it work.  You'll know its working because you'll
see the following startup message:

	command channel listening on 127.0.0.1#953

First, here's what /etc/rndc.conf looks like:
-----------------------------------------------------------
key rndc_key {
        algorithm "hmac-md5";
        secret "nCzkGvxO65EHAoi9kpn5ww==";
};

options {
        default-server localhost;
        default-key rndc_key;
};

server localhost {
        key     rndc_key;
};
----------------------------------------------------------

	This is fairly self explanitory.  The only 
foggy point is the hmac-md5 secret creation.  To create
it move to a temp directory and run the following:

   /usr/local/sbin/dnssec-keygen -a hmac-md5 -b 128 -n user rndc

This'll output two files named: "Krndc.+157+33861.key" and 
"Krndc.+157+33861.private", or something along thoughs lines.
The secrets are the same in both files, simply cut-and-paste
the secret into the secret line of the key statement.  Once
that is done you can wack the two key files.

	Next, you need to mod /etc/named.conf.  Add the following:
-----------------------------------------------------------------
key rndc_key {
        algorithm "hmac-md5";
        secret "nCzkGvxO65EHAoi9kpn5ww==";
};

controls {
        inet 127.0.0.1 allow { localhost; } keys { rndc_key; };
};

acl localhost { 127.0.0.1; };
-----------------------------------------------------------------

	Notices that the "key" section is straight outta /etc/rndc.conf.
The "controls" section will contian the IP address, and allow is the 
defines ACL for access.  That, therefore requires an ACL.... duh.
Obviously, when defining "keys" you need to point to the key name.

	The changes in /etc/rndc.conf make alot of sense.  Obviously,
to control the nameserver you'll need a key (check), you'll need to 
define what nameserver your going to talk to and which key you'll use 
for it. (check)  Now, the optional part is in specifying multiple servers to
work with.  For each server you would add a new "server" section.
In our previous example it could have been omitted.  You can go the other
way too, to exclude the "options" section and rely on the server clause only, 
but since you hadn't defined a "default-server" you'd have to use rndc with 
a "-s server" option every time.  It's best to just spec a default server,
and defining the server in its own section is just good habit. 

	Here is another RNDC setup on a diffret machine:
-------------------/etc/rndc.conf-----------------------------
key rndc_key {
        algorithm "hmac-md5";
        secret "QrXc3DTpzUVf80Y1YAj7NQ==";
};

options {
        default-server 10.0.0.1;
        default-key rndc_key;
};
---------------------------------------------------------------
 ...and...
------------------/etc/named.conf------------------------------
acl localhost { 127.0.0.1; };

options {
        directory "/etc/namedb";
        pid-file "named.pid";
};

//----------RNDC STUFF----------

// Control Statements for RNDC Control
controls {
        inet 10.0.0.1 allow { localhost; } keys { rndc_key; };
};

// Key for RNDC
key rndc_key {
        algorithm "hmac-md5";
        secret "QrXc3DTpzUVf80Y1YAj7NQ==";
};

//------------RNDC STUFF---------

// Root server hints
zone "." {
        type hint;
        file "db.cache";
};

// Reverse Mapping
zone "0.0.127.in-addr.arpa" {
        type master;
        file "db.127.0.0";
        notify no;
};

zone "cuddletech.com" {
        type master;
        file "db.cuddletech";
};
--------------------------------------------------------------


	Notice in the second case outlined, I've omited the 
"server" statement from /etc/rndc.conf.  This was because I 
didn't want to use loopback, and I'm not sure how the rndc.conf
file resolves names, so I wanted to spec an IP.  Unfortuntely,
the "default-server" statement will except an IP, while the
"server" statement will not.
	Next we see a change of the "inet" clause in the controls
statement of /etc/named.conf.  This is what places the RNDC server,
so instead of being on 127.0.0.1, like before, it now sits on 10.0.0.1.
	BTW, testing shows that the "allow-query" option has NO effect
of the RNDC setup.
	
	On the issue of "how she resolves names".  I'd imagine
via DNS itself.  Note that "localhost" is a special case, handled
by the loopback map.  "localhost" is damned near idiot proof.  However
to use a non-"localhost" server statement I'm thinking that you
can't use the alias, but must use the real name.  <shrug>

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 RNDC: Network Management.

	To raise the bar abit, you might wanna access
rndc remotely.  To do this you need to do the following:
	a) Edit the client side /etc/rndc.conf file.
	b) Check perms in server side /etc/named.conf control statement.

First, make sure that in your /etc/named.conf's "control" statement 
that the "allow" allows the client.  If it does, then your done on the
server.  If your not, check the acl's.  Also, FYI, make sure that you
aren't serving RNDC on the localhost, but on an actual interface,
as noted earlier.

Now, on the client, add lines similar to these:
----------------------------------------------
//Nexus6 RNDC Control
key rndc_key {
        algorithm "hmac-md5";
        secret "QrXc3DTpzUVf80Y1YAj7NQ==";
};


server nexus6 {
        key     rndc_key;
};
---------------------------------------------

I've found that the name of the key IS significant.  If you created
the key as "..keygen... -n user rndc" then you need to call the key 
"rndc_key", if you called it "nexus6" then its "nexus6_key".  Failure
to follow this guideline will get you a message like this:

bash-2.02# rndc -s nexus6 stats
rndc: send remote authenticator: permission denied
bash-2.02# 
____________________________________________________________________________
!!!NOTE: Therefore, always give your keys significant names, not generic.!!!
----------------------------------------------------------------------------

	You can see from the above example syntax that accessing
a remote server via rndc requires a "-s server" each time you make
a request.  The servername must be resolvable via DNS before trying any
of this.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Add:
	-Signing Zones
	-DNSSEC
	-More enc stuff....


Signing Zones:

1) Create two keys for the zone
dnssec-keygen -a RSA -b 1024 -n ZONE cuddletech.com
dnssec-keygen -a RSA -b 1024 -n ZONE cuddletech.com
2) Create a keyset from thoughs
dnssec-makekeyset -t 3600 Kcuddletech.com.+001+34959 Kcuddletech.com.+001+39233
3) Sign the key
dnssec-signkey keyset-cuddletech.com. Kcuddletech.com.+001+34959 Kcuddletech.com.+001+39233
4) Add the keys to the Zone file, AFTER the $TTL is defined.
$INCLUDE Kcuddletech.com.+001+34959.key
$INCLUDE Kcuddletech.com.+001+39233.key
5) Sign the zone
dnssec-signzone -o cuddletech.com db.cuddletech 
 [ -o zonename, this is the name that is listed in the SOA]
6) Modify the named.conf for the zone,
from db.cuddletech to db.cuddletech.signed
 
Done.