This whole thread is really kind of hurting my feelings.

Google has not correctly implemented DNSSEC. If you send them a normal DNS query and the response is not validly signed, they just pass the answer back to you without any indication that it's invalid. They only tell you that the answer failed to validate if you set the DO ("dnssec okay") or AD ("authentic data") bits in your query, which almost no DNS clients currently do.

If the answer is invalid, a validating name server is supposed to respond with SERVFAIL, so that even if the client doesn't know anything about DNS security, it will still be protected against spoofing. Google is claiming to provide protection against spoofing, and then they aren't providing *any protection at all*.

If you want DNSSEC protection, you're still going to have to run a validating name server yourself: either BIND 9 or Unbound. (Disclosure: I'm a BIND 9 author.) It is, nowadays, extremely easy to configure a validating name server using BIND 9; in any version since 9.8.0, a one-line named.conf will do it:

options { dnssec-validation auto; };

Run named with that configuration and "nameserver 127.0.0.1" in resolv.conf and you're good to go. Google public DNS is not ready to trust yet.

In fact, you don't need a dynamic DNS provider at all. My home router (a Netgear WNDR3700, costs about $85) is running CeroWRT, which includes BIND 9, which takes care of dynamic DNS by itself. It also does DNSSEC validation, and serves a dozen or so DNSSEC-signed domains. It's also my web server, IPv6 tunnel endpoint, shell server, and a passel of other things. Current uptime 224 days. Consumer router hardware can do a lot these days.

(Full disclosure: I'm a BIND 9 author and helped with the CeroWRT port.)

'Cause I wouldn't have been able to resist the temptation to name it "Amazon Prime".

I totally recognize that this is a stupid reaction, but if service #1 costs X dollars and service #2 costs Y dollars, I want a little lagniappe if I purchase both--the bundle of services #1 and #2 should cost an amount less than X+Y.

If they'd announced that streaming was $9 and DVD's were $9 and the combination would be discounted to only $16, I would have been sad about the price increase but a lot less irked, even though it still would've been $16. At least it isn't $18, I'd think, and I'd pay up. But they made each service $8, and didn't discount the bundle at all, and so it grates on me.

Marketing fail on their part. Rationality fail on mine.

That's not correct. The locking bug had already been fixed in 9.7.3b1, a month before it was found to be exploitable as a DoS. When we did find that out, we consulted with vendors and decided to continue with the releases in progress.

Those of us who are a certain age and were geeky enough to read Danny Dunn books know exactly where the CIA got this idea.

(Luckily Danny was able to destroy Professor Bullfinch's notes so the CIA wouldn't be able to replicate the much better dragonfly he'd invented, so they had to fall back on tiny, impractical gasoline engines instead.)

A friend of mine said to me a while back: "I've decided I'm going to skip Facebook, and then skip the thing that comes after Facebook, and join the one that comes after that."

There is much wisdom in her plan.

Whoops, I meant "nonreusable", sorry. (Though I believe they're also planning to make the Falcon recoverable and reusable eventually.)

Actually, the Falcon 9, unlike most reusable boosters, was designed in advance to carry humans. It meets all of NASA's requirements for a human-rated vehicle except for an escape system. SpaceX has stated their intention to dot that final i within a couple of years. The Dragon spacecraft they're designing for the Falcon 9 will support a crew of 7.

DNSSEC and DNSCurve solve two different (though overlapping) problems. DNSSEC is about end-to-end authentication and validation: It strives to ensure that the data you received is the data the actual owner of a name server intended to send, unaltered by anyone along the way. DNSCurve is about ensuring a trustworthy connection between the authoritative name server and the resolver (and incidentally about encrypting queries, which is nice), but it doesn't do a thing to keep the resolver from lying to you. Man in the middle is a problem with DNS, as anyone who stays in hotels frequently can attest.

As for set-it-and-forget-it, if you use BIND 9.7 (on which, full disclosure, I was the lead engineer), it comes pretty close. If you don't roll keys, it can maintain itself forever, and you can roll ZSK's with a cron job. Rolling KSK's still requires operator intervention in most cases. (But rolling keys is optional; people with higher security needs will want to do it often, but low-value targets can get away with doing it infrequently or never.)

Thank you very much for looking at the code. If you could send critiques like that to the developer list instead of posting them to slashdot, it'd have a better chance of getting attention from the other developers.

Actually the bit you're looking at is libdns, which we're trying to design in such a way that it can be used by other DNS-aware applications, not just BIND. (I happen to agree with several of your other points, though, and there are places outside libdns where the pimpl thing was used and maybe shouldn't have been.)

Try it some time! It's fun! I can even refer you to an ongoing open-source project that you can contribute to, if you like! :)

To give a rough idea of scale, BIND 9 has about half a million lines of C code, and the first release took a couple of years to write.

(BIND 10, in its current minimal and unfinished state, is about 40,000 lines of C++, and 10,000 lines of python.)

Wined and dined.

We wrote lots of tests. (How else would we know it has bugs in it?) This is a somewhat fair criticism of BIND 9, but read the link before you assume we didn't learn any lessons from the past. The unit tests are included in the tarball and coverage results are viewable online.