Re: [DNSOP] Delegation acceptance checks

[Havard Eidnes <[e-mail]>]

> Pre-delegation checks add friction to the domain registration
> process. They further complicate the commuications between
> different actors in the commercial graph (registrars, registries,
> resellers, DNS operators, hosting companies) and introduce delay
> and manual intervention into what might otherwise be a fairly
> automated or at least automatable process. That is to say, checks
> have a cost, and that cost might well be difficult to sell in a
> commercial environment, especially one where the policy depends on
> a membership that is often quite commercially motivated. (I
> appreciate not all TLDs are the same.)

Oh, yes, the sanctity of making a buck, "we can't let any technical
obstacle get in it's way", and by extension "contributing to
maintaining the good health of the public DNS doesn't really matter,
as long as we get to collect the registration fees."

I guess it depends on what service the registry is actually
offering.

One way to look at it is that it's offering a service to extend the
public DNS name space to registrants.  In that scenario it makes
perfect sense to do a one-time check on initial registration or
update, with the intention of preventing the domain owner from
shooting himself in the foot.

Another way would be to look at it as purely a name space
administration issue, i.e. just ensure uniqueness, and let loose the
commercial folks with their "product innovations" and "improved
efficiency" aims, casting aside quite a few technical considerations
for the public DNS.

In case you haven't noticed, I have a distaste for the latter, and
a number of registries operate with the former model.


On the technical side, I don't think anyone has suggested to
introduce repeated checks with de-registration either of a single NS
or an entire domain on auto-polit.  Does any public registry
actually do that sort of thing?  I've never heard of it.  I call
that a straw man.

> On the technical side, I think arriving at a generalised approach
> will be difficult. For example,
>
> 1. Repeated checks -- just because something is declared good at
>    registration time doesn't mean it might not go bad later. How
>    often do you need to check?

You are assuming too much here, I think, in particular what the goal
is and what the a reasonable mechanism to attain that goal could be.
I've not argued to "outlaw inconsistencies or lameness", and it is
true that such errors may be introduced over time outside of the
interactions with the registry.  What I have argued is that it's
probably a good idea to check for consistency & service on the time
of registration or update.

> 2. The possibility of cascading failure -- a partial failure in a
>    delegation, if punished by a domain suspension, might result in
>    a complete failure. This is at worst an attack vector and at
>    best contrary to the interests of stability for users of the
>    Internet. Making automated changes to disable things that are
>    already demonstrably fragile seems a bit like form over
>    function.

Again, here you're assuming that something doing a repeated check
will automatically de-register a domain on auto-pilot.  I certainly
have not argued for such a thing, and would find the suggestion
absurd.

> 3. Deliberately-incoherent namespaces -- many of the most common
>    responses in the DNS are generated at response time according
>    to a variety of dynamic policy, and are subject to access
>    control. So vantage points matter. Any policy that is measuring
>    the health of a delegation needs to be able to interpret the
>    results of multiple measurements from different vantage points
>    and understand which of them correspond to a policy that is
>    acceptable, without any a priori understanding of what the
>    response generation policy is. In general I think this is
>    problematic.

I don't think this is problematic at all.  If a registrant wants to
do "private stuff" with his domain, he'd do best in keeping that
private, and the effects of that out of visibility for the registry.
The registry should be checking the publically visible data, and is
unlikely to have a probe for consistency checking within a "private
DNS zone" of a registrant.  And ... if you really insist on doing
violence to the DNS standards and expectations of consistency,
you're of course free to do whatever dirty deeds you have convinced
yourself you need to do in a subdomain / sub-zone of your properly
functioning public DNS domain.

> 4. The fiction of a single namespace. The particular bits of
>    machinery that respond to particular names and particular
>    addresses (including nameserver names and nameserver addresses)
>    are not always the same. Private namespaces exist that avoid
>    collisions with the nominally-public namespace by making the
>    same companyname.com domain exist in both, but implementing
>    each very differently. This is valid and good advice, even
>    (e.g. compared to squatting on .HOME or .CORP). Should those
>    domains be suppressed simply because they are not intended for
>    use by the general public?

I would actually argue that the name space is a single -- the public
DNS name space is a single tree.  Witness the rather long discussion
thread in this group around the .ALT name space, and how normal DNS-
using clients and servers are supposed to relate to it, and how we
now need to carve out a blockage to prevent someone else coming
along later and actually getting .ALT registered in the DNS.

I will concede, though, that what is different is that certain parts
of the name space are only available to a subset of the clients.

So, you're arguing that it would be "causing too much work"(?) for
the registry to insist on having the registrant stand up a couple of
public name servers to register the publically visible version of a
domain?  Really?

Regards,

- Håvard