Re: [DNSOP] A new appoarch for identifying anycast name server instance
Nicholas Weaver wrote: 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. The way to solve a complex problem is divide and conquer. The obvious point of division is the caching resolver. You insisting on not to divide the problem but to keep the problem complex and rely on complicated tools is not acceptable not even by end users. 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 I mean professional DNS operators, as here is DNSOP. benefit from building a full rich suite of tools which combine many tests. Feel free to have a PROFESSIONALDNSTOOLBUILDERS ML elsewhere. Rest of lengthy lines are legitimately ignored. 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
Nicholas Weaver wrote: Note: The following is manually formatted because because you choose not to use a feature of modern mail composers? As for subtlety, what if, the information is cached and stale? Good point, but there are easy solutions: You are still missing the subtlety. a: Do you honestly expect these queries to be common enough to be cached? That's no solution. 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. 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. 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. 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! That your mail reader can't word wrap properly on received messages is not my problem. See my first lines of this mail. 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. 72 (actually 80 or 132, but we should be conservative) characters is based on ergonomics of key board size and legible character size, which have had and will have longer history than Apple. See this thread in IETF ML this February for further enlightment: https://www.ietf.org/ibin/c5i?mid=6rid=48gid=0k1=933k3=9861tid=1317368971 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, That you don't accept that reality is your problem. 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. 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
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
Re: [DNSOP] A new appoarch for identifying anycast name server instance
On 30/09/2011 14:22, Nicholas Weaver wrote: The Old Fashoned Mail Reader Flame War below: Everyone else just stop reading now and save your eyeballs. By all means carry on with the discussion of the identification of anycast nameserver instances, but Mail Reader Flame Wars are not in the scope of DNSOP and should not be carried out on this list. Thanks, Stephen DNSOP Co-Chair ___ 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: 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
Re: [DNSOP] A new appoarch for identifying anycast name server instance
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
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
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
Re: [DNSOP] A new appoarch for identifying anycast name server instance
I have noticed that the good source of entropy for even load balancing with reply suppression for duplicated query is source port number and message-id, which means identifying query is unstable. 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
Bill Woodcock wo...@pch.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sep 27, 2011, at 2:21 PM, Edward Lewis wrote: Whether this is a DNSOP WG item rests on how broad the interest is On Sep 27, 2011, at 1:17 PM, Warren Kumari wrote: I for one am interested and willing to work on this (responding for bean counting..) Likewise. We don't need it internally, but it seems like a good idea, and I think we'd be happy to support it, if it were done well. We're happy to work on it. -Bill Woodcock Research Director Packet Clearing House -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iQIcBAEBCAAGBQJOgmCNAAoJEG+kcEsoi3+HmZcP/jaC0bPZ2vOqyXBPc00dKXUe UXJZuvghGrP2xtoDveXwGJFm5OHQNsTlfxs3TuVZGPmnKMpkWGZB0IAJ1btDiAUh etYSCed82ETbZ3uVLpBGIryf9vZJQTrWJ/lfsTZn8Mqa8dOUzB+bQywfpYE+WMeS OIeOo/culWA80PtiENkm2HV7r3Y+ajUqG3f0Ldh8icYUQGIriqfbWFW6zxF2bqPL CEv2GtgjCVTHo0O7oWGSh88X5h7uvFNzD0L48N64WaUP4pMKgvK3gA0DaMC3S4yF LS6ikyO9rkABX5Bd8mAugoKHPB9uXh8LhjuOlhZiRxDMJ27x2cIHoON40kE0ByUK nHmHzdrPQF94uSmbekd3disx66PBHzGCiaDusujnGUaPGOOLDY72/Vt8SuyyEPbI tDbsOC11t99VIRHYSdbYjJ7tqMScatuAHIECV6zkDNIV0SjseXosjn5aKv/dlVpY /jL0vHkQvuNOJ3+G8NIJHIoKoDQcg0sY8eQJw7GBGTgc0CLvVIj26eveZTfBRL/2 803K8xQvw4DlItIQvvHu2bzDN1N4Sw8MGNLinwdht+tKqoD3rELZhtpwCy8mr8v1 BA4kW0YYediXH9zw41IGhpJPrJ5MLj51w7itRW5fWFVtVluDGG2EUMYtBJbmLdMA At6NB9dzSPk8wiNMDiro =QOdR -END PGP SIGNATURE- ___ 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
Re: [DNSOP] A new appoarch for identifying anycast name server instance
Bill Woodcock wo...@pch.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sep 27, 2011, at 2:21 PM, Edward Lewis wrote: Whether this is a DNSOP WG item rests on how broad the interest is On Sep 27, 2011, at 1:17 PM, Warren Kumari wrote: I for one am interested and willing to work on this (responding for bean counting..) Likewise. We don't need it internally, but it seems like a good idea, and I think we'd be happy to support it, if it were done well. We're happy to work on it. -Bill Woodcock Research Director Packet Clearing House -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iQIcBAEBCAAGBQJOgmCNAAoJEG+kcEsoi3+HmZcP/jaC0bPZ2vOqyXBPc00dKXUe UXJZuvghGrP2xtoDveXwGJFm5OHQNsTlfxs3TuVZGPmnKMpkWGZB0IAJ1btDiAUh etYSCed82ETbZ3uVLpBGIryf9vZJQTrWJ/lfsTZn8Mqa8dOUzB+bQywfpYE+WMeS OIeOo/culWA80PtiENkm2HV7r3Y+ajUqG3f0Ldh8icYUQGIriqfbWFW6zxF2bqPL CEv2GtgjCVTHo0O7oWGSh88X5h7uvFNzD0L48N64WaUP4pMKgvK3gA0DaMC3S4yF LS6ikyO9rkABX5Bd8mAugoKHPB9uXh8LhjuOlhZiRxDMJ27x2cIHoON40kE0ByUK nHmHzdrPQF94uSmbekd3disx66PBHzGCiaDusujnGUaPGOOLDY72/Vt8SuyyEPbI tDbsOC11t99VIRHYSdbYjJ7tqMScatuAHIECV6zkDNIV0SjseXosjn5aKv/dlVpY /jL0vHkQvuNOJ3+G8NIJHIoKoDQcg0sY8eQJw7GBGTgc0CLvVIj26eveZTfBRL/2 803K8xQvw4DlItIQvvHu2bzDN1N4Sw8MGNLinwdht+tKqoD3rELZhtpwCy8mr8v1 BA4kW0YYediXH9zw41IGhpJPrJ5MLj51w7itRW5fWFVtVluDGG2EUMYtBJbmLdMA At6NB9dzSPk8wiNMDiro =QOdR -END PGP SIGNATURE- ___ 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
Re: [DNSOP] A new appoarch for identifying anycast name server instance
On 2011-09-27, at 14:21, Edward Lewis wrote: We respond honestly to queries for HOSTNAME.BIND, VERSION.BIND, ID.SERVER, VERSION.SERVER as well as RFC5001/NSID on L-Root, for example. It's not a matter of honesty. No inference intended; what I meant was we let the software report its actual version number, and the actual hostname of the server rather than overriding them (as I've seen some people do). Joe ___ 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 28, 2011, at 5:47 AM, Joe Abley wrote: On 2011-09-27, at 14:21, Edward Lewis wrote: We respond honestly to queries for HOSTNAME.BIND, VERSION.BIND, ID.SERVER, VERSION.SERVER as well as RFC5001/NSID on L-Root, for example. It's not a matter of honesty. No inference intended; what I meant was we let the software report its actual version number, and the actual hostname of the server rather than overriding them (as I've seen some people do). Just a sampling of some of the version strings we've seen in scanning DNS resolvers and authorities: The name is BIND, James BIND Enterprise I don't think so captain 13:54 @zarkdav well, one could write a zone file so that it returns a joke 666 the number of the beast...! A kinky version of course ALL YOUR BASE ARE BELONG TO US All we are is dust in the wind Are you still shivering? Are you still cold? Are you loathsome tonight? Does your madness shine bright? Ash nazg durbatuluk, ash nazg gimbatul, ash nazg thrakatuluk agh burzum-ishi krimpatul. Aye, Carumba! He's looking at me version string! (We have even received abuse complaints for querying for version strings!) ___ 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 Tue, 27 Sep 2011 22:51:09 +0900 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Paul Vixie wrote: 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. All our current diagnostics rely on contacting the server itself to see which server answers us. The proposal now being discussed allows the DNS control plane to be tested. Are you saying that end users, not name server operators, diagnose anycasted name servers? no. 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. there may also be some network mapping and measurement benefits to this proposal. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
Xun wrote: So, what diagnosis, are you considering, becomes possible only by your proposal? The particular diagnostic that our proposal tries to provide is to tell which one of a set of anycast servers responses to a DNS query. It's a reception by a hospital clerk rather than a diagnosis by a doctor, I'm afraid. Unicast address of an anycast server is very useful for many diagnostics, however, as DNS queries is sent to the anycast address and the path is decided by routing system, knowing the set of unicast address may not sufficient to answer that question. That is an issue better handled by IP layer. Also, I'm afraid a fantastic idea of anycast node of RFC4892 is a result of broken specification of IPv6 anycast (yes, IPv6 is broken in several ways), which assumes there should be more than one anycast servers sharing an anycast address on a link. Anyway, we can't discuss anything meaningful about anycast node, because its definition is too fuzzy. I am not sure if I correctly understand your statement. Did you mean multiple anycast servers sharing a same path is only for IPv6? I'm not sure either, because of broken terminology of the RFC, which is your problem. Are you saying anycast node is, following a definition of node of IPv6, something looks like a server for the rest of the Internet? 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 Tuesday, September 27, 2011 09:49:03 am Masataka Ohta wrote: Xun wrote: Unicast address of an anycast server is very useful for many diagnostics, however, as DNS queries is sent to the anycast address and the path is decided by routing system, knowing the set of unicast address may not sufficient to answer that question. That is an issue better handled by IP layer. 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. All our current diagnostics rely on contacting the server itself to see which server answers us. The proposal now being discussed allows the DNS control plane to be tested. In other words if I want to know which F-root instance I am being routed to, I can ask, dig @f.root-servers.net version.bind ch txt or the equivilent in terms of id.server. But if i want to know which F-root node my ISP's name server is being routed to, I have no tools available today. I would like to be able to say dig @75.75.75.75 _hostname._ns_diags.f.root-servers.net txt or similar. To do that, there has to be an NS record at or below the name server name (or some other predictable rendezvous point in the naming system) and each instance must serve that zone locally with localized content. I support the general concept of this draft. re: http://www.isi.edu/~xunfan/research/draft-anycast-diagnostics.txt Paul ___ 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 is an issue better handled by IP layer. 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. All our current diagnostics rely on contacting the server itself to see which server answers us. The proposal now being discussed allows the DNS control plane to be tested. Are you saying that end users, not name server operators, diagnose anycasted name servers? Certainly, you, as an end user, can do so. Moreover, your report as an end user to name server operators may not be ignored, if you can somehow bypass call center operators to reach someone who knows what BIND means. In general, however... 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
A noble idea, but alas not terribly useful. If this were available, we'd disable it in anything we deploy nor build it into our code base. At 11:26 -0700 9/25/11, xun...@isi.edu wrote: Hi all, Our research group has been looking at assessing anycast usage. (We have a technical report about our early findings at ftp://ftp.isi.edu/isi-pubs/tr-671.pdf if you're interested.) One result of that work is that we think additional information would make anycast dianosis much easier---we'd like to use in-band class-IN TXT records to augment what is done today with class-CHAOS records today (RFC-4892). In discussing our findings and proposed approach with ISC, they recommended we put together an internet-draft that documents our proposal. We have a draft of our proposal with rationale at http://www.isi.edu/~xunfan/research/draft-anycast-diagnostics.txt We'd love to get feedback from the working group, and to know if this sort of diagnosis would be something appropriate for the WG to take up. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Vote for the word of the day: Paparazzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate red tape ___ 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 2011-09-27, at 10:09, Edward Lewis wrote: A noble idea, but alas not terribly useful. Not very useful for Neustar, maybe, but I would suggest that your requirements in this regard are likely not to be universal. We respond honestly to queries for HOSTNAME.BIND, VERSION.BIND, ID.SERVER, VERSION.SERVER as well as RFC5001/NSID on L-Root, for example. Joe ___ 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 Tue, 27 Sep 2011 14:21:48 EDT, Edward Lewis wrote: At 13:53 -0400 9/27/11, Joe Abley wrote: Not very useful for Neustar, maybe, but I would suggest that your requirements in this regard are likely not to be universal. No argument with that. But since the question was asked... What I meant is that although there are places that will want to implement this, there are many that won't, including us. (Lecture on internal monitoring, et.al., elided.) I'd have to say that it has been a long time since there was a trouble ticket that needed to know which any cast instance was being hit by the user. There's nothing wrong with anyone implementing this. But whether this is a DNSOP WG item rests on how broad the interest is and if there's a need to coordinate for interoperability reasons. This discussion from several folks suggests that security and access control are worth thinking about more than the current draft does. As for the WG scoping question: there was enough interest that RFC-4892 was written in 2007. What's proposed is, in one sense, a more general RFC-4892. If that was intesting enough then, has anything changed to make the topic no longer interesting? Part of our motivation is that if we make diagnosis easier and more powerful, perhaps new people will want to do it. For example, enabling customers of a service to independently validate they're getting the coverage they're paying for. (Of course, you have to decide if that example is a reason for, or against :-) -John Heidemann ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sep 27, 2011, at 2:21 PM, Edward Lewis wrote: Whether this is a DNSOP WG item rests on how broad the interest is On Sep 27, 2011, at 1:17 PM, Warren Kumari wrote: I for one am interested and willing to work on this (responding for bean counting..) Likewise. We don't need it internally, but it seems like a good idea, and I think we'd be happy to support it, if it were done well. We're happy to work on it. -Bill Woodcock Research Director Packet Clearing House -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iQIcBAEBCAAGBQJOgmCNAAoJEG+kcEsoi3+HmZcP/jaC0bPZ2vOqyXBPc00dKXUe UXJZuvghGrP2xtoDveXwGJFm5OHQNsTlfxs3TuVZGPmnKMpkWGZB0IAJ1btDiAUh etYSCed82ETbZ3uVLpBGIryf9vZJQTrWJ/lfsTZn8Mqa8dOUzB+bQywfpYE+WMeS OIeOo/culWA80PtiENkm2HV7r3Y+ajUqG3f0Ldh8icYUQGIriqfbWFW6zxF2bqPL CEv2GtgjCVTHo0O7oWGSh88X5h7uvFNzD0L48N64WaUP4pMKgvK3gA0DaMC3S4yF LS6ikyO9rkABX5Bd8mAugoKHPB9uXh8LhjuOlhZiRxDMJ27x2cIHoON40kE0ByUK nHmHzdrPQF94uSmbekd3disx66PBHzGCiaDusujnGUaPGOOLDY72/Vt8SuyyEPbI tDbsOC11t99VIRHYSdbYjJ7tqMScatuAHIECV6zkDNIV0SjseXosjn5aKv/dlVpY /jL0vHkQvuNOJ3+G8NIJHIoKoDQcg0sY8eQJw7GBGTgc0CLvVIj26eveZTfBRL/2 803K8xQvw4DlItIQvvHu2bzDN1N4Sw8MGNLinwdht+tKqoD3rELZhtpwCy8mr8v1 BA4kW0YYediXH9zw41IGhpJPrJ5MLj51w7itRW5fWFVtVluDGG2EUMYtBJbmLdMA At6NB9dzSPk8wiNMDiro =QOdR -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
Edward Lewis wrote: There's nothing wrong with anyone implementing this. But whether this is a DNSOP WG item rests on how broad the interest is and if there's a need to coordinate for interoperability reasons. Identification of a server is an issue to be handled by a unicast address at the IP layer. Identification of some component within a server is an issue totally depending on internal implementation of the server. I can see nothing left for DNSOP WG. 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
Quoting Paul Hoffman paul.hoff...@vpnc.org: On Sep 25, 2011, at 1:53 PM, xun...@isi.edu wrote: Sure, thanks for the advise. We can add _ for instance_id and node_id also, _instance_id._ns-diagnostics.$ORIGIN, _node_id._ns-diagnostics.$ORIGIN Sounds good. Yes, the is not the first time we have this terminology problem. node is defined in RFC 4786 while RFC 4892 use instance. We only have a slight explanation of the two in Section 1 the first goal, The mechanism should be able to identify both specific anycast instances (a specific computer running anycast), and also anycast nodes (defined in RFC 4786 [RFC4786] as the topology location where multiple instances may run) but we should definitely give a clear differentiation at the beginning. Ah, I missed that. Maybe a two-paragraph terminology section would make it more obvious for the too-quick like me... Sure, we will do that. --Paul Hoffman ___ 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
Re: [DNSOP] A new appoarch for identifying anycast name server instance
I'm forwarding a mail from Xun as he mistakenly send it not to the list but to me. Masataka Ohta Original Message Quoting Masataka Ohta mo...@necom830.hpcl.titech.ac.jp: xun...@isi.edu wrote: One result of that work is that we think additional information would make anycast dianosis much easier--- How can it be made much easier? All the anycast servers should have unicast addresses to be used for zone transfer, which can be used for most, if not all, diagnostics. So, what diagnosis, are you considering, becomes possible only by your proposal? I think the initial e-mail text we sent is short and incomplete, our draft proposal is clearer. The particular diagnostic that our proposal tries to provide is to tell which one of a set of anycast servers responses to a DNS query. Unicast address of an anycast server is very useful for many diagnostics, however, as DNS queries is sent to the anycast address and the path is decided by routing system, knowing the set of unicast address may not sufficient to answer that question. For the diagnosis that becomes possible ONLY by our proposal, to our knowledge, is the identification of anycast nodes in catchments other than where the querier is currently located. One example utility might be to tell which authoritative name server provides answers to a recursive name server. Also, I'm afraid a fantastic idea of anycast node of RFC4892 is a result of broken specification of IPv6 anycast (yes, IPv6 is broken in several ways), which assumes there should be more than one anycast servers sharing an anycast address on a link. Anyway, we can't discuss anything meaningful about anycast node, because its definition is too fuzzy. I am not sure if I correctly understand your statement. Did you mean multiple anycast servers sharing a same path is only for IPv6? If so, I don't agree. We know that at least F root has multiple anycast servers in a site (which we think has same meaning to RFC4786 defined anycast node) for address 192.5.5.241. And I believe a load-balancing mechanism is reasonable for anycasted authoritative name servers. So anycast node should not be discarded at this time. As the terminology is very confusing with node of domain tree and node of IPv6, the entire idea of anycast node should better be silently ignored. 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
Thank you very much, Masataka! Quoting Masataka Ohta mo...@necom830.hpcl.titech.ac.jp: I'm forwarding a mail from Xun as he mistakenly send it not to the list but to me. Masataka Ohta Original Message Quoting Masataka Ohta mo...@necom830.hpcl.titech.ac.jp: xun...@isi.edu wrote: One result of that work is that we think additional information would make anycast dianosis much easier--- How can it be made much easier? All the anycast servers should have unicast addresses to be used for zone transfer, which can be used for most, if not all, diagnostics. So, what diagnosis, are you considering, becomes possible only by your proposal? I think the initial e-mail text we sent is short and incomplete, our draft proposal is clearer. The particular diagnostic that our proposal tries to provide is to tell which one of a set of anycast servers responses to a DNS query. Unicast address of an anycast server is very useful for many diagnostics, however, as DNS queries is sent to the anycast address and the path is decided by routing system, knowing the set of unicast address may not sufficient to answer that question. For the diagnosis that becomes possible ONLY by our proposal, to our knowledge, is the identification of anycast nodes in catchments other than where the querier is currently located. One example utility might be to tell which authoritative name server provides answers to a recursive name server. Also, I'm afraid a fantastic idea of anycast node of RFC4892 is a result of broken specification of IPv6 anycast (yes, IPv6 is broken in several ways), which assumes there should be more than one anycast servers sharing an anycast address on a link. Anyway, we can't discuss anything meaningful about anycast node, because its definition is too fuzzy. I am not sure if I correctly understand your statement. Did you mean multiple anycast servers sharing a same path is only for IPv6? If so, I don't agree. We know that at least F root has multiple anycast servers in a site (which we think has same meaning to RFC4786 defined anycast node) for address 192.5.5.241. And I believe a load-balancing mechanism is reasonable for anycasted authoritative name servers. So anycast node should not be discarded at this time. As the terminology is very confusing with node of domain tree and node of IPv6, the entire idea of anycast node should better be silently ignored. Masataka Ohta ___ 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
[DNSOP] A new appoarch for identifying anycast name server instance
Hi all, Our research group has been looking at assessing anycast usage. (We have a technical report about our early findings at ftp://ftp.isi.edu/isi-pubs/tr-671.pdf if you're interested.) One result of that work is that we think additional information would make anycast dianosis much easier---we'd like to use in-band class-IN TXT records to augment what is done today with class-CHAOS records today (RFC-4892). In discussing our findings and proposed approach with ISC, they recommended we put together an internet-draft that documents our proposal. We have a draft of our proposal with rationale at http://www.isi.edu/~xunfan/research/draft-anycast-diagnostics.txt We'd love to get feedback from the working group, and to know if this sort of diagnosis would be something appropriate for the WG to take up. ___ 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 25, 2011, at 11:26 AM, xun...@isi.edu wrote: We have a draft of our proposal with rationale at http://www.isi.edu/~xunfan/research/draft-anycast-diagnostics.txt Instead of ns-diagnostics, using _ns-diagnostics would be much better. The _ at the beginning of a label is not a hostname meme seems to be accepted by nearly everyone in the DNS world. You do not define the difference between an instance and a node, and RFC 4892 doesn't define node. Either clearly differentiate them here, or maybe just get rid of node. --Paul Hoffman ___ 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 Sun, Sep 25, 2011 at 12:19 PM, Paul Hoffman paul.hoff...@vpnc.orgwrote: On Sep 25, 2011, at 11:26 AM, xun...@isi.edu wrote: We have a draft of our proposal with rationale at http://www.isi.edu/~xunfan/research/draft-anycast-diagnostics.txt Instead of ns-diagnostics, using _ns-diagnostics would be much better. The _ at the beginning of a label is not a hostname meme seems to be accepted by nearly everyone in the DNS world. Sure, thanks for the advise. We can add _ for instance_id and node_id also, _instance_id._ns-diagnostics.$ORIGIN, _node_id._ns-diagnostics.$ORIGIN You do not define the difference between an instance and a node, and RFC 4892 doesn't define node. Either clearly differentiate them here, or maybe just get rid of node. Yes, the is not the first time we have this terminology problem. node is defined in RFC 4786 while RFC 4892 use instance. We only have a slight explanation of the two in Section 1 the first goal, The mechanism should be able to identify both specific anycast instances (a specific computer running anycast), and also anycast nodes (defined in RFC 4786 [RFC4786] as the topology location where multiple instances may run) but we should definitely give a clear differentiation at the beginning. Thanks! --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop On Sun, Sep 25, 2011 at 12:19 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Sep 25, 2011, at 11:26 AM, xun...@isi.edu wrote: We have a draft of our proposal with rationale at http://www.isi.edu/~xunfan/research/draft-anycast-diagnostics.txt Instead of ns-diagnostics, using _ns-diagnostics would be much better. The _ at the beginning of a label is not a hostname meme seems to be accepted by nearly everyone in the DNS world. You do not define the difference between an instance and a node, and RFC 4892 doesnt define node. Either clearly differentiate them here, or maybe just get rid of node. --Paul Hoffman ___ 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
Re: [DNSOP] A new appoarch for identifying anycast name server instance
On Sep 25, 2011, at 1:53 PM, xun...@isi.edu wrote: Sure, thanks for the advise. We can add _ for instance_id and node_id also, _instance_id._ns-diagnostics.$ORIGIN, _node_id._ns-diagnostics.$ORIGIN Sounds good. Yes, the is not the first time we have this terminology problem. node is defined in RFC 4786 while RFC 4892 use instance. We only have a slight explanation of the two in Section 1 the first goal, The mechanism should be able to identify both specific anycast instances (a specific computer running anycast), and also anycast nodes (defined in RFC 4786 [RFC4786] as the topology location where multiple instances may run) but we should definitely give a clear differentiation at the beginning. Ah, I missed that. Maybe a two-paragraph terminology section would make it more obvious for the too-quick like me... --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A new appoarch for identifying anycast name server instance
xun...@isi.edu wrote: One result of that work is that we think additional information would make anycast dianosis much easier--- How can it be made much easier? All the anycast servers should have unicast addresses to be used for zone transfer, which can be used for most, if not all, diagnostics. So, what diagnosis, are you considering, becomes possible only by your proposal? Also, I'm afraid a fantastic idea of anycast node of RFC4892 is a result of broken specification of IPv6 anycast (yes, IPv6 is broken in several ways), which assumes there should be more than one anycast servers sharing an anycast address on a link. Anyway, we can't discuss anything meaningful about anycast node, because its definition is too fuzzy. As the terminology is very confusing with node of domain tree and node of IPv6, the entire idea of anycast node should better be silently ignored. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
