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

[Viktor Dukhovni]

> On Jun 1, 2018, at 9:37 AM, Ray Bellis <ray at isc.org> wrote:
> 
> As you surmised, I also believe it's impossible for a true wildcard NS
> using the '*' label to work with DNSSEC because of the issue with the
> owner name forming part of the DS hash.

Yes, secure wildcard delegations can't work without protocol changes.
I was just musing on the possibility/utility of potential protocol
changes to make it work.  *If* "*" is handled specially, then the
signed "*" NS RRset could be validated, and also the signed "*"
DS RRset, along with the relevant NSEC records.  The name that
goes into the DS computation would then be "*" and not that of
the synthetic delegated domain.  Rather a bunch of special-casing,
so almost certainly a very poor cost-to-benefit ratio.

I'm asking on [dns-operations] because I think the costs are
rather obvious.  What's a little less obvious to me is whether
there's actual demand for this sort of thing outside the small
number of customers of nazwa.pl which is the only place I'm
finding zone-apex NS wildcards in DNSSEC-signed domains.

[ The DANE survey now covers working DNSKEY RRsets at 7.61
  million zones, with the wildcard zone apex NS RRsets seen
  only in 11 zones hosted by nazwa.pl nameservers.

  Another DNS provider is the sole place where customers have
  a habit of changing the actual zone apex NS RRset (not its
  child wildcard) to point away from the nameservers that
  have the right keys to sign the zone.  Presently, they're
  fixing these as I find them, but ideally the tooling will
  prevent such changes when they get around to updating it.

  Some amount of "don't let the customer shoot themselves
  in both feet" is appropriate. ]

-- 
	Viktor.