The KSK signs only DNSKEY records, and the ZSK signs all other relevant resource records in the zone. Your DNSSEC delegation comes from a DS record (a fingerprint of your KSK) which is included (and signed) in the delegating zone. The practical upshot of this is you can change your ZSK frequently without having to update the DS record upstream (thus contacting your delegator) every time you do so.

I'll add that it's a good idea to get low self-discharge batteries for a wireless mouse. I get a good three months between battery changes, and a spare set of standard NiMH battery could be dead by then.

http://en.wikipedia.org/wiki/Low_self-discharge_NiMH_battery

Well, you're half right.

DNSSEC's original form allowed for unrestricted zone walking via querying for non-existent domains and receiving an answer containing the RRs appearing just before and after the non-existent domain. This was a major stopping point for widespread implementation. RFC 5155 and NSEC3 addresses this by using hashes of domains instead of domains themselves.

As for the certificates, you do not need to buy a certificate from VeriSign to sign your DNS data. You generate your own keys and provide a key fingerprint to whomever is delegating your domain to you. Queriers can use that fingerprint to validate the DNSKEYs you present for their use in validating your signed records.

Signed zone data is not reliant on x509 certificates; algorithms defined in RFC 4034 are RSA/MD5, Diffie-Hellman, DSA/SHA-1, Elliptic Curve, RSA/SHA-1, and room for ~245 future algorithms. There is no identity information stored in the keys used for DNSSEC, so you should be able to generate the keys yourself.

http://tools.ietf.org/html/rfc5155

about:config

browser.identity.ssl_domain_display

Set it to 2 to see the Common Name of the cert in the address bar. Very helpful to see side-by-side with the URL. EV certs will still show the Organization and Country, but it makes non-EV certs a little more obvious.