BIND

Compiling and installing BIND
=============================

Download the latest version of BIND from http://www.isc.org

Download and install the latest version of openssl too.

Extract the source to bind.

$ ./configure --with-openssl

(you may have to specify --with-openssl=/PATH if configure can't find it)

$ make

$ sudo make install

TSIG - RFC 2845
====
TSIG can be used to authenticate requests sent to a nameserver.
Generally, the type of requests that one would like to authenticate
would be:
-DNS dynamic updates
-zone transfers
-even queries

First, generate a keypair.

# dnssec-keygen -a HMAC-MD5 -b 256 -n HOST dynupdates

This will generate two files (which contain exactly the
same information, in different formats). The two files
generated were:
----------
Kdynupdates.+157+43213.key
Kdynupdates.+157+43213.private
----------

Now, add the following stanza to the named.conf (the key
portion can be found in either of the files that were
generated by the dnssec-keygen.

key dynupdates. {
  algorithm hmac-md5;
  secret "4+qC7mgcQwmp0nicty/EKP5pX1QFn5/MJ5h5w4bKzEU=";
};

Then add in the following in the zone stanza:
allow-update { key dynupdates. ; };

*** hmmm, here is where it gets a little weird ***
It errors saying that it can't open the key file, but a truss
shows that its actually trying to lookup a different name.
The solution was to renamed the .key and .private files to have
"00000" after the second "+" in the name.

For example, given the files generated above, I had to do:
# mv Kdynupdates.+157+43213.key Kdynupdates.+157+00000.key
# mv Kdynupdates.+157+43213.private Kdynupdates.+157+00000.private

Now when you run the nsupdate command, use the -k option to
tell nsupdate to authenticate itself using the key in the
file.

$ nsupdate -k /var/named:dynupdates. /tmp/data

Where /tmp/data contains:

--------------------
update add testing.vmprivate.com. 86400 in a 10.10.10.10

--------------------

DNSSEC
========

Pre-requisites
--------------
You need to understand public/private key cryptography.
You really need to have BIND 9 or later.

Why?
----
So that people don't spoof your domain and redirect traffic (web, mail, etc)
to the wrong location. They could also launch DOS attacks by returning
NXDOMAIN for any requests.

How?
----
First, generate a key-pair (Don't use DSA - there are compatibility issues):
# /usr/local/sbin/dnssec-keygen -a RSA -b 512 -n ZONE \
	-r /dev/dsk/c0t0d0s0 unixpeople.com

If you don't specify the random device or if there is insufficient data
in the random device, you will be prompted to type a bunch of characters
in order to generate randomness..... This is a real pain.

This command will generate 2 files:
------------------
Kunixpeople.com.+003+29874.key
Kunixpeople.com.+003+29874.private
------------------

Add the public part of the key to the zone file
------------------
$INCLUDE Kunixpeople.com.+003+29874.key
------------------

Sign the zone file
------------------------
# /usr/local/sbin/dnssec-signzone -o unixpeople.com -p db.unixpeople
------------------------

This will produce a file called db.unixpeople.signed.

Now update the named.conf to load the signed file. Don't ever make changes
to the signed file - make changes to the original file, then re-sign it.

Remember to check the /var/adm/messages file for any errors
-----------------------------------------------------------
The server used to return SIG and NXT RRs with any query, but
apparently, that confused some older servers, so now the RRs
are only returned if it is requested by the resolver.
We can ask dig to request the RRs by using:

$ dig +adflag @woody.unixpeople.com www.unixpeople.com in a

-------------------------------------------------------------

What happens now?
------------------
A digital signature (SIG) is generated for every RRSet in your zone file.
Also a NXT RR is generated for every RRSet in your zone file. 

Weaknesses/Negatives
---------------------
1) Some older servers freak-out when attempting to perform a zone
transfer of a signed zone. For example, my BIND 9.1.3 works fine with
a signed zone, but one of my secondary's was running BIND 8.2.3 and it
would fail to load the zone. 8.2.4 loads ok.
2) There are no known weaknesses with DNSSEC. In future, we could
expect that any weaknesses discoverred in the public/private cryptography
arena would apply to the DNSSEC solution.
3) The signatures that are generated, eventually expire (by default, they
expire after 30 days). This means that the zone(s) must be re-signed
periodically. One possible method of re-signing the zone is:
-stop the nameserver (to be sure the zone is quiescent - if dynamic updates)
-bump the serial number in the unsigned file
-re-sign the zone
-re-start the name-server.
4) For a server to be able to validate your signed responses, that server
would have to have a copy of your public key. The proof of this next statement
is left to the student, but its true. 
The parent zone would need to have the public key for each of its children.
It would then need to distribute its children's key signed with the parents
key. Just as delegation works, so would this. 
5) Adoption will be slow because it requires a relatively knew DNS server,
and because microsoft does not support it yet. In addition, if people return
unsigned results, at what point in time will be actually stop accepting
these?. 
6) Clients don't generally do validation of DNSsec. They expect their
local name server to do it. Thats ok, but it is a potential weakness. 

What is missing from DNSSEC?
----------------------------
The only thing that is really missing is the for the root-servers to generate
keys and sign the root zone. In addition, the registrars would have to
start accepting KEYs from second-level zones (in some secure way of course).

Why is it not widely deployed?
------------------------------
I think everyone is just waiting for the root servers to sign their zones.