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

[Edward Lewis]

On 5/26/18, 23:48, "dns-operations on behalf of Viktor Dukhovni" <dns-operations-bounces at dns-oarc.net on behalf of ietf-dane at dukhovni.org> wrote:
        
    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...

This list not being an IETF one...

1) One design rule for the DNS protocol has been to avoid having the data determine the protocol's algorithm.  E.g., no special cases because "it's the root" or "it's COM".  Avoiding this makes for a simpler, healthier protocol architecture (such as it is).

2) For this, making an exception of the "*" label would mean altering the basic algorithm for validation, which would imply having to "tech refresh" all validators in existence.

3) Would it be less effort, system wide, to take the approach that if one wants to respond "on-demand" to zones (that don't exist a-priori), the provisioning could be done "on-demand"?  This is based on the assumption that this is a niche use case.

4) What if, once we exempt "*" label NS sets from non-signing, someone wants to then add DS records for the wildcarded names?  The DS hash includes the zone's name, meaning, that signed delegations via wildcard match would not go as expected. ("It wouldn't work.")

I do believe that there are name servers that create zones on the fly.  I won't 'fess up names, but if anyone whose done this wants to speak up, how hard is it to on-demand provision a zone vs. relying on a wildcard NS?