<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 18, 2017 at 7:25 AM, Gervase Markham 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">Is anyone able to explain why this scenario is at all common? Why would<br>
the authoritative nameservers for a domain refuse to answer queries, if<br>
the owner of the domain wanted the domain to work at all?<br></blockquote><div><br></div><div>Isn't that two questions? That is, can someone explain this scenario, and how common is it? :)</div><div><br></div><div>I think <a href="https://github.com/dns-violations/dns-violations">https://github.com/dns-violations/dns-violations</a> is a useful collection of various ways that vendors have improperly implemented DNS and could result in affecting (a limited number of sites, customers of a particular DNS host / CDN).</div><div><br></div><div>I'm not aware of any publicly available data showing prevalence or that it is common, especially in the context of CA issuance, and so I would think it would be a wonderful contribution to the Internet community if CAs are seeing such issues, that they could publish information about it.</div><div><br></div><div>I know Let's Encrypt has investigated some issues, such as <a href="https://community.letsencrypt.org/t/caa-servfails-from-namebrightdns-com/38748">https://community.letsencrypt.org/t/caa-servfails-from-namebrightdns-com/38748</a> and <a href="https://community.letsencrypt.org/t/public-suffix-list-caa-issue-s/39802">https://community.letsencrypt.org/t/public-suffix-list-caa-issue-s/39802</a> , but these are indicative of gross server misconfigurations, and so failing to issue a certificate is a correct response for a misconfiguration that is indistinguishable from an attack.</div><div><br></div><div>As CAs often remark about OCSP, the most secure solution is to fail closed when a service fails. Given that CAs have direct lines with the customers affected by such service failures - and thus, the means to remedy the issue - this does not seem at all an onerous request.</div><div><br></div><div>As you said, and as Phillip mentioned, this is working as intended and designed, and important for security, so if there is more data that can be shared to help understand these concerns, that'd be useful, but otherwise it doesn't seem necessary to change anything.</div><div><br></div></div></div></div>