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

[Mark Andrews <[e-mail]>]

> On 6 May 2023, at 04:45, Joe Abley <[e-mail]> wrote:
> 
> Hi Peter,
> 
> On Fri, May 5, 2023 at 04:39, Peter Thomassen <[e-mail]> 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.)

Then just have them all be post delegation checks.  If the servers listed are not serving within a week pull the delegation.

> 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?

Daily.  There are no zones where this is anything like impossible to do.  A single threaded process can do tens of thousands of requests a second and can be testing hundreds of thousands on delegations simultaneously.  We do this every day with the compliance checks on ednscomp.isc.org.

> 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.

So?  Stability of the DNS is already broken because of broken delegations and non RFC compliant server implementations.  It’s only mostly working at the moment because resolver vendors go to extraordinary lengths to work around the broken configurations and implementations.  No one is saying one strike and you are removed.  I would expect people to be given a reasonable amount of time to correct the issue along with repeated waring to multiple contacts.  That said once you start penalising broken behaviour people will learn that penalties will be applied and will proactively fix things that they know are being checked.

This is nothing more than the equivalent of a vehicle safety check.  For most checks the mechanic will say go get this fixed and come back to me in a few days for a re-check.  There are very few things where the mechanic says you can’t drive this car away as it is so unsafe that you shouldn’t be driving it, if you want to take the vehicle it needs to be on a flatbed.

> 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.

Please show a single instance where the delegation can’t be made coherent at the TLD level.  Nameservers and their addresses are relatively stable compared to everything else in the DNS.

> 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?

Well if the public side of a delegation is getting answers from the private version of the zone there is a problem that needs to be addressed.

> 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?

They ALL matter.  Broken delegations get used by bad actors to cause additional load on recursive servers and on authoritative that are being referred to incorrectly.

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]