On Fri, May 5, 2023 at 11:46 AM Joe Abley <jab...@strandkip.nl> wrote:
> Hi Peter, > > On Fri, May 5, 2023 at 04:39, Peter Thomassen <pe...@desec.io > <On+Fri,+May+5,+2023+at+04:39,+Peter+Thomassen+%3C%3Ca+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 > [snip] There is also the notion of indirect checks vs direct checks, with reporting/signaling/scaling elements. I think the work on trust anchors (done for gathering information to inform the root key rollover) would be one relevant example to consider. Other work (recent or in progress) related to reporting to domain operators (don't recall draft or rfc identifiers) would also be useful to examine. 3. Deliberately-incoherent namespaces > [snip] This is definitely something that any proposal should accommodate. One approach would be looking at opt-in vs opt-out mechanisms, possibly anchored under the namespaces of NS names. Scaling for all of these sorts of mechanisms is also very important, given that the first priority of the DNS system is answering queries, and anything that impacts performance needs to be tempered appropriately. > 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? > This is an important consideration, for sure. I think any proposals should start with a couple of things; 1. Identifying what parties are interested parties and/or involved parties. Depending on specifics the number could be large, but in the general case there is a minimum number of parties that are necessarily involved. Enumerating those, and what their roles in would be a good place to start. 2. Determining authority tied to those parties and their roles. The canonical example would be the operator of a name server, should be involved in decisions about whether or not a given delegation should be allowed when the domain is not served by the name server. > > 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. > This is where I can add some useful data and context. Operators of substantial numbers of zones where this traffic is received are able to quantify the impact. At the servers under domaincontrol dot com, the normal traffic is over 15% queries for domains not served (i.e. lame zone delegations). That is a lot. Additionally, lame delegations are abuse vectors. We see much abuse via this vector. And lastly, the current state of affairs is that we are unable to directly affect this, since the RRR model does not include a role for DNS operators. (We are also a Registrar, but when the domain has a different Registrar than us, the RRR rules do not facilitate us removing lame delegations to our name servers.) I do have some ideas on mechanisms, but those probably belong in their own thread. I.e. the issue isn't specifically "pre-delegation checks", it is "delegation correction". > 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. > > How I wish that were the case. It is not, at least not for everyone, and certainly not for us. The abuse vector is similar in nature to the Kaminsky poisoning attacks. The attackers have mechanisms that are fundamental to DNS which operators are defenseless against, for which only systemic corrections can address. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
