Stu Bailey, Infoblox’s CTO, forwarded me this article about a hidden feature in the latest builds of Googles Chrome browser. It allows users to configure Chrome to use a different set of name servers from those that their system uses. This might come in handy if, for example, your IT organization locks down the ability to modify your system resolver settings and you think you could get better performance from a closer/faster/shinier set of name servers than the ones IT provides. I think Googles ulterior motive for introducing the feature may have been to allow users whose default name servers perform NXDOMAIN redirection to configure Chrome to query the Google Public DNS servers, which notably don’t rewrite NXDOMAIN responses.
Regardless of motive, though, the new feature highlights an interesting possibility: of using application-specific resolver settings. This has been possible since the beginning of BIND: applications have always had the ability to tweak the resolvers configuration to suit their needs.That’s how some applications opted to use the search list (e.g., command-line SSH and FTP clients) while others insisted on the use of fully qualified domain names (e.g., mail user agents). And its how tools like dig and nslookup read the system resolver configuration from resolv.conf or the Windows Registry but still allow you to query any name server you specify, or turn recursion off, or change timeouts.
What tantalizes me is the possibility that an application will opt to do DNSSEC validation on its own. That’s quite possible, of course: In the CD, or Checking Disabled bit, DNSSEC provides the signaling necessary to allow an application to say, Don’t perform validation for me. Just pass along the DNSSEC resource records and I’ll do it myself. It’s then up to the application to validate the chain of trust from the answer its interested in to the nearest trust anchor. And with the recent (July 15) signing of the root zone, there’s only one trust anchor such an application would need to know in order to validate a large proportion of the signed Internet namespace: the roots zones public key-signing key.
Why would you ever want or need an application todo validation, instead of leaving it to the recursive name server your stub resolver queries? Well, most civilians have no control over that recursive name server and whether it performs validation. If your IT organization or ISP drags its feet and doesn’t bother to turn validation on, you just have to make do without it, right?
But most IT organizations and ISPs at the very least run name servers recent enough to understand the CD bit and pass through DNSSEC records, so you can offload the responsibility for validation onto an application. In fact, in this configuration the application would gain much better visibility into the nature of any validation failures that might occur. Particularly sensitive applications could demand the added security of a DNSSEC-validated answer.
It’s an interesting thought, anyway. Who knows? Maybe the next version of Chrome will support it.
