According to Wired, Symbolics.COM was registered on March 15, 1985.  Symbolics.COM was the very first subdomain of COM, making today the silver anniversary of, well, something.  The first delegation from .COM, I guess.  Since then, there have been tens of millions more, of course, so the very firstought to be significant.

I had the privilege of managing the 9th-oldest subdomain of .COM, HP.COM, for several years back in the late 1980s and early 1990s.  That job set me on the path I've been on for the last twenty-something years, and for that I'm very grateful.

What else has happened during those 25 years?  Countless versions of the BIND name server were released, from BIND 4.8 to the current 9.7.0.  For that, we owe the Internet Systems Consortium an enormous debt of gratitude.  BIND still powers, by our last measure, almost 75% of the authoritative name servers serving subzones of .COM, .NET and .ORG.  Commercial ventures with that kind of market share make people rich; the folks at ISC chose instead to pursue the nobler goal of producing the reference implementation of the Domain Name System, thereby facilitating the remarkable growth and success of the Internet.

Read more...

Read more...

Read more...

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...