<div dir="ltr">On Wed, Sep 17, 2014 at 12:27 PM, Casey Deccio <span dir="ltr"><<a href="mailto:casey@deccio.net" target="_blank">casey@deccio.net</a>></span> wrote:<br><div class="gmail_extra"><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"><div dir="ltr">I don't immediately see anything wrong with the complete names above.  But I can see that BIND and unbound both are failing validation for _<a href="http://tcp.kinderporno.cz" target="_blank">tcp.kinderporno.cz</a>.  I am wondering if this is perhaps due to incorrect handling of NSEC records associated with wildcards.<br><div class="gmail_extra"><br><div><div><br>$ dig +dnssec +noall +authority @<a href="http://ns.forpsi.it" target="_blank">ns.forpsi.it</a> _<a href="http://tcp.kinderporno.cz" target="_blank">tcp.kinderporno.cz</a> | grep NSEC | head -1<br>default._<a href="http://domainkey.kinderporno.cz" target="_blank">domainkey.kinderporno.cz</a>. 3600    IN NSEC    _jabber._<a href="http://tcp.kinderporno.cz" target="_blank">tcp.kinderporno.cz</a>. TXT RRSIG NSEC<br><br></div><div>The NSEC record returned doesn't prove that the name doesn't exist (NXDOMAIN) because the name (_<a href="http://tcp.kinderporno.cz" target="_blank">tcp.kinderporno.cz</a>) is in fact an ancestor of the next field of the NSEC record (_jabber._<a href="http://tcp.kinderporno.cz" target="_blank">tcp.kinderporno.cz</a>), as an empty non-terminal.  But that proof is not required for wildcard, only for NXDOMAIN status.<br> </div></div></div></div></blockquote><div><br></div><div>For archival purposes, the above guess was incorrect, due to an overlooking of proper server-side wildcard processing behavior from RFC 1034, as indicated by Ondřej, who posted reference to the same issue on the DANE WG mailing list.  In this case, the wildcard should never have been expanded because an ancestor of the name exists.<br><br></div><div>Casey<br></div></div></div></div>