On 5/11/23, 7:30 PM, "DNSOP on behalf of Mark Andrews" <dnsop-boun...@ietf.org on behalf of ma...@isc.org> wrote: > > It’s not a challenge to track what is lame. It’s dead simple. You just > have to look. Getting > it addressed is the challenge.
Speaking from experience (which means I'm about to launch an amplification attack here: taking a short message and adding in stories from the past few decades in this area), this is very true. Using the analogy of observing symptoms, diagnosing cause, prescribing a fix, and following through, it's easy to tell when someone coughs - but, if the cause happens to be from a personal habit, very difficult to mitigate. In following this discussion, admitting that I have no idea what "rfc8499bis" is (not a title, not a document file name, not a link), I ought to throw in this question: "Why do broken delegations (lame, unreachable address, etc.) matter?" So in some sense I'm committing an IETF sin. In my experience with lameness, the problem was rather specific. In that era, a server, given a question it could not answer would refer the querier to the root zone - perhaps as some sort of joke initially. The trouble was that some resolvers were not in on the joke (and I bet there was no technical document specifying what an "upwards referral" signified) but it turned out to be pretty easy to fix the problematic resolvers. (It was one major, proprietary source who, surprisingly to many in the open source fandom, actually fixed their bug.) I'm not sure my work in quantifying the amount of lameness ever mattered as the eradication process undertaken seemed to overcome by the fix of the resolvers (nevertheless, it was pretty interesting research to conduct). (This is the central thought of this rant:) It's true that if a registrant misconfigures their delegation or servers, their service will suffer. But does this have fallout for anyone other than their service users? Other than researchers who poke into this stuff (like me)? Does it impact the registry delegating to the registrant? From other experience, I once dove into an incident (details I can't divulge). One of the things I identified was the source of the queries for a particular DNSSEC-related data set. In the top-ten queries was a "labs" machine - a research organization was "pounding" the servers for this data set to the extent they were a noticeable portion of the incoming traffic. At times, research is not measuring traffic but becoming the traffic. And from another experience, I once had to deal with a customer who had a zone delegated to the servers that we operated but neglected to tell us. (The very picture of lameness, completely unrelated to my earlier lameness quantification.) Our monitors did not know the incoming queries were headed for one of our current customer's zone as we didn't know the zone was theirs. We thought it was simply DDoS-related traffic. A factor here is that the operations I am talking about were not a TLD of any kind (hence the last label was not tell-tale). And yet another experience, I've dealt with situations where a major change was being proposed but those that needed to play along had absolutely no relationship with us. The Internet encourages people to plug in and play without being subject to remote monitoring. At times that is very good. At times that is very frustrating. What I learned from that was no one can set expectations on what someone else will do on the Internet. One can't expect protocol conformance from an entity with which you have no relationship, but you need to be prepared to deal with whatever comes (a take on "liberal accept, conservative send" - that adage attributed to Jon Postel). It's fine to quantify situations. It's fine to launch campaigns to improve the "health&safety" of the Internet and fine to measure the impact of the campaigns. But you can never expect to see "success". This is really frustrating when changes (including clarifications) are sorely needed to improve the state of operations across the global public Internet. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
