[dns-operations] (In)correct handling of wildcard NS at zone apex.
ietf-dane at dukhovni.org
Sat May 26 20:40:36 UTC 2018
> 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
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
It seems to me, that when a zone contains:
@ 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
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
More information about the dns-operations