<div dir="ltr"><div>Evening!</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">I don’t think this is true otherwise all resolver implementations would<br>have been affected and not just a few. If you are on path direct behind<br>the resolver of course all bets are off, but if you are on path just<br>between the resolver and the forwarder those resolvers that are more<br>cautious in what cache information they use for iterative queries are not<br>vulnerable.<br></blockquote><div><br></div><div>DoT could work if the attacker is between the server and the resolver.</div><div>However, if the attacker controls the target server, DoT just fails.</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">I guess that is why Akamai Cacheserve, NLNet Labs Unbound and PowerDNS<br>Recursor are not mentioned in the paper because they were not vulnerable.<br></blockquote><div><br></div><div>Sorry. Those software is not affected because they implemented</div><div>the bailiwick checking well as we explained in our paper instead of what you said</div><div> that they used DoT. That's what we found by performing our analysis and testing.</div><div>We also tested Akamai Cacheserver after Akamai researchers reached out to us.</div><div>Both their immune implementations and DNSSEC protected them well.</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">I agree that DNSSEC can fully mitigate it and should be used. Any<br>encrypted transport to a forwarder also would work, but IMHO it probably<br>would be better to not use forwarding at all.<br></blockquote><div><br></div><div>Yes. DNSSEC will work.  </div><div> </div><div>Best,</div><div>Xiang</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 27, 2023 at 3:39 PM Ralf Weber <<a href="mailto:dns@fl1ger.de">dns@fl1ger.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Moin!<br>
<br>
On 27 Sep 2023, at 3:58, Xiang Li wrote:<br>
<br>
> Hi Stephane,<br>
><br>
> This is Xiang, the author of this paper.<br>
><br>
> For the off-path attack, DoT can protect the CDNS from being poisoned.<br>
> For the on-path attack, since the forwarding query is sent to the<br>
> attacker's server, only DNSSEC can mitigate the MaginotDNS.<br>
<br>
I don’t think this is true otherwise all resolver implementations would<br>
have been affected and not just a few. If you are on path direct behind<br>
the resolver of course all bets are off, but if you are on path just<br>
between the resolver and the forwarder those resolvers that are more<br>
cautious in what cache information they use for iterative queries are not<br>
vulnerable.<br>
<br>
I guess that is why Akamai Cacheserve, NLNet Labs Unbound and PowerDNS<br>
Recursor are not mentioned in the paper because they were not vulnerable.<br>
<br>
I agree that DNSSEC can fully mitigate it and should be used. Any<br>
encrypted transport to a forwarder also would work, but IMHO it probably<br>
would be better to not use forwarding at all.<br>
<br>
So long<br>
-Ralf<br>
——-<br>
Ralf Weber<br>
<br>
</blockquote></div></div>