[dns-operations] (In)correct handling of wildcard NS at zone apex.

[Viktor Dukhovni]

An interesting edge-case is mishandled by the nameservers at
nazwa.pl.  They seem to have a few customers with signed zones
that are empty apart from a wildcard NS just below the zone
apex.  For example (leaving out RRSIGs and other distractions):

  @ns3.nazwa.pl.[195.238.185.146]
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59853
  ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
  ;_25._tcp.lifestylegb.eu. IN TLSA
  lifestylegb.eu.		SOA	ns1.nazwa.pl. biuro.nazwa.pl. [...]
  eqr[...].lifestylegb.eu. NSEC3 [...] 5E9[...]  A NS SOA TXT RRSIG DNSKEY NSEC3PARAM
  5e9[...].lifestylegb.eu. NSEC3 [...] EQR[...]  NS

  5e95v3ds5672lk9f1d2sin9dmoesmhmq = *.lifestylegb.eu
  eqr053drfcs8a2g7ppmgnau51auumvq9 = lifestylegb.eu

The answer is sufficient to conclude that the zone apex and
the wildcard NS are the only RRsets in the zone.  Unfortunately,
because of the wildcard NS the server is NOT authoritative for
the requested qname and should be returning a delegation, with
the NS RRs and RRSIG in the authority section.  Without these,
I get:

  $ unbound-host -D -t tlsa _25._tcp.lifestylegb.eu 
  [...] <_25._tcp.lifestylegb.eu. TLSA IN>: nodata proof failed from [...]

So far, I've found 8 similar wildcard NS domains served by
nazwa.pl, with TLSA lookups failing in the same manner for
them all.  Have not seen the problem anywhere else (6.5
million other domains), so quite rare, and a bit subtle.

The relevant "NSID" info is:

  ; NSID: [...] ("atm1-dns-slave3.netart.com.pl")

It claims to be PowerDNS 4.1.1:

  version.bind.           CH      TXT     "PowerDNS Authoritative Server 4.1.1 (built Feb 16 2018 09:54:38 by root at 8080b046c7ee)"

and the most recent version appears to be 4.1.3, so this bug may still be in the latest release.

-- 
	Viktor.