Wed, 01 Jun 2011
As you all probably know by know, DNSSEC has been enabled on the root ('.') since July 2010.
And on most TLDs like .com shortly thereafter (in the specific case of .com, since March 2011).
The Debian guide to turning on DNSSEC is useful but some things you need to know (after using it for a week or so).
If you have 'listen-on-v6', set to yes and you roam to a non-IPv6 network. Your name resolutions can take 30+ seconds.
Since I roam from a some networks they do have IP6 and some that do not, I have had to turn this setting off to achieve reasonable performance
My use case is simple – if a bit geeky – use the local resolver on my system irregardless of what I get dynamically (via DHCP) or automagically (via SLAAC).
I can do this manually for each network I connect to, but it quickly looses its appeal.
Apart from the happy DNSSEC campers, very little takes advantage of DNSSEC yet.
Kind of like the early days of IP6. It would be nicer if websites stored the fingerprint of the SSL website in DNS and it could be cross-checked against what was sent.
The effort to do so is underway at the IETF by the name of DANE.
In fact publishing SSH key fingerprints via DNS is already possible RFC4255 but I am unaware of deployed support.
Things are progressing, and I suspect now is a great moment to get involved if you have spare time, in making it significantly harder for 3rd-parties to censor the Internet for everyone.
ॐ (aum) - what was, what is and what will be, wildfire's musings
Subscribe to a syndicated feed of my weblog, brought to you by the wonders of Atom.
Rendered in only 0.1127 seconds.