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
