<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p>Shumon Huque asks:</p><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Try dig @<a href="http://8.8.8.8" rel="noreferrer" target="_blank">8.8.8.8</a> <a href="http://blah.h4ha.net" rel="noreferrer" target="_blank">blah.h4ha.net</a>. A for example.<br></blockquote><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">
With BIND/Unbound/Knot, this authenticates correctly.<br></blockquote><div>... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Wonder why Google fails though? Is it determining that a wildcard exists,<br>
and thus the NSEC record must be wrong ..</blockquote><div><br></div><div>Peter van Dijk replies:<br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The response contains the asked-for A record. The (cryptographically valid) RRSIG over that mentions off-hand that it was expanded from a wildcard. An NSEC is included that says that ‘blah’ does not exist. I believe that that is a conclusion that a validator is allowed to jump to.<br><br>However, the NSEC does prove that the wildcard itself does not exist and thus the answer makes no sense. I believe that that is also a conclusion that a validator is allowed to end up with, and it looks like that is what Google is doing.</blockquote></div><div><br></div><div>And Viktor Dukhovni notes:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This could be an interaction with aggressive nsec.</blockquote></div><div><br></div><div>From the horse's mouth: Google Public DNS returns SERVFAIL for this response because the authority has provided a self-contradictory answer that represents a potential vulnerability in the zone.</div><div><br></div><div>Shumon's speculation further on in the thread that returning SERVFAIL here might encourages authorities to fix the problem is certainly an argument I agree with, and it is part of the reason I chose to do this. The larger reason is that when I was updating the code that now does not accept such self-contradictory answers, it was part of a security cleanup in response to Ralph Dolmans' and Karst Koymans's CVE-2017-15105 vulnerability report, which Ralph later wrote up in an excellent blog post (<a href="https://medium.com/nlnetlabs/the-peculiar-case-of-nsec-processing-using-expanded-wildcard-records-ae8285f236be">https://medium.com/nlnetlabs/the-peculiar-case-of-nsec-processing-using-expanded-wildcard-records-ae8285f236be</a>).</div><div><br></div><div>Although their report focused on wildcard NSEC records, it also demonstrated that NSEC or NSEC3 records could be mis-used for exploits: proving nonexistence of CAA records that did exist, or redirecting e-mail through a wildcard MX when an MX or A/AAAA record existed for a hostname. In that light, it seemed better not to accept these self-contradictory proofs, since they were at best the result of a broken DNSSEC signing process, and potentially a malicious attempt to "prove" things about the domain that were not true. Google Public DNS makes no attempt to search out larger self-contradictions (DNS is only eventually consistent anyhow, so they may exist in any zone that changes), but when a single answer is self-contradictory in this way it is rejected.</div><div><br></div><div>Viktor's point about aggressive NSEC synthesis based on such records is well taken, although Google Public DNS would not do so in this case even if it accepted the inconsistent response, since it needs an SOA record and none was provided here (Google Public DNS aggressive NSEC only synthesizes NXDOMAIN or NOERROR-NODATA responses, not wildcards). Another query type that doesn't match the wildcard (such as AAAA) could be accepted, if it were not for the fact that the authority returns NOERROR-NODATA with a proof of NXDOMAIN. That response also gets a SERVFAIL (as it must, to prevent forged delegation referral responses for nonexistent domains) and therefore is not used for aggressive NSEC cache synthesis.</div><div> </div><div>On a more practical note, in a previous case where an authority was returning "bald-faced lies" (proving the nonexistence of anything but the zone apex in a non-empty zone, in contrast to the minimal white and black lies) we had to disable aggressive NSEC cache synthesis as it was causing spurious negative answers. The domain was later identified as using PowerDNS, and the solution was for them to run pdnsutil rectify-zone to rebuild the NSEC chain (<a href="https://community.cloudflare.com/t/leg-br-domains-failing-to-query-1-1-1-1/18379/2">https://community.cloudflare.com/t/leg-br-domains-failing-to-query-1-1-1-1/18379/2</a>). It is possible that this is all that <a href="http://epik.com">epik.com</a> needs to do to fix this issue.</div><div><br></div><div>@alex<br></div></div></div></div></div></div></div></div></div></div></div></div></div></div>