<div dir="ltr"><div dir="ltr">On Sun, Apr 14, 2019 at 3:02 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 11:19:09AM -0400, Shumon Huque wrote:<br>
<br>
> Not sure I have any specific suggestions, other than that the DNS community<br>
> could try to work collectively to ensure that all major DNS providers have<br>
> protocol compliant behavior.<br>
<br>
That'd be great. One recent problem "hotspot" is <a href="http://epik.com" rel="noreferrer" target="_blank">epik.com</a>, where<br>
I'm seeing many new problem domains showing. These signed domains<br>
have only the zone apex in their NSEC chain, but TLSA queries for<br>
sub-domains return NODATA rather than NXDOMAIN. This renders replies<br>
for TLSA queries bogus, and breaks email delivery from DANE-enabled<br>
senders.<br>
<br>
For example (condensed):<br>
<br>
@ns3.epik.com.[52.55.168.70]<br>
@ns4.epik.com.[45.79.4.83]<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49327<br>
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1<br>
;_25._<a href="http://tcp.h4ha.net" rel="noreferrer" target="_blank">tcp.h4ha.net</a>. IN TLSA<br>
<a href="http://h4ha.net" rel="noreferrer" target="_blank">h4ha.net</a>. SOA <a href="http://ns1.epik.com" rel="noreferrer" target="_blank">ns1.epik.com</a>. [...]<br>
<a href="http://h4ha.net" rel="noreferrer" target="_blank">h4ha.net</a>. NSEC <a href="http://h4ha.net" rel="noreferrer" target="_blank">h4ha.net</a>. A NS SOA RRSIG NSEC DNSKEY CAA<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></blockquote><div><br></div><div>Interesting problem. So the wildcard can be queried directly and validates</div><div>properly. But _any_ queries that match the wildcard, including TLSA records </div><div>at subdomains, don't validate because of the missing NSEC for the wildcard.</div><div><br></div><div>Wonder what DNS implementation they are running, or if they rolled their</div><div>own. There have actually been bugs in some open source DNS implementations</div><div>involving incomplete NSEC/NSEC3 chain generation.</div><div><br></div><div>I assume you've attempted to reach out to the DNS admins involved?</div><div><br></div><div>Shumon</div><div><br></div></div></div>