On Sat, Nov 10, 2018 at 2:08 PM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote: > Thanks for making the time to resolve this. No worries at all. > It looks much better now, and my resolver is seeing the expected > valid answers from all servers, however DNSViz is reporting some > packet drops with queries to the primary "ns0.amsl.com": > ... > sort of stringent rate-limiter may be in place, since queries > ... > Perhaps the packet drops are intentional, but if not, they may be > something to investigate. That is correct, we have rate limiting in place on our primary name server, to help protect against some prior DDOS attacks against it. (I'm always amazed at how much time other people have to craft and launch attacks like this. I *never* have that kind of time. *sigh*) Abridging (so to speak) a few other comments I've seen, now that I've had time to browse the archive... > Only these two get it right: > That's ns0.amsl.com (the primary?) Well, at least we got it right. Many years ago, the IETF decided that they wanted to have Afilias provide slave service to our primary - Afilias continues to do an excellent job at it - but they have made us aware that we need to change to some newer nameservers in the registry, which we are trying to do. Getting control of that process is taking more time than we'd like, but it is in progress. > And who is responsible for and gets to fix it? Ultimately, I am. I don't have the bandwidth to participate in this list; sadly, this list is the place where everyone loves to talk about issues. I have a staff of engineers - they can be reached at ietf-action@xxxxxxxx. But, ultimately, if someone feels like they're not getting satisfaction, I am the "buck stops here" person. > Perhaps the folks at AMSL and their ietf.org liaisons can be persuaded to adopt a more reliable operating model Despite my responsibility to fix things, I lack the commensurate direct authority to make operational model changes. The Tools Team, ultimately, makes those decisions. However, I have put in place new instructions to increase the frequency of manual handling, and the scope of automatic verification, with my engineers. More than anyone else, I *certainly* do NOT want things to fail. > the deliberate unnecessary complexity of the system +1 to deliberate. Many IETF systems are complex, this is the result of many changes by many interested participants over time. I'm not sure I can make a judgement about "unnecessary" but many of the IETF's systems do have many moving parts, and as new technologies and "exciting toys" come out, those tend to get added to the mix, increasing complexity further. At the same time, it is very difficult to take old things out, so we are left with an ever-increasing level of complexity (and work and maintenance needed to handle these things.) > and the failure to maintain it is interesting... > This reveals the questionable robustness of the operation and maintenance functions Since we (AMS) don't control all of the moving parts in this case, I can't respond to that directly, and I have no desire to get into a throwing-under-the-bus situation here. I will simply say that this system, like others, is complex, it needs some updates, we are working on getting access to the things we need in order to apply those updates and, once done, I will hope that it never breaks again. But, sometimes things do break despite all best efforts. And when something does break, I'll do what is needed to fix it again. That's why I'm here. I trust that answers everyone's questions at this stage. I *hope* that I will be on vacation for the next two weeks, but there are people both at AMS and in the Tools Team/community who know how to reach me if it becomes necessary. And if anyone wants to talk about "how the IETF does things," I would invite and encourage you to participate in the Tools Team. They're doing a lot of work on a lot of things (including, hopefully, removing some old things that need to go!) and can use all the support from the rest of us that they can get. If you haven't thought about it before, but would like to help, reach out to Russ, Robert and Henrik, and they'll be happy to work with you. Glen -- Glen Barney IT Director AMS (IETF Secretariat)
