Re: [DNSOP] A new appoarch for identifying anycast name server instance
Paul Vixie wrote: Certainly, you, as an end user, can do so. i think i could diagnose problems reported on my authority server if i could get a recursive name server to tell me which of my anycast instances it is talking to. The problem is that the report is unreliable. As your assumption is: The purpose I see in this proposal, that cannot be handled by the IP layer, is to tell me which anycast instance is seen by some recursive name server. even you can't diagnose the problem, if what is broken is not your server but the recursive name server used by someone who reported the problem and you can't have access to the recursive name server. BTW, IP layer solution could be a recommendation on anycast servers to use their unicast addresses as source addresses of ICMP replies, which may be able to traverse NAT. there may also be some network mapping and measurement benefits to this proposal. May or may not be. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
On Thursday, September 29, 2011 07:34:55 am Masataka Ohta wrote: The problem is that the report is unreliable. As your assumption is: The purpose I see in this proposal, that cannot be handled by the IP layer, is to tell me which anycast instance is seen by some recursive name server. even you can't diagnose the problem, if what is broken is not your server but the recursive name server used by someone who reported the problem and you can't have access to the recursive name server. 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. there may also be some network mapping and measurement benefits to this proposal. May or may not be. there are ~16M open recursive name servers right now. so, i say, may. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
On Thu, 29 Sep 2011, Paul Vixie 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. +1 May or may not be. there are ~16M open recursive name servers right now. so, i say, may. In lieu of remote looking glass equivalents for DNS, open recursive name servers have unwittingly helped me gain an idea (if not a precise one) of where the target anycast servers are located. The more open recursive name servers there are to test, the better I can triangulate. So yes, this proposal may be useful on that score. wfms ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
Paul Vixie 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. there may also be some network mapping and measurement benefits to this proposal. May or may not be. there are ~16M open recursive name servers right now. so, i say, may. But, information on them is easily obtained by anycast servers. Or, are you mentioning huge scale network mapping and measurements on zillions of clients behind ~16M servers? Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
Nicholas Weaver 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. It means those who can use run a one-click or two-click tool have no idea on how to bypass intermediate entities, which means call center operators as a firewall is definitely necessary. As an author of such tools, I strongly support this proposal, as the basic philosophy of these tools are: As I said, the basic philosophy is do it at the IP layer. How, do you think, about ICMP reply I mentioned, which is, in theory, required by RFC1122? Masataka Ohta PS Before developing tools, you should better learn to wrap your lines well below 72 characters. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
On Sep 29, 2011, at 7:40 AM, Masataka Ohta wrote: 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. It means those who can use run a one-click or two-click tool have no idea on how to bypass intermediate entities, which means call center operators as a firewall is definitely necessary. I think you're missing something subtle here, both in this comment and in the Do it in IP layer comment. Well constructed tools like Netalyzr are able to infer properties about paths that they don't have direct access to, based on how traffic is passed through them: making sure that the traffic will reveal desired information. This proposal allows debuging information about the recursive resolver TO anycast authority path, a path which the user AND anycast operator do not otherwise have direct access to. Only the recursive resolver operator has access to that path, and for much debugging, the recursive resolver OPERATOR is not a participant in the process. And the end user running the tool, combined with the tech support person on the other end who sees the results, CAN often bypass the broken intermediate entitites, depending on what the results are that the tool spits out: a: If its their NAT or local CPE being very lame: blocking requests AND with a bad proxy, tell the user to replace it. b: If the CPE is giving its own lame proxy but can be bypassed, instruct the user how to use Google Public DNS: problem solved for the user without needing a forklift upgrade. c: If the recursive resolver itself is being lame (eg, how Earthlink's was the other day), either instruct the user how to bypass it, OR start applying various pressures to the resolver operator to get it fixed ASAP. d: If its a path problem between the recursive resolver and the authority, tech support escalates it internally. a, b, and c you can get today with some care (we don't package it up in Netalyzr, but we can distinguish between the three cases in the data), but D is hard, and this requires tools such as the proposal. PS Before developing tools, you should better learn to wrap your lines well below 72 characters. That your mail reader can't word wrap properly on received messages is not my problem. Word wrapping MUST be done on the recipient side, not on the sender side, unless you want to maintain ridiculous conventions like text lines are at most 72 characters, monospaced which were obsolete two decades ago. And in this case particular case, blame Microsoft. Apple on their mailer for the longest time implemented a standard method, format=flowed, intended to please BOTH mail readers that can word-wrap and mail readers that can't. But they dropped this way back in 10.6.2, because Microsoft never recognized it right. Given the choice between pleasing a few recipients who cling to an obsolete convention with obsolete tools and pleasing the very large population of recipients with a tool unwilling to accept a standard which could please both, Apple went with the natural choice: it is the mail reader's responsibility to word wrap to the reader's own display parameters. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
Nicholas Weaver wrote: I think you're missing something subtle here, both in this comment and in the Do it in IP layer comment. I'm afraid it's you. This proposal allows debuging information about the recursive resolver TO anycast authority path, a path which the user AND anycast operator do not otherwise have direct access to. As for subtlety, what if, the information is cached and stale? OTOH, identification by ICMP is up to date save RTT. I skipped to read rest of your mail, because you have not learned to wrap lines properly. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] word wrapping and respect for standards
On Thursday, September 29, 2011 03:36:26 pm Nicholas Weaver wrote: Word wrapping MUST be done on the recipient side, not on the sender side, unless you want to maintain ridiculous conventions like text lines are at most 72 characters, monospaced which were obsolete two decades ago. And in this case particular case, blame Microsoft. Apple on their mailer for the longest time implemented a standard method, format=flowed, intended to please BOTH mail readers that can word-wrap and mail readers that can't. But they dropped this way back in 10.6.2, because Microsoft never recognized it right. Given the choice between pleasing a few recipients who cling to an obsolete convention with obsolete tools and pleasing the very large population of recipients with a tool unwilling to accept a standard which could please both, Apple went with the natural choice: it is the mail reader's responsibility to word wrap to the reader's own display parameters. format=flowed gave the nec'y hint, told my user agent that the text was meant to be wrapped. in the absence of this hint, i don't get word wrapping because the columns might be fixed. (like code fragments or similar.) so i do blame microsoft for not doing the right thing with format=flowed, but i also blame apple for going off-rails and violating the principle of least astonishment for an unknown but nonshrinking population of non-microsoft e-mail readers. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
Note: The following is manually formatted because you are incapable of using a modern mail reader OR have deliberately misconfigured your modern mail reader OR are reading the message using a buggy archive: On Sep 29, 2011, at 9:34 AM, Masataka Ohta wrote: Nicholas Weaver wrote: I think you're missing something subtle here, both in this comment and in the Do it in IP layer comment. I'm afraid it's you. This proposal allows debuging information about the recursive resolver TO anycast authority path, a path which the user AND anycast operator do not otherwise have direct access to. As for subtlety, what if, the information is cached and stale? Good point, but there are easy solutions: a: Do you honestly expect these queries to be common enough to be cached? b: These should have a TTL of 0 seconds and/or support a prepended, cache-busting wildcard. 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? Please tell me how to do so, in a way that is expected to work, so I can use this in automating some significant problem solving. I skipped to read rest of your mail, because you have not learned to wrap lines properly. Your inability to use a modern mail client is NOT MY PROBLEM! Let me reiterate, manually formatted to please you: That your mail reader can't word wrap properly on received messages is not my problem. Word wrapping MUST be done on the recipient side, not on the sender side, unless you want to maintain ridiculous conventions like text lines are at most 72 characters, monospaced which were obsolete two decades ago. And in this case particular case, blame Microsoft. Apple on their mailer for the longest time implemented a standard method, format=flowed, intended to please BOTH mail readers that can word-wrap and mail readers that can't. But they dropped this way back in 10.6.2, because Microsoft never recognized it right. Given the choice between pleasing a few recipients who cling to an obsolete convention with obsolete tools and pleasing the very large population of recipients with a tool unwilling to accept a standard which could please both, Apple went with the natural choice: it is the mail reader's responsibility to word wrap to the reader's own display parameters. 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. If you are complaining because a particular web mail archive you are using are not formatting properly, it is a bug in the archive generation tool's HTML formatting, and should be reported as such. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
You know Nicholas, if you've got time to respond to the next best thing [DNSOP] and [DNSEXT] have to a troll, we still need a replacement mechanism for registering EDNS0 types. :) For you curmudgeons like me, remember to Meta-x auto-fill-mode before you read this note. o.b.DNS: If I use both SPF and DKIM, do I get SPDIF for better DNS surround sound? -Alex (Note: I don't know, and I don't care, if 'taka does it intentionally. Just a trend I've noticed. This is all just my completely subjective opinion, and should be disregarded as such.) -Original Message- From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of Nicholas Weaver Sent: Thursday, September 29, 2011 1:13 PM To: Masataka Ohta Cc: Paul Vixie; dnsop@ietf.org; Nicholas Weaver Subject: Re: [DNSOP] A new appoarch for identifying anycast name server instance Note: The following is manually formatted because you are incapable of using a modern mail reader OR have deliberately misconfigured your modern mail reader OR are reading the message using a buggy archive: On Sep 29, 2011, at 9:34 AM, Masataka Ohta wrote: Nicholas Weaver wrote: I think you're missing something subtle here, both in this comment and in the Do it in IP layer comment. I'm afraid it's you. This proposal allows debuging information about the recursive resolver TO anycast authority path, a path which the user AND anycast operator do not otherwise have direct access to. As for subtlety, what if, the information is cached and stale? Good point, but there are easy solutions: a: Do you honestly expect these queries to be common enough to be cached? b: These should have a TTL of 0 seconds and/or support a prepended, cache-busting wildcard. 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? Please tell me how to do so, in a way that is expected to work, so I can use this in automating some significant problem solving. I skipped to read rest of your mail, because you have not learned to wrap lines properly. Your inability to use a modern mail client is NOT MY PROBLEM! Let me reiterate, manually formatted to please you: That your mail reader can't word wrap properly on received messages is not my problem. Word wrapping MUST be done on the recipient side, not on the sender side, unless you want to maintain ridiculous conventions like text lines are at most 72 characters, monospaced which were obsolete two decades ago. And in this case particular case, blame Microsoft. Apple on their mailer for the longest time implemented a standard method, format=flowed, intended to please BOTH mail readers that can word-wrap and mail readers that can't. But they dropped this way back in 10.6.2, because Microsoft never recognized it right. Given the choice between pleasing a few recipients who cling to an obsolete convention with obsolete tools and pleasing the very large population of recipients with a tool unwilling to accept a standard which could please both, Apple went with the natural choice: it is the mail reader's responsibility to word wrap to the reader's own display parameters. 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. If you are complaining because a particular web mail archive you are using are not formatting properly, it is a bug in the archive generation tool's HTML formatting, and should be reported as such. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
