Hi Peter,
On Fri, May 5, 2023 at 04:39, Peter Thomassen <[pe...@desec.io](mailto:On Fri,
May 5, 2023 at 04:39, Peter Thomassen <<a href=)> wrote:
>> Having the delegating party check for service for the requested zone
>> at time of delegation request and refuse to update / register if
>> this check fails
>
> It would be interesting to develop a consensus position on acceptance checks
> for delegations. (Obviously, that's out of scope for this draft, so renaming
> the subject.)
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.)
The ability to arrive at a consistent universal policy across many different
policy regimes seems like a bit of a long shot. Some early adopters of
increased friction will be at a commercial disadvantage to late or
never-adopters of the same kinds of checks. This disadvantage will provide
further disincentive to adopt this kind of check for those registries that are
commercially-motivated. (I appreciate not all TLDs are commercially-motivated.)
So even if a clear technical best current practice could be published, I think
there would be considerable work to do in seeing it implemented. I presume
implementation is desirable, otherwise we're just navel-gazing.
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?
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.
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.
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?
My personal opinion on all of this is that there is already direct commercial
pressure for delegations to be healthy when they matter. Services that depend
on the DNS (or things reached by the DNS) that people care about generally have
incentives to keep their ducks lined up (incentives like revenue, customer
retention, being elected again). Things in the DNS that aren't well-paired with
incentives like that might well break more often, but if a delegation breaks in
the forest and there's nobody present to argue about whether the delegation is
strictly lame or not, does anybody need to care?
To look at it another way, why would we give authority to a third party to
break our domains just because they are not fully-informed about how we are
using them?
And lastly, even if a delegation is genuinely broken and useless for all the
world, and nobody cares enough to fix it, what harm does it do? What is the
motivation to find a fix? A dribble of extra traffic relating to a
mainly-unused domain to a nameserver that is already over-provisioned doesn't
seem very compelling.
Even if I thought this was a problem that needed a solution, I don't think the
solution is likely to be easy. The technical aspects are the easiest part, and
those are already difficult. Perhaps we can just become comfortable with the
idea that at any time the DNS contains bits that work and bits that don't work,
and that is just the way of things.
Joe
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
