Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As the title says.

The design of DNSSEC and its implementation in Bind (and things like Unbound) quite clearly allow for either use. They can optionally do DNSSEC validation, returning SERVFAIL if the validation fails. Or alternatively they can be set to "support" DNSSEC but not to do the actual validation, allowing client software to use the "DO" bit (with EDNS) to request the DNSSEC records and do validation itself.

Notably, Google's own public DNS servers seem to follow the latter, allowing DNSSEC requests to pass through them but not doing DNSSEC validation themselves.

Which of these two ways was DNSSEC envisioned to be run? If you want context, imagine you have a few small web application servers and a caching recursive DNS server for them to do DNS requests through.

share|improve this question
up vote 1 down vote accepted

I don't know about "envisioned"; probably time will tell what works best.

But if you already have a caching server, I'l let that do the verification. The main reason: you then have one place where you can log verification failures (and maybe, if necessary, configure exceptions – when a site you have to reach has broken DNSSEC records).

Doing that on a multitude of clients doesn't scale.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.