Re: [DNSOP] Delegation acceptance checks [was: Re: [Ext] WGLC rfc8499bis one week extension for lame delegation definition]

[Joe Abley <[e-mail]>]

Hi Peter,

On Fri, May 5, 2023 at 04:39, Peter Thomassen <[[e-mail]](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

>