On Sep 30, 2011, at 5:56 PM, Masataka Ohta wrote: > Nicholas Weaver wrote: > >> Correct. But this is why you need to have queries that check the >> caching server AS WELL. The CHAOS queries are useful here, as >> are queries for the cached normal data, and queries which infer >> glue policy so you can know if/what the cached normal data is being >> used. > > Don't solve a simple problem in such a complex way.
If it can affect users, it should be testable from the user's system if possible. >>> Ask one's resolver operator to do so. He will investigate >>> what's wrong and may contact an anycast server operator >>> if he think there is a real problem for which his resolver >>> is not responsible. > >> How am I, in building an automated tool designed to diagnose >> as many problems as possible, > > That's your fundamental misunderstanding. > > Professionals use simple tools. That's the only way to solve > complex, beyond tool builder's imagination, problems in the > real world. No, professional tool-builders benefit from building a full rich suite of tools which combine many tests. And, if done right, become favorite tools of professionals as well as amateurs. [1] Each test, on its own, can be done "as a simple tool": eg, "Whats the exact DNS PMTU for the authority to resolver path"? You would be welcome to build a special command-line client to do so. But in the end, you really do have to test as many things as possible, in as automatic a way as possible if you want to a: Find out what problems an arbitrary end user is facing. E.G. "Your Mother is complaining about her Internet connection." Do you really want to walk her through a set of 60+ separate tests in the debugging flow? or b: Make the network fix itself. >>> As Paul Vixie can not accept all the reports from all the end >>> users, aggregation through resolver operator path is the way >>> for scalable operation. >> >> But until you can generate queries to test the path how are >> you supposed to know where to start looking for the problem? > > First, login to the caching server. Rest depends on internal > details of the server. There may be some tools available > on the server. Your attitude seems to be: "This is ONLY a problem from the point of view of the resolver operator". I disagree. For all multicasted authorities who don't have your attitude, this seems a very simple and easy convention: it costs a trivial amount of effort, and may be quite useful. There's no new RTYPEs and no new major changes, just a few records customized for each instance by a startup script. Those multicast authorities which take your viewpoint can ignore it. [1] Note on Netalyzr: we do do requests. E.G. we're looking at adding tests for Olafur's child-sticky problem, and tests for induced stickiness, and have added in port filtering tests to address specific VPN tools used by colleagues. So if you want us to roll in additional tests, we do consider it, for all those who actually find a multi-function tool a useful service. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
