<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Clients need to send both cd=0 and cd=1 queries. The two types of queries address different failure scenarios. <div><div><br></div><div>I tried hard to prevent the stupid just send cd=1 advice before it was published. Years before there was a wish to reduce the amount of work a validating resolver does. There was bad advice from that and the WG chair refused to reopen the issue. </div><div><br></div><div>CD=1 addresses bad clocks and trust anchors in resolvers. CD=0 addresses bad authoritative servers and spoofed responses. You can start with either and try the other when validation fails. <br><div><div><br><div dir="ltr">-- <div>Mark Andrews</div></div><div dir="ltr"><br><blockquote type="cite">On 3 Dec 2023, at 12:31, Crist Clark <cjc+bind-users@pumpky.net> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto">Preface: Please don’t read any judgement of DNSSEC’s value into this question. Just looking for the opportunity to understand DNSSEC better from some world-class experts if any care to respond.</div><div dir="auto"><br></div><div dir="auto">When a client (or any DNS-speaker) is doing validation, doesn’t it set CD on queries through a forwarder? In that sense, the intermediate servers do not filter “bad answers.” Or is my understanding incorrect? Or do you mean the data that the forwarder is using internally has been filtered of bad answers?</div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 1, 2023 at 1:40 PM Mark Andrews <<a href="mailto:marka@isc.org">marka@isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="auto">A validating resolver is a prerequisite for validating clients to work. Clients don’t have direct access to the authoritative servers so the can’t retrieve good answers if the recursive servers don’t filter out the bad answers.<div><br></div><div>Think of a recursive server as a town water treatment plant. You could filter and treat at every house and sometimes you still do like boiling water for baby formula but on the most part what you get out of it is good enough for consumption as is. </div></div><div dir="auto"><div><br><div><br><div dir="ltr">-- <div>Mark Andrews</div></div><div dir="ltr"><br><blockquote type="cite">On 2 Dec 2023, at 08:14, John Thurston <<a href="mailto:john.thurston@alaska.gov" target="_blank">john.thurston@alaska.gov</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<p>At first glance, the concept of a validating resolver seemed like
a good idea. But in practice, it is turning out to be a hassle.</p>
<p>I'm starting to think, "If my clients want their answers
validated, they should do it." If they *really* care about the
quality of the answers they get, why should my clients be trusting
*me* to validate them?</p>
<p>Can someone make a good case to me for continuing to perform
DNSSEC validation on my central resolvers?<br>
</p>
<pre cols="72" style="font-family:monospace">--
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a href="mailto:John.Thurston@alaska.gov" target="_blank" style="font-family:monospace">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
<span>-- </span><br><span>Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list</span><br><span></span><br><span>ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" target="_blank">https://www.isc.org/contact/</a> for more information.</span><br><span></span><br><span></span><br><span>bind-users mailing list</span><br><span><a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a></span><br><span><a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a></span><br></div></blockquote></div></div></div>-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div></div>
</div></blockquote></div></div></div></div></body></html>