Your technical comments:
>> b: These should have a TTL of 0 seconds and/or support a
>> prepended, cache-busting wildcard.
>
> Loss of synchronization can occur between cached normal data
> and uncached identification data. And, as I already mentioned
> what is broken may be the caching server.
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.
>>> OTOH, identification by ICMP is up to date save RTT.
>>
>> How can one generate an ICMP on the path from the resolver's
>> outbound interface to to the authority, and receive the
>> response, without access to the resolver?
>
> 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, supposed to ask a HUMAN at
A SEPARATE SITE to conduct MANUAL queries on my tool's behalf?
?????
The major use I see for these queries is in automatic debugging,
not human intervention, to understand if there is a problem which
will require human intervention.
Your "IP layer" solution only works for human intervention, and
only starting with humans which aren't initially in the debugging
process.
> 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?
As a builder of tools, I need to be able to test all the paths
I possibly can that might affects a user's traffic. Direct when
possible, and by inference through queries this this when not.
EG, I already have tests that can determine whether it is the recursive
resolver which has problems with fragmentations or large responses.
Yes, from the client standpoint this limits the fixes that can be
applied, but automated tools on the client need to know this
information in order to know how to react to the problem.
(If I wanted to, I could even identify the hop for the firewall on the
resolver that has this problem, but I don't want to build that test,
because I'm lazy and its sufficient to know "its the resolver that
is broken" for my current purposes)
This is similar information: Information a CLIENT can use to
ATTEMPT to diagnose problems elsewhere in the network by inference.
It may not be perfect, but it will tell the client enough to know
who to talk to.
EG in your criticism, it could be the resolver, not the path
between the resolver and authority thats broken. But even that
is useful information, AND additional queries may help, eg, what
is the TTL on the cached information the resolver is returning
when you query it?
The Old Fashoned Mail Reader Flame War below: Everyone else
just stop reading now and save your eyeballs.
I'm including it so it is on the record, but its below so everyone
else can ignore it.
>> As an addition, your headers suggest you are using
>> Thunderbird. I checked Thunderbird 6 on OS-X this morning,
>> it word wraps unstructured text flawlessly. Please ensure
>> that you haven't mistakenly turned on a mis-formatting
>> "feature".
>
> I use my mail readers with my own configuration both for
> English and Japanese (where ASCII space characters are
> basically not used) mails.
You have deliberately misconfigured your tool to ignore critical
formatting information for ASCII text.
My suggestion is to reinclude spaces, but have the spaces be
in a much smaller font. Your on-screen presentation should
be the same, but it is likely that your displayer will
break on the mini-spaces, providing a word-wrap to your
desired window width.
Also, note that Format=flowed causes more problems than it solves
a) It messes up presentation on a much LARGER population of
mail clients.
b) It incorrectly modifies formatting! You can not properly cut and
paste blocks of code or other items into mail messages, as it ends up
destroying the real formatting.
c) Format=flowed is NOT required. It is an optional feature that
only some mail composers bother with. Notably the biggest clients
DO NOT send it that way:
Outlook neither sends nor receives it properly to my knowledge. So
sending such email breaks a HUGE number of clients.
Mac mail receives it properly but does not send it after concluding
that it was breaking more than it was fixing.
Gmail's web client does not send it, instead mangling plain text
to 72 columns by default. This is even worse: their "solution"
will ensure that not only will the text not display wide when
the user is on a wide device, but that it will display badly and
narrow when the user is on a device like a smartphone.
"Standards" which 90%+ of the market have rejected are not standards,
but wishful thinking.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
