>> It may not be possible for everyone to agree on a comprehensive >> set of 'wrongs' with no omissions, but it should be possible to >> get consensus on a core set of 'wrongs' that are not controversial. > > Yes and no. I think going for a minimum will be a good goal, > but for example to have lame delegations must by definition be > allowed, as some registration policies do require delegation > (i.e. NS records). So people add NS records in parent zone, but > nothing responds there.
I think I don't understand the scenario you're sketching up here. Furthermore, I don't think I understand why you argue that such a setup must be acceptable. Does the scenario look like this? * Client asks to registrar to set up frobbit.se * Registrar is lazy and doesn't want to set up a separate zone, so instead sets up his own fake .se zone where he puts the data for frobbit.se, including delegating NS records which points towards the servers serving the fake .SE zone. * Registrar contacts the registry to have frobbit.se registered as a delegation I've heard anectdotal evidence about folks doing that, and being denied doing so by registry checks because the SOA record comes out wrong. But this doesn't create a lame delegation (does it?) so I don't think I understand what you're saying. A zone registered with delegation records, but where none of the name servers respond to queries for the zone does noone any good, so why must it be acceptable? Maybe my imagination can't fathom the reasons why people insist on creating lame delegations. > Until policy allows registration without delegation, you will > see lame delegations. Again, please explain. Maybe I'm spoiled by our local CC registry insisting on certain technical checks passing before registration can be allowed to proceed. I'm not saying we're without lame delegations, though, but I think they occur for other reasons (post-registration changes, badly-managed transisions). Regards, - Håvard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
