On 1 Jul 2024, at 07:19, Paul Vixie <paul=40redbarn....@dmarc.ietf.org> wrote:
> joe, let's figure out how to "rigidly constrain" again. expressing fixed > policy > which can operate inside the recursive system would be a whole lot easier to > diagnose whenever it's unreliable, but avoid the additional round trips that > the CDN world fears so strongly. we should want that outcome, which > corresponds to "anti-complexity". The BOF is about the practice of authority servers returning client-specific responses to clients in order to direct applications to particular destinations. The IETF in the past has said "don't do that" about things it has felt were distasteful, or it has refused to say anything because the dirty business in question was somehow not worthy of recognition. NAT was one of those things, and as a result v4 NAT traversal is a pig's ear. To me this BOF is an attempt not to perpetuate the same mistake with "DNS load balancing". Coming up with a replacement mechanism sounds lovely but I suspect is unlikely to change the core architectures of those CDNs and other providers who have deployed these existing mechanisms, and if that turns out to be true we will have an additional mechanism to manage in fine xkcd-927 style. Documenting the existing mechanisms and perhaps coming up with ways to make them more supportable seem like better bets if the goal is to move the needle on operational reliability. > davey, "another indirection" means both more round trips and more complexity, > and will find few friends. Not in the sense I intended it. Names are a layer of indirection for addresses. Any layer of indirection is an open door for a control plane. I'm saying that it's unremarkable that people are using the DNS as part of the process of connecting applications to content in a dynamic, user-centric way. I am saying nothing about how many round trips might be involved in doing so. Joe _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
