<div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Apr 15, 2019 at 12:57 PM Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</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">On Sun, Apr 14, 2019 at 03:56:35PM -0400, Shumon Huque wrote:<br>
<br>
> > There does appear to be a wildcard in play:<br>
> ><br>
> >     @ns3.epik.com.[52.55.168.70]<br>
> >     @ns4.epik.com.[45.79.4.83]<br>
> >     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39918<br>
> >     ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1<br>
> >     ;*.<a href="http://h4ha.net" rel="noreferrer" target="_blank">h4ha.net</a>.            IN A<br>
> >     *.<a href="http://h4ha.net" rel="noreferrer" target="_blank">h4ha.net</a>.             RRSIG   A 13 2 [...]<br>
> >     *.<a href="http://h4ha.net" rel="noreferrer" target="_blank">h4ha.net</a>.             A       192.155.81.104<br>
> ><br>
> > but, as seen above, it is not included in the NSEC chain.  The<br>
> > behavior is identical across all ~3700 <a href="http://epik.com" rel="noreferrer" target="_blank">epik.com</a> hosted domains I've<br>
> > managed to find.<br>
> <br>
> Interesting problem. So the wildcard can be queried directly and validates<br>
> properly. But _any_ queries that match the wildcard, including TLSA records<br>
> at subdomains, don't validate because of the missing NSEC for the wildcard.<br>
<br>
It is a bit more mundane, queries for "A" records do return the<br>
wildcard A result, the failre is with sub-domain queries for any<br>
other RR type, where the RCODE is correct (NODATA), but the NSEC<br>
chain is wrong (includes just the zone apex, no wildcard).<br></blockquote><div><br></div><div>Ah, I see. I did some quick tests using 8.8.8.8 yesterday and it was</div><div>producing SERVFAIL for wildcard expanded positive responses too,</div><div>assumed that it was related to the incorrect NSEC, and didn't bother to</div><div> investigate further.</div><div><br></div><div>Try dig @<a href="http://8.8.8.8">8.8.8.8</a> <a href="http://blah.h4ha.net">blah.h4ha.net</a>. A for example.</div><div><br></div><div>With BIND/Unbound/Knot, this authenticates correctly. But I'd say that</div><div>the reason is a bit more interesting than mundane. The apparent sole</div><div>NSEC record in the zone, that is returned in the authority section of</div><div>the response, although incorrect (because there is at least one other name</div><div>in the zone, the wildcard), accidentally causes the right thing to happen:</div><div>namely it also proves no explicit match and no closer wildcard match of the</div><div>name is possible.</div><div><br></div><div>Wonder why Google fails though? Is it determining that a wildcard exists,</div><div>and thus the NSEC record must be wrong ..</div><div><br></div><div>Shumon.</div><div><br></div></div></div></div>