<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On 25 Mar 2019, at 18:52, Florian Weimer <<a href="mailto:fw@deneb.enyo.de" class="">fw@deneb.enyo.de</a>> wrote:<br class=""><div><div class=""><br class="Apple-interchange-newline"></div><blockquote type="cite" class=""><div class=""><div class="">* Florian Weimer:<br class=""><br class=""><blockquote type="cite" class="">* Ondřej Surý:<br class=""></blockquote><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Matt, there’s no difference between NXDOMAIN and SERVFAIL from the<br class="">client perspective.<br class=""></blockquote><br class="">Right. In theory, the recursive resolver could switch to a different<br class="">root server that returns good data, but the malicious root server<br class="">could return bad unsigned glue as part of the attack. It is very<br class="">difficult to recover from that in the recursive resolver.<br class=""></blockquote><br class="">Actually, it's impossible here because <a href="http://ROOT-SERVERS.NET" class="">ROOT-SERVERS.NET</a> is not signed.<br class="">Oops.<br class=""></div></div></blockquote><div><br class=""></div></div>If <a href="http://ROOT-SERVERS.NET" class="">ROOT-SERVERS.NET</a> was signed it would have the effect of increasing the size of responses to priming queries sent with EDNS0/DO=1. An unscientific quick peek over the fence at DNS-OARC's DITL-2018 root zone data suggests that there's a lot of that traffic. Whether or not this has the potential to cause a problem depends on how big the increase might be. Different algorithms might have different impact due to differences in signature size, dual-sign rollovers would cause more bloating, etc, etc.<div class=""><br class=""></div><div class="">In the past it has been suggested (e.g. by me) that signatures in the <a href="http://ROOT-SERVERS.NET" class="">ROOT-SERVERS.NET</a> zone don't have much immediate benefit, since the records we're most interested in securing are the ones that affect end-users directly, which are much further down the tree. If rogue data in a priming response take you on a trip down dark shady alleyways, at least DNSSEC lets you know that you're there.</div><div class=""><br class=""></div><div class="">Anyway, I thought it was worth pushing back gently on any inference that the lack of DNSSEC in <a href="http://ROOT-SERVERS.NET" class="">ROOT-SERVERS.NET</a> was a simple oversight. t has definitely been considered.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Joe</div></body></html>