Re: Short-sighted much?
DNSSEC isn't encryption, at least not in the same way as TLS/SSL. It does increase zone storage sizes and yes, on a busy server it will increase load due to the larger responses, but the mechanism is in the clear just as with normal DNS. What DNSSEC does is returns extra resource records such as RRSIG to clients requesting DNSSEC (dig flag +dnssec and you might want to add +multi to that to make it readable. You'll be wanting to query a DNSSEC aware resolver). Unless you're adding or removing RRs continuously, your extra workload as a sysadmin is restricted to effecting and keeping records of key rollovers. Changing the zone data between rollovers just requires re-signing the zone with the same keys and specifying the end date.
A zone is still static in whatever backend storage method you use and the data is still requested and transferred over port 53 in the clear, so the cost of crypto argument is moot. Bandwidth, however, will increase. This is unavoidable.
As for "it's working well enough," you know it isn't. There are umpteen different ways an attacker or a badly configured resolver can inject or introduce false information into a DNS transaction with no way, until DNSSEC came along, for the client to verify the authenticity of the information it receives as the DNS is insecure by design and is about ten years overdue for a good coat of looking at.
Example of a DNSSEC transaction:
; <<>> DiG 9.4.2-P1 <<>> nlnetlabs.nl +dnssec +multi
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49907
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 3
[ The "ad" flag means DNSSEC has been requested and the response has been verified as trusted. Which it should be as nlnetlabs.nl is one of my trust-anchors. ]
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
[ Note the EDNS, or Extension Mechanisms for DNS, defined by RFC 2671. This allows a UDP reply to be longer than 500 bytes (in this case 4kB) and is essential for DNSSEC ]
;; QUESTION SECTION:
;nlnetlabs.nl. IN A
;; ANSWER SECTION:
nlnetlabs.nl. 3600 IN A 220.127.116.11
[ Standard A record you would expect in any DNS transaction for a simple forward lookup ]
nlnetlabs.nl. 3600 IN RRSIG A 5 2 10200 20081129015003 (
[ This is the new boy. RRSIG is the result of signing the A record with the ZSK, which in turn is signed with the KSK, the public key of which is known to either the parent zone, a DLV registry or added to a client as a trust anchor, which then allows the client to make a decision on whether it trusts the reply based on "trust anchors" containing SEPs (secure entry points: This is usually the public KSK of whatever zone you use as the trust anchor) of known good zones. None of this is done "on the fly." It's all static in the authoritative server's backend and can be safely cached for the length of the TTL. The only crypto involved is on the client side while verifying the RRSIGs. All of the necessary public keys are published in the zone itself. ]
20081101015003 18182 nlnetlabs.nl.
;; AUTHORITY SECTION:
nlnetlabs.nl. 7200 IN NS ns7.domain-registry.nl.
nlnetlabs.nl. 7200 IN NS open.nlnetlabs.nl.
nlnetlabs.nl. 7200 IN NS omval.tednet.nl.
nlnetlabs.nl. 10200 IN RRSIG NS 5 2 10200 20081129015003 (
20081101015003 18182 nlnetlabs.nl.
;; ADDITIONAL SECTION:
open.nlnetlabs.nl. 7200 IN A 18.104.22.168
open.nlnetlabs.nl. 10200 IN RRSIG A 5 3 10200 20081129015004 (
20081101015004 18182 nlnetlabs.nl.