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
[DNSOP] version inspection...Re: A new appoarch for identifying anycast name server instance
At 5:50 -0700 9/28/11, Nicholas Weaver wrote: Just a sampling of some of the version strings we've seen in scanning DNS resolvers and authorities: ... (We have even received abuse complaints for querying for version strings!) I think that hiding the version in a sarcastic way is going too far. I prefer to put in contact xyz for this information. We put in URLs to contact. Version discovery never was part of the protocol, so I wouldn't be inclined to include it. When offering a service though, hiding the unnecessary details is something I've come to appreciate. One of the early lessons in this way came from the days when networks were new things. Working on a multi-building campus and a new thing called fiber we got a spool of fiber coated in red. Not orange, red. The only difference was the color of the outer sheath. Once some of our internal relying parties found out that we had used the red fiber they waged war to get the orange fiber to replace it. Cooler heads prevailed and we swore never again to talk about the color of the fiber sheath in front of others. As far as DNS as a service, I'd rather just have the customer say I can't do this, and this is where I am. Once customers begin to diagnose the situation, they generally set up incorrect expectations. With incorrect expectations comes resentment when the real fix goes in against what they thought should have happened. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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] version inspection...Re: A new appoarch for identifying anycast name server instance
Ed, On Sep 28, 2011, at 7:34 AM, Edward Lewis wrote: As far as DNS as a service, I'd rather just have the customer say I can't do this, and this is where I am. How is a customer to know where they are in the network topology as seen from their ISP (particularly in a world of a myriad of twisty little tunnels, all alike)? Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Whether to meet at IETF83 in Taipei
Dear WG, the next IETF is approaching and your chairs need to decide whether there is a need for face to face meeting in Taipei. We currently see some discussion of new or evolving issues but none of the active documents seem to have pressing open issues that would clearly benefit from a meeting style exchange of arguments. We'd like to revisit this assessment no later than 23:59 UTC Wednesday 5 October, so please help making a reasonable decision on the list before then. Thank you, Stephen and Peter PS: http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF82 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] version inspection...Re: A new appoarch for identifying anycast name server instance
At 8:06 -0700 9/28/11, David Conrad wrote: How is a customer to know where they are in the network topology as seen from their ISP (particularly in a world of a myriad of twisty little tunnels, all alike)? If you ask me +norec: I don't know. The answer to this would require conjecture about a situation which we don't come across in our daily activity. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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
[DNSOP] cross-wg/area review: draft-ietf-geopriv-res-gw-lis-discovery-02.txt
You may have seen a similar request on the dnsext list: we're looking for reviewers for draft-ietf-geopriv-res-gw-lis-discovery-02.txt. http://tools.ietf.org/html/draft-ietf-geopriv-res-gw-lis-discovery-02 If you are able and willing to devote some time and energy on a thorough review of this draft, especially the use of the DNS reverse tree as a hook for service discovery and its applicability in today's (and, for that matter, tomorrow's) environments, please let Stephen and myself know. Regards, Peter ___ 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
