> Actually they already did. OS X for instance has this baked into mDNSResponder.
That's not altogether true and now also irrelevant.
mDNSResponder has DNSSEC support that isn't quite baked and was not enabled by default. The only way to use the support it did provide was by passing specific flags to a relatively low-level API. (You'd have to configure the system to use a DNSSEC enabled resolver as well of course.)
mDNSResponder has been replaced by discoveryd which does not have any DNSSEC support (other than silently accepting the validate flags). Perhaps it'll gain further support in the future. If it does I'd not bet on it being enabled by default any time soon.
Fire up a terminal, run "tcpdump -s0 -i en0 udp", open Safari, resolve "www.enteract.com", and tell me if you see a full recursive DNS lookup happening, or if instead you see Safari's stub resolver asking the DHCP-configured DNS cache server for help over the insecure Internet.
This is like saying "everyone can just run their own DNS server". Of course, as I said, they won't. The fact that Apple has a DNSSEC-resolving recursive lookup server and Safari doesn't use it strengthens my point instead of weakening it.
Of course it does, Safari uses the resolver provided by OS X, which is mDNSResponder. (It superseded the stub resolver in libSystem.dylib starting with 10.6.)
How's that saying go about only proving the code correct, but not testing it? I think there's a reason tptacek specifically asked about tcpdump of on wire traffic.
Actually they already did. OS X for instance has this baked into mDNSResponder.