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!