<div dir="ltr"><div dir="ltr">On Wed, Jul 19, 2023 at 3:28 AM Shane Kerr <<a href="mailto:shane@time-travellers.org">shane@time-travellers.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Shumon and all,<br>
<br>
On 18/07/2023 21.41, Shumon Huque wrote:<br>
> On Tue, Jul 18, 2023 at 3:29 PM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org" target="_blank">ietf-dane@dukhovni.org</a> <br>
> <mailto:<a href="mailto:ietf-dane@dukhovni.org" target="_blank">ietf-dane@dukhovni.org</a>>> wrote: <br>
> <br>
> Yes, I agree. A resolver can't really tell that a response with an <br>
> expired signature wasn't an attacker trying to replay old data. For <br>
> robustness against attacks, it must re-query other available other <br>
> servers if they exist.<br>
<br>
I kind of think that a resolver using UDP should just drop a response on <br>
the floor if it has an expired signature. Otherwise an attacker can <br>
induce behavior change by spoofing replies, which is itself a security <br>
problem (in this case, blocking with a response that would arrive later <br>
and work, effectively removing a name server from the set of name <br>
servers queried for a given lookup).<br></blockquote><div><br></div>The problem is that in the general case the resolver can't really tell if</div><div class="gmail_quote">this was an attack or a misconfiguration. So, it's best to build in robust</div><div class="gmail_quote">behavior to deal with the case more generally. Which in my opinion is</div><div class="gmail_quote">"drop the response on the floor, maybe blacklist the server for a while,</div><div class="gmail_quote">and retry the next server". If a later valid response does come, then be</div><div class="gmail_quote">prepared to accept it (if you've still held on to the query).<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This idea mostly applies to UDP without DNS cookies since it is the only <br>
transport easily vulnerable to spoofing. With other transports you are <br>
much more sure that the answer actually came from the server you are <br>
querying, and so you can be confident that the server is giving out <br>
bogus answers. (TCP is vulnerable to BGP hijacking and the like, but in <br>
that case you would still expect to get bogus answers for subsequent <br>
queries to the same server.)<br></blockquote><div><br></div><div>Well, there are inline attackers as well and DNSSEC is designed to protect</div><div>against those too. If this only applied to UDP, then other protocols that use</div><div>connection oriented transport or session oriented frameworks on top of UDP</div><div>would not bother with cryptographic authentication either. And yet, they all</div><div>do.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Unfortunately I don't think any resolvers hold onto a UDP query until <br>
after the DNSSEC validation. So there is not really much option other <br>
than to try again. 🤓<br></blockquote><div><br></div><div>Yeah, but I don't really see that as a problem. I see concerns have been</div><div>raised in this thread about the NXNAME attack and such dissuading <br></div><div>resolver implementers from more retries, but in my view the only thing</div><div>that taught us is that resolver implementers need to go back to first</div><div>principles and sensibly bound the amount of work they are willing to do,</div><div>not eliminate retries.<br></div><div><br></div><div>To quote RFC 1034 (published in 1987):<br><br>"The recommended priorities for the resolver designer are:<br><br> 1. Bound the amount of work (packets sent, parallel processes<br> started) so that a request can't get into an infinite loop or<br> start off a chain reaction of requests or queries with other<br> implementations EVEN IF SOMEONE HAS INCORRECTLY</div><div> CONFIGURED SOME DATA."</div><div><br></div><div>Note: the capitalized phrase for emphasis.</div><div><br></div><div>(My addendum: they should also bound the time spent.)</div><div><br></div><div>Transient configuration problems are _pervasive_ in deployed DNS</div><div>infrastructure. If BIND for example did not have the robust retry</div><div>behavior that Mark Andrews documented upthread, we could never</div><div>have used them in our infrastructure. In my experience Unbound also</div><div>had the same robustness, but I'm now a little concerned by the description</div><div>of the Unbound failures reported by Gavin M during this Verisign incident.</div><div>Maybe they have limited retries too aggressively? It would be good to <br></div><div>get some NLnetLabs colleagues to chime in with a description of their</div><div>behavior.<br></div><div><br></div><div>Shumon.</div><div><br></div></div></div>