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.

Read more...

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.

Read more...

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.

Read more...