<div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Apr 15, 2019 at 6:24 PM Peter van Dijk <<a href="mailto:peter.van.dijk@powerdns.com">peter.van.dijk@powerdns.com</a>> wrote:</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">
On 15 Apr 2019, at 22:05, Shumon Huque wrote:<br>
><br>
> 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.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> With BIND/Unbound/Knot, this authenticates correctly. But I'd say that<br>
> the reason is a bit more interesting than mundane. The apparent sole<br>
> NSEC record in the zone, that is returned in the authority section of<br>
> the response, although incorrect (because there is at least one other <br>
> name<br>
> in the zone, the wildcard), accidentally causes the right thing to <br>
> happen:<br>
> namely it also proves no explicit match and no closer wildcard match <br>
> of the<br>
> name is possible.<br>
<br>
PowerDNS also accepts it. My suspicions match yours :)<br></blockquote><div><br></div><div>Good to know. [Reminder to myself: I really need to add a PowerDNS</div><div>recursor to my suite of test resolvers :-)]</div><div><br></div><div>[...]</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">
The response contains the asked-for A record. The (cryptographically <br>
valid) RRSIG over that mentions off-hand that it was expanded from a <br>
wildcard. An NSEC is included that says that ‘blah’ does not exist. <br>
I believe that that is a conclusion that a validator is allowed to jump <br>
to.<br>
<br>
However, the NSEC does prove that the wildcard itself does not exist and <br>
thus the answer makes no sense. I believe that that is also a conclusion <br>
that a validator is allowed to end up with, and it looks like that is <br>
what Google is doing.<br></blockquote><div><br></div><div>Yeah, the response is clearly non-sensical. I wasn't suggesting that Google</div><div>was in the wrong here, but I was wondering about the specific details of their</div><div>validation algorithm, since if our speculation is correct, they seem to be</div><div>going beyond the requirements in the spec.</div><div><br></div><div>An implementer strictly following the recipe for authenticating DNS</div><div>responses outlined in RFC 4035 would probably end up validating</div><div>this response. To quote from 4035, Section 5.3.4:</div><div><br></div><div><div>> 5.3.4. Authenticating a Wildcard Expanded RRset Positive Response</div><div>></div><div>> If the number of labels in an RRset's owner name is greater than the</div><div>> Labels field of the covering RRSIG RR, then the RRset and its</div><div>> covering RRSIG RR were created as a result of wildcard expansion.</div><div>> Once the validator has verified the signature, as described in</div><div>> Section 5.3, it must take additional steps to verify the non-</div><div>> existence of an exact match or closer wildcard match for the query.</div><div><br></div></div><div>It doesn't say: also make sure there are no contradictory facts being</div><div>asserted in the response, such as an NSEC record that denies the</div><div>existence of the wildcard that was deduced to exist by means of the </div><div>RRSIG in the answer section. It seems that resolvers could make any</div><div>number of quite complex deductions of this nature, but why would an</div><div>implementer go out of their way to do all that extra work? On the other</div><div>hand, this zone is clearly broken, so there is probably benefit in a</div><div>popular resolver flagging its responses as broken, if it acts as an</div><div>incentive to get this fixed.</div><div><br></div><div>Shumon.</div><div><br></div></div></div></div>