<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 28, 2016 at 9:52 AM, Peter Bowen via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><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="gmail-m_1789444525133663017Apple-tab-span" style="white-space:pre-wrap">   </span>1m5.424s</div><div>user<span class="gmail-m_1789444525133663017Apple-tab-span" style="white-space:pre-wrap"> </span>0m0.476s</div><div>sys<span class="gmail-m_1789444525133663017Apple-tab-span" style="white-space:pre-wrap">  </span>0m0.296s</div></div></div></div></blockquote><div><br></div><div>Thanks for putting together this test. There are a few ways in which it's inefficient. Queries are made serially, while a production system would make them in parallel. Process creation overhead is large, as you mentioned. Also, you are fetching across many different domains, which may have widely varying performance characteristics, but the main case we are discussing is issuance to a large number of subdomains.</div><div><br></div><div>I have a somewhat more realistic test setup I've used for DNS scanning. I used a commodity VPS with 8 cores running Unbound, plus this Go tool: <a href="https://github.com/jsha/go/blob/master/caa-lookups/lookups.go">https://github.com/jsha/go/blob/master/caa-lookups/lookups.go</a>.</div><div><br></div><div><div>time (seq --format '%<a href="http://g.hoffman-andrews.com">g.hoffman-andrews.com</a>' 1 100000 | ./caa-lookups -server localhost:1053 -parallel 1500 -checkCAA) | grep -v ': ok'</div><div><br></div><div>real    1m34.374s</div><div>user    0m45.656s</div><div>sys     0m43.392s</div></div><div><br></div><div>That works out to a rate of about 1000 qps right off the bat, and I'm sure it can be optimized further. Or one could add a few more cores, or a slightly faster network card. I'm confident that this setup could support the issuance rate of 6M per hour (1670 qps) that you cite.</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"><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>If the hostnames are known in advance, this could be handled by doing the CAA check at validation time (with a suitable minimum freshness). The CA could have an online component that checks CAA records in advance for each hostname they wish to issue for, then walk the results to the factory.</div></div></div></div>