[dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?

[Daniel Kalchev]

On 12.09.14 04:24, Andrew Sullivan wrote:
> On Thu, Sep 11, 2014 at 09:35:40PM -0300, Rubens Kuhl wrote:
>>
>> It was curious to see that a to-be-unnamed TLD registry, a newcomer
>> to the scene many years after the holy wars that ended up defining
>> the current RFCs, writing completely new code, mentioned that they
>> found attributes to be a better option
> 
> Well, note, the RFCs actually allow you to do one or the other, so
> there was no "victor" in the war.  Many people when designing a new
> registry think attributes are better because they don't create
> cross-object links.  If you come from the database side of the house
> (which I do), you are given shudders because of the potential for data
> inconsistency in glue.  Lots of new registries don't have a glue
> problem early on, and so this never seems like it's worth worrying
> about.  That's the real reason I prefer the host-object approach.  But
> like Frederico, I don't want to reignite a controversy.

If you truly did not want to re-ignite this, you would not have stated
opinion --  there is a reason both ways end up in the RFCs, as both work
and it's all a matter of diligence (and software).

Here is mine

The host-object approach is the worst choice, ever. It suits certain
operators idea of 'visibility', but does not help with data consistency.
Consider the scenario of domain.com delegated to pns1.otherdomain.com
and pns2.otherdomain.com. However otherdomain.com is delegated to
ns1.otherdomain.com and ns2.otherdomain.com. Obviously, otherdomain.com
is the 'service provider'.

In theory, the ns1.otherdomain.com and ns2.otherdomain.com need to have
glue records. Everything else is extraneous, vanity stuff if you will
and add to the maintenance and data consistency burden.

variant 1: ns1.otherdomain.com and ns2.otherdomain.com are attributes to
the otherdomain.com object. Everything is as it should be. Whoever
controls the domain object, controls the glue. The domain object is
gone, so is the glue. Perfect!

variant 2: ns1.otherdomain.com, ns2.otherdomain.com,
pns1.otherdomain.com and pns2.otherdomain.com are all host-objects. Who
owns them? Which of them can/do have glue? True, a much more complex
(read: more prone to errors and harder to verify) piece of software
could handle all the mess. Most of the cases of EPP software are however
quite trivial. What happens when otherdomain.com gets deleted? Which
host-objects disappear, if any, which glue remains, who ends up managing
those records, etc. Zombie host-objects aren't that impossible, right?

As a Hollywood cop would say "follow the money". Who has most interest
for the host objects to exist? Certainly, not the typical domain name owner.

>> better, but for me it indicates that the role in the value chain can
>> play a part in which option is preferred.
> 
> Yes.  Interoperability is way more important that just about anything
> else on the Internet.

You mean... whose operations would be cheaper? :)
The bigger fish wins most of the time.

Daniel