<div dir="ltr"><div dir="ltr">On Sun, Feb 28, 2021 at 3:17 AM Bill Woodcock <<a href="mailto:woody@pch.net">woody@pch.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Your experiment is not distributing malware through .GOV or .MIL, therefore you have no reasonable expectation that we, our donors, and our users should absorb the externalized costs of your experiment. <br><br></blockquote><div><br></div><div>I beg your pardon. I am the DNS Architect for the Internal Revenue Service in the Department of Treasury in the US Federal Government. I was not running an experiment. We have had DNSSEC signing for public zones in place since 2011, DNSSEC validation at the perimeter of our recursive infrastructure for all Internet queries, including those for our own public zones, in place since 2012. We have had DNSSEC validation enabled throughout our internal enterprise recursive infrastructure since 2015 and at this juncture have most of our enterprise authoritative DNS DNSSEC signed as well.</div><div><br></div><div>I asked about Quad9 because your publicly posted information asserts you enforce DNSSEC validation. No exceptions are publicly documented yet it appeared that validation was disabled for our primary production second level domain. I was asking if anyone knew why since it appeared Quad9 did enforce DNSSEC validation on other zones like <a href="http://comcast.net">comcast.net</a>.</div><div><br></div><div>It did not occur to me that the Quad9 service had disabled DNSSEC validation for the entire .gov and .mil gTLDs. That definitely needs to be part of your public documentation. Your service DNSSEC validates the parts of Internet DNS you feel like validating.</div><div><br></div><div>Scott</div></div></div>