<div dir="ltr">Hi DRC,<div><br></div><div>Thanks for your reply. If we have a root server on-net, then I still have the issue of not knowing whether my recursive server has working outbound connectivity; a local copy of the root then moves the issue to the TLD servers.</div><div><br></div><div>Andrew</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 7, 2016 at 12:32 PM, David Conrad <span dir="ltr"><<a href="mailto:drc@virtualized.org" target="_blank">drc@virtualized.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On Jun 7, 2016, at 8:12 AM, Andrew White <<a href="mailto:andrew@vivalibre.com">andrew@vivalibre.com</a>> wrote:<br>
> We are considering adding some health checks on our recursive DNS platform.<br>
><br>
> We'd like to ensure each server has access to the root via a remote dig at the recursive server. Specifically we are considering a query to an effectively random top-level domain that should always be answered by an NXDOMAIN by a root server.<br>
><br>
> Given the large number of servers and our need to perform this check fairly often, this could result in a large number of queries resulting in NXDOMAIN to the root.<br>
<br>
</span>Not that it's likely your probes will go above the noise in the noise, why not mirror the root (a la <a href="https://tools.ietf.org/rfc/rfc7706.txt" rel="noreferrer" target="_blank">https://tools.ietf.org/rfc/rfc7706.txt</a>)?<br>
<br>
Regards,<br>
-drc<br>
(speaking only for myself)<br>
<br>
</blockquote></div><br></div>