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.
>> 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.
>> 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.
> The Old Fashoned Mail Reader Flame War below:
I think I gave you a pointer to a thread in IETF ML. Feel free
to reopen it there but not here.
Masataka Ohta
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
