<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 28, 2016 at 9:52 AM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><div><br></div></span><div>OK.  I used a machine with a locally running caching resolver.  I then did the following as a test:</div><div><br></div><div>Fetch top-1m.csv.zip</div><div>Unzip it</div><div>head -n 200 top-1m.csv | cut -d, -f2 | sed -r -e ’s/^/www./‘ > top200.txt</div><div>echo 'nameserver 127.0.0.1’ > resolv.conf</div><div>time (ruby -e 'IO.foreach("top200.txt"){|l| l.strip!; loop {|x|puts l + "."; l=l.split(".")[1..-1].join("."<wbr>); break if l.empty?}}' | while read N; do drill -c resolv.conf "$N" IN TXT; done)</div><div><br></div><div><div>real<span class="m_-9143946021091986854Apple-tab-span" style="white-space:pre-wrap">   </span>1m5.424s</div><div>user<span class="m_-9143946021091986854Apple-tab-span" style="white-space:pre-wrap">      </span>0m0.476s</div><div>sys<span class="m_-9143946021091986854Apple-tab-span" style="white-space:pre-wrap">       </span>0m0.296s</div></div><div><br></div><div>Running the last line again (e.g. after warming the named cache):</div><div><br></div><div><div>real<span class="m_-9143946021091986854Apple-tab-span" style="white-space:pre-wrap">     </span>0m15.105s</div><div>user<span class="m_-9143946021091986854Apple-tab-span" style="white-space:pre-wrap">     </span>0m0.444s</div><div>sys<span class="m_-9143946021091986854Apple-tab-span" style="white-space:pre-wrap">       </span>0m0.404s</div><div><br></div><div>One CA on the call said they have an active contract that requires them to support issuance rates of 6M per hour (approximately 1670 per second).  Even if you reduce this by orders of magnitude, CAA doesn’t make sense.</div></div></div></div></blockquote><div><br></div><div>Considering your above example is dominated by process spawning overhead, it would suggest that your metric example is proof that you can implement CAA inefficiently, not that CAA is itself inefficient.</div><div><br></div><div>For the less technical members, the overhead of invoking a new process every time (Peter's "do drill -c ..." line) is known to be several orders of magnitude slower than a single process to implement this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>Also consider the offline issuance process — e.g. a CA running at a factory, disconnected from the Internet.  How is this to be handled?</div></div></div></div></blockquote><div><br></div><div>This is a more useful and productive line of inquiry, and helps highlight concrete areas where blanket CAA requirements may not be desirable. Thank you for this, because it shows that even discussions related to caching are insufficient for this use case, and argues very strongly for the need for policy-based solutions, rather than technical.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I’m sure the numbers above can be improved by reusing processes, but it does show there are valid concerns.</div></div></blockquote><div><br></div><div>I have trouble reconciling these two statements. The fact that there can be an inefficient implementation is not a proof that there is not an efficient or reasonable one, especially in something so critical to Internet infrastructure.</div><div> </div></div></div></div>