On Fri, Mar 15, 2024 at 6:03 AM libor.peltan <libor.pel...@nic.cz> wrote:
> Hi Matt! > > Thank you for your findings, this is really interesting. > > First of all, your claim in parentheses "(sjc.dns-oarc.net > <http://sjc.dns-oarc.net> is a real subdomain with hosts in it, not an > ENT)" seems not to be true. It is proven by NSEC that this name is > indeed an ENT. But this of course does not affect the issue importance. > Ugh.. I have no idea what I was thinking when I wrote that. Yes, clearly sjc.dns-oarc.net owns no records. > I analyzed the DNSViz output in detail and it shows that while the name > servers ns1.dns-oarc.net. and ns2.dns-oarc.net, actually do answer > correctly, including the mentioned NSEC, the name servers > udns1.ultradns.net. and udns2.ultradns.net. answer incorrectly, not > including that NSEC. > Ah! It looks like I overlooked some of the detail in the hover text on the graph view. I saw the absence of the necessary NSEC, but missed that it was limited to only some servers. Thanks for pointing that out. > > I tried it by hand and indeed, the problem is solely at ultradns servers: > > Looking at the output, there is a (redundant) NSEC proving the > non-existence of the wildcard *.dns-oarc.net. instead(!): dns-oarc.net. > 3600 IN NSEC fs1.10g.dns-oarc.net. A NS SOA MX TXT > AAAA RRSIG NSEC DNSKEY CDS CDNSKEY CA > > This remind me of a similar issue that we have fixed in Knot DNS some > years ago, but I con't find it at the moment, it seems that what we have > fixed is wildcard answers in connection with CNAMEs/DNAMEs and stuff, > but not this straightforward situation... > > In any case, you should probably tell UltraDNS to use recent versions of > whatever software they use. > I'm fairly sure they're still using their own in-house server software. I'll report this to their support and see what happens. Thanks Libor!
--
