On Sep 29, 2011, at 4:05 AM, Masataka Ohta wrote:
>> that happens sometimes. however, i often end up in an email conversation
>> with
>> a problem reporter, and i often ask them to run certain "dig" commands. so,
>> even if i can't reach a recursive server, a feature like this can still help
>> me.
>
> It may work for you if you don't receive too much wrong requests.
>
> For scalable management, however, what you need is call center
> operators as a firewall.
And we're already seeing today, and expect more in the future, systems where
the front-line support instructions include "run a one-click or two-click
tool", rather than "run dig".
As an author of such tools, I strongly support this proposal, as the basic
philosophy of these tools are:
1: Discover a common problem
2: Develop a manual test that understands that problem
{this is the "ask the user to run dig" method.}
3: Wrap up an automatic version of the test into the comprehensive suite...
We have already seen that 3 is very powerful with Netalyzr: at least one
on-line game has adopted Netalyzr as their debugging tool of choice for more
advanced problems.
The information that this proposal realizes, through the use of a very simple
convention, would be of an aid in debugging subtle anycast problems, over paths
that the user OR anycast operator can't easily access otherwise.
Yes, the end USER probably doesn't, and shouldn't care about such information,
but it must be obtainable from the end user's vantage point if you want to
enable such tools to debug DNS anycast issues.
The only additions I'd make is an additional keywords medium- and long-
prepended to the query, and unicast-ip.
The length keyword should have the same information, but with padding in the
text records to a packet length of approximately 1100B and 1800B long.
The reason for this addition is to enable debugging of individual paths for DNS
MTU issues.
While unicast-ip should return an A record for (a) unicast IP address of the
server.
The reason for this is to assist tools which can look up A records but not TXT
records. (EG, the Java API allows easy lookup of IP addresses but doesn't
allow grabbing of TXT records, so unless the Java applet is contacting the
server directly, server identification can be harder).
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
