March 11 2010 by 
Cricket Liu (Infoblox)
If you're interested in the slides from the recent Infoblox/F5 DNSSEC webinar with Dan Kaminsky, Nate Meyer and Scott Rose, they're available here. Thanks to everyone who listened in!
PS
If you're having trouble with the link above, here's a PDF of the slides.
Posted in DNSSEC | DNS Security | 
5 comments
February 27 2010 by Cricket Liu (Infoblox)
With the recent announcement that OpenDNS will support DNSCurve, I've begun hearing more questions about it. In particular, people wonder whether DNSCurve is a viable alternative to DNSSEC. They've generally heard that DNSCurve is simpler to set up than DNSSEC and involves less overhead.
Unfortunately, DNSCurve isn't an alternative to DNSSEC - although it could conceivably complement DNSSEC, in ways I'll discuss.
Posted in DNSSEC | DNS Security | 17 comments
February 11 2010 by Cricket Liu (Infoblox)
I feel like at least half of my postings to this blog have been about DNSSEC (and for those of you uninterested in DNSSEC, I'm sorry). But one DNSSEC-related topic I haven't brought up is the "last mile."
In DNSSEC, the "last mile" refers to communications between the stub resolver and the recursive name server. The stub resolver is the piece of the Domain Name System that resides on nearly every computer and translates an application's request for data (say the address of www.infoblox.com) into a DNS query, and then sends that query to one or more name servers. The recursive name server receives a resolver's query, examines its cache for the answer, and if it doesn't find the answer there, may need to send one or more queries to remote name servers.
Posted in DNSSEC | DNS Security | 2 comments
February 01 2010 by Cricket Liu (Infoblox)
Last time, I compared the number and size of the response messages involved in resolving a record in an unsigned zone to those involved in resolving a record in a signed zone under a signed TLD. This time, I want to look at the actual computation involved.
This isn't really a comparison, of course, because in the case of an unsigned zone, there's no heavy computing involved: The name server simply reads responses from the network and unmarshals their content into discrete resource records--simple! In the case of a signed zone under a signed TLD, there's lots of work to do.
Posted in DNSSEC | 6 comments
January 14 2010 by Cricket Liu (Infoblox)
I realized last week that I'd never actually traced all the queries sent and responses received by a recursive name server resolving a domain name in a zone signed with DNSSEC. I decided to trace the recursive resolution of an RRset in a signed top-level domain, since I wanted to see the "chain of trust" in action. I knew .org was signed and figured isc.org (the Internet Systems Consortium's domain) would probably already have a DS (Delegation Signer) record.
Posted in DNSSEC | BIND | 13 comments