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

[Viktor Dukhovni]

> On May 26, 2018, at 1:54 AM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> Even if some suitable semantics for these were defined promptly
> (unlikely) it would still take a long time for implementations
> to catch up...  So this is something for signers to watch out
> for.  Interesting that I'm only seeing this at nazwa.pl at
> present.

That said, perhaps it is worth considering whether a useful meaning
can be ascribed to wildcard NS even with DNSSEC, so that a decade
from now most resolvers and nameservers might avoid failure in this
case.

It seems to me, that when a zone contains:

	$ORIGIN example.com.
	@ IN SOA ns1.example.net. hostmaster ( ... )
	@ IN NS ns1.example.net.
	@ IN A 192.0.2.1
	* IN NS ns1.example.org

we might exempt the "*" node itself from the rule that
non-authoritative delegation NS RRsets are unsigned,
and require a parent-zone signature for any wildcard NS
records.

If the zone then (as observed) signs the wildcard record:

	* IN NS ns1.example.org.
	* IN RRSIG NS ...
	* IN NSEC @ NS
        * IN RRSIG NSEC

Then it may be possible to conclude that all sub-domains
are insecurely (no DS in the NSEC bitmap) delegated.

A query for _25._tcp.example.com. TLSA might then elicit

	_tcp.example.com. IN NS ns1.example.org.
	*.example.com. IN NSEC example.com. NS
	*.example.com. IN RRSIG NSEC ...

>From which we conclude that "_tcp" does not exist
in the parent zone per the signed NSEC record.  But,
there is a wildcard insecure delegation.  And the
existence or non-existence of insecure TLSA records
might then be obtained from "ns1.example.org."

Perhaps I am missing some crucial obstacle, or perhaps
it is simply not worth the trouble to rescue 9 out of
6.5 million domains from their folly.  And yet it seems
possible to define wildcard NS if that was sufficiently
appealing...

-- 
	Viktor.