From anne-marie.eklund-lowinder at iis.se Sat Mar 1 08:59:51 2014 From: anne-marie.eklund-lowinder at iis.se (=?Windows-1252?Q?Anne-Marie_Eklund-L=F6winder?=) Date: Sat, 1 Mar 2014 08:59:51 +0100 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: <5310E99F.9030707@dougbarton.us> References: <75E71F03-24EE-4122-ACEF-0056E9B8B96B@icann.org> <5310E99F.9030707@dougbarton.us> Message-ID: <983F17705339E24699AA251B458249B5D21AA5D309@EXCHANGE2K7.office.nic.se> > -----Ursprungligt meddelande----- > Fr?n: dns-wg-bounces at ripe.net [mailto:dns-wg-bounces at ripe.net] F?r Doug > Barton > Skickat: den 28 februari 2014 20:55 > Till: dns-wg at ripe.net > ?mne: Re: [dns-wg] the seven people who hold the keys to worldwide > internet security > > > +1, although I would have liked to see an explicit refutation of the > drama-inspiring question of whether the key holders can use their keys > to turn off the Internet. :) You know the answer to that already.... :) Of course the keys aren't there to turn it off, just to keep it going! Anne-Marie -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 182 bytes Desc: not available URL: From anne-marie.eklund-lowinder at iis.se Sat Mar 1 09:23:44 2014 From: anne-marie.eklund-lowinder at iis.se (=?Windows-1252?Q?Anne-Marie_Eklund-L=F6winder?=) Date: Sat, 1 Mar 2014 09:23:44 +0100 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: <3A2993EA-7442-4E50-A82C-CF7240CA25FB@rfc1035.com> References: <75E71F03-24EE-4122-ACEF-0056E9B8B96B@icann.org> <20140228190747.GN21395@x28.adm.denic.de> <3A2993EA-7442-4E50-A82C-CF7240CA25FB@rfc1035.com> Message-ID: <983F17705339E24699AA251B458249B5D21AA5D311@EXCHANGE2K7.office.nic.se> It will become a celebrity! It's name is Dust Devil, sounds like any rock star? Anne-Marie > -----Ursprungligt meddelande----- > Fr?n: dns-wg-bounces at ripe.net [mailto:dns-wg-bounces at ripe.net] F?r Jim > Reid > Skickat: den 28 februari 2014 20:30 > Till: Peter Koch > Kopia: dns-wg at ripe.net > ?mne: Re: [dns-wg] the seven people who hold the keys to worldwide > internet security > > On 28 Feb 2014, at 19:07, Peter Koch wrote: > > > There must be something about the vacuum cleaner, though. > > Yeah. I liked that bit. > > Perhaps we can arrange for that vacuum cleaner a leading role at > RIPE68? Assuming of course the Powers That Be will permit such a vital > element of worldwide interweb security to be allowed out in public. > > ;-) > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 182 bytes Desc: not available URL: From anne-marie.eklund-lowinder at iis.se Sat Mar 1 09:25:12 2014 From: anne-marie.eklund-lowinder at iis.se (=?Windows-1252?Q?Anne-Marie_Eklund-L=F6winder?=) Date: Sat, 1 Mar 2014 09:25:12 +0100 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: References: Message-ID: <983F17705339E24699AA251B458249B5D21AA5D312@EXCHANGE2K7.office.nic.se> I agree. They did a very good job, both the journalist and the photographer. It isn't easy to understand for people in common, I mean it obviously isn't easy to understand for more technical savvy people either. :) Anne-Marie > -----Ursprungligt meddelande----- > Fr?n: dns-wg-bounces at ripe.net [mailto:dns-wg-bounces at ripe.net] F?r > Brett Carr > Skickat: den 28 februari 2014 20:20 > Till: Jim Reid > Kopia: RIPE DNS WG > ?mne: Re: [dns-wg] the seven people who hold the keys to worldwide > internet security > > I didn't think it was that bad an article really especially if you try > to view it from the point if view of somebody who knows nothing about > Internet operations and/or DNS/DNSSEC. > > Brett > > > On 28 Feb 2014, at 17:26, "Jim Reid" wrote: > > > > Sigh. Just sigh. > > > > http://www.theguardian.com/technology/2014/feb/28/seven-people-keys- > worldwide-internet-security-web > > > > > > Well at least the article has a photo of Rick Lamb in a suit and tie, > so it's not all bad... :-) > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 182 bytes Desc: not available URL: From Woeber at CC.UniVie.ac.at Sat Mar 1 13:38:31 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Sat, 01 Mar 2014 13:38:31 +0100 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: References: Message-ID: <5311D4C7.4030704@CC.UniVie.ac.at> Brett Carr wrote: > I didn't think it was that bad an article really especially if you try to > view it from the point if view of somebody who knows nothing about Internet ...which leaves me with the question why such a person was invited: Gaining access to their inner sanctum isn't easy, but last month I was invited along to watch the ceremony and meet some of the keyholders... instead of someone who knows at least something about the topic covered. But in the end, business as usual with media people :-( -W > operations and/or DNS/DNSSEC. > > Brett > > >>On 28 Feb 2014, at 17:26, "Jim Reid" wrote: >> >>Sigh. Just sigh. >> >>http://www.theguardian.com/technology/2014/feb/28/seven-people-keys-worldwide-internet-security-web >> >> >>Well at least the article has a photo of Rick Lamb in a suit and tie, so it's not all bad... :-) >> >> > > From ripe-wgs.cs at schiefner.de Sat Mar 1 14:35:51 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Sat, 01 Mar 2014 14:35:51 +0100 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: <5311D4C7.4030704@CC.UniVie.ac.at> References: <5311D4C7.4030704@CC.UniVie.ac.at> Message-ID: <5311E237.3070609@schiefner.de> Hi Wilfried, On 01.03.2014 13:38, Wilfried Woeber wrote: > ...which leaves me with the question why such a person was invited: > > > Gaining access to their inner sanctum isn't easy, but last month I was > invited along to watch the ceremony and meet some of the keyholders... > > > instead of someone who knows at least something about the topic covered. > But in the end, business as usual with media people :-( given it's been a Guardian journalist, I'd assume some relations and side-effects to and from a scoop this paper has recently been key in. Cheers, -C. From jabley at hopcount.ca Sat Mar 1 19:03:51 2014 From: jabley at hopcount.ca (Joe Abley) Date: Sat, 1 Mar 2014 13:03:51 -0500 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: <5311D4C7.4030704@CC.UniVie.ac.at> References: <5311D4C7.4030704@CC.UniVie.ac.at> Message-ID: <4BED697B-7EFF-4AEF-BCF0-549E78B66034@hopcount.ca> On 1 Mar 2014, at 7:38, Wilfried Woeber wrote: > Brett Carr wrote: >> I didn't think it was that bad an article really especially if you try to >> view it from the point if view of somebody who knows nothing about Internet > > ...which leaves me with the question why such a person was invited: > > > Gaining access to their inner sanctum isn't easy, but last month I was > invited along to watch the ceremony and meet some of the keyholders... > Gaining unauthorised access and doing so in a way that is not noticed isn?t easy. Getting authorised access is as easy as asking for it. The only practical limitations in the number of visitors are the size of the room, and the effect of interruptions on a scripted ceremony. There have been lots of non-participatory visitors in key ceremonies more or less since they started happening. The presence of observers strengthens the system; the whole reason for the pomp and circumstance is to encourage people to trust in the process and its execution. Joe From anne-marie.eklund-lowinder at iis.se Sun Mar 2 08:45:27 2014 From: anne-marie.eklund-lowinder at iis.se (=?Windows-1252?Q?Anne-Marie_Eklund-L=F6winder?=) Date: Sun, 2 Mar 2014 08:45:27 +0100 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: <4BED697B-7EFF-4AEF-BCF0-549E78B66034@hopcount.ca> References: <5311D4C7.4030704@CC.UniVie.ac.at> <4BED697B-7EFF-4AEF-BCF0-549E78B66034@hopcount.ca> Message-ID: <983F17705339E24699AA251B458249B5D21AA5D330@EXCHANGE2K7.office.nic.se> > -----Ursprungligt meddelande----- > Fr?n: dns-wg-bounces at ripe.net [mailto:dns-wg-bounces at ripe.net] F?r Joe > Abley > Skickat: den 1 mars 2014 19:04 > Till: Woeber at CC.UniVie.ac.at > Kopia: RIPE DNS WG > ?mne: Re: [dns-wg] the seven people who hold the keys to worldwide > internet security > > > On 1 Mar 2014, at 7:38, Wilfried Woeber wrote: > > > Brett Carr wrote: > > ...which leaves me with the question why such a person was invited: > > > > > > Gaining access to their inner sanctum isn't easy, but last month I > was > > invited along to watch the ceremony and meet some of the > keyholders... > > > > Gaining unauthorised access and doing so in a way that is not noticed > isn?t easy. > > Getting authorised access is as easy as asking for it. The only > practical limitations in the number of visitors are the size of the > room, and the effect of interruptions on a scripted ceremony. > > There have been lots of non-participatory visitors in key ceremonies > more or less since they started happening. The presence of observers > strengthens the system; the whole reason for the pomp and circumstance > is to encourage people to trust in the process and its execution. That is correct. Personally I welcome observers from outside the group of TCR's and ICANN staff. And an observer never gain access to tier 5, which is the cage where the safes are, only authorized people which has a role to play in the ceremony itself. Anne-Marie -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 182 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Sun Mar 2 13:32:18 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Sun, 02 Mar 2014 13:32:18 +0100 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: <4BED697B-7EFF-4AEF-BCF0-549E78B66034@hopcount.ca> References: <5311D4C7.4030704@CC.UniVie.ac.at> <4BED697B-7EFF-4AEF-BCF0-549E78B66034@hopcount.ca> Message-ID: <531324D2.6080308@schiefner.de> Folks - compared to this piece of [insert your preferred 4-letter-word here]: The Internet Is Controlled By 14 People - Business Insider http://www.businessinsider.com/the-internet-is-controlled-by-14-people-2014-3 the Guardian's article is truly a master piece. Ms. Bort would us all have done a favour if she would have restrained herself to just referencing to James Ball's article - without wrapping any further wording around it. Happy Sunday, all: -C. From jim at rfc1035.com Sun Mar 2 15:18:35 2014 From: jim at rfc1035.com (Jim Reid) Date: Sun, 2 Mar 2014 14:18:35 +0000 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: <4BED697B-7EFF-4AEF-BCF0-549E78B66034@hopcount.ca> References: <5311D4C7.4030704@CC.UniVie.ac.at> <4BED697B-7EFF-4AEF-BCF0-549E78B66034@hopcount.ca> Message-ID: <0AFEA916-408D-4ABB-B5E7-24E3203C0AC5@rfc1035.com> On 1 Mar 2014, at 18:03, Joe Abley wrote: > Getting authorised access is as easy as asking for it. The only practical limitations in the number of visitors are the size of the room, and the effect of interruptions on a scripted ceremony. Indeed. This is one of my many gripes about the piece, possibly the biggest one. It's just wrong for the piece to give the impression that this reporter got super-special privileges or there was something magical about observing the ceremony in person. That annoys me. It gives the false impression that this ceremony -- which apparently can turn off the interwebs y'know -- is secret. That helps to spead FUD which is unlikely to be a productive influence on the current discussions on reform of Internet governance and "control of the root". I suppose too the paranoid might well be upset that an untrustworthy reporter -- who could be a terrorist or computer hacker -- is allowed to get anywhere near such a critically important thing. Well, something the paranoid consider "the critically important master switch for the Interwebs". Your tinfoil hats might vary. From lutz at iks-jena.de Mon Mar 3 15:39:36 2014 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Mon, 3 Mar 2014 14:39:36 +0000 (UTC) Subject: [dns-wg] the seven people who hold the keys to worldwide internet security References: <75E71F03-24EE-4122-ACEF-0056E9B8B96B@icann.org> Message-ID: * Kim Davies wrote: > I actually think the story does a great job of making a deathly boring procedure interesting and accessible. It's not only boring. It's expensive, too. The participants have to pay for the fame. From michele at blacknight.com Mon Mar 3 15:52:48 2014 From: michele at blacknight.com (Michele Neylon - Blacknight) Date: Mon, 3 Mar 2014 14:52:48 +0000 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: <20140303145201.7E22633C043@merlin.blacknight.ie> References: <75E71F03-24EE-4122-ACEF-0056E9B8B96B@icann.org> <20140303145201.7E22633C043@merlin.blacknight.ie> Message-ID: What? Doesn't ICANN / IANA cover their expenses?? -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 -----Original Message----- From: dns-wg-bounces at ripe.net [mailto:dns-wg-bounces at ripe.net] On Behalf Of Lutz Donnerhacke Sent: Monday, March 3, 2014 2:40 PM To: dns-wg at ripe.net Subject: Re: [dns-wg] the seven people who hold the keys to worldwide internet security * Kim Davies wrote: > I actually think the story does a great job of making a deathly boring procedure interesting and accessible. It's not only boring. It's expensive, too. The participants have to pay for the fame. From jim at rfc1035.com Mon Mar 3 15:55:52 2014 From: jim at rfc1035.com (Jim Reid) Date: Mon, 3 Mar 2014 14:55:52 +0000 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: References: <75E71F03-24EE-4122-ACEF-0056E9B8B96B@icann.org> Message-ID: On 3 Mar 2014, at 14:39, Lutz Donnerhacke wrote: > * Kim Davies wrote: >> I actually think the story does a great job of making a deathly boring procedure interesting and accessible. > > It's not only boring. It's expensive, too. The participants have to pay for the fame. This might change. ICANN's just finished a consultation on the "people who hold the keys to worldwide internet security". [You might recall Kim asking here for people to respond.] One of the questions that was asked was if funding of TCR's expenses would somehow create a conflict of interest or compromise their integrity. From jim at rfc1035.com Mon Mar 3 15:58:52 2014 From: jim at rfc1035.com (Jim Reid) Date: Mon, 3 Mar 2014 14:58:52 +0000 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: References: <75E71F03-24EE-4122-ACEF-0056E9B8B96B@icann.org> <20140303145201.7E22633C043@merlin.blacknight.ie> Message-ID: On 3 Mar 2014, at 14:52, Michele Neylon - Blacknight wrote: > Doesn't ICANN / IANA cover their expenses?? No. The TCRs must pay their own way or get their employer to pick up the travel costs. IMO this should change. From jabley at hopcount.ca Mon Mar 3 15:59:40 2014 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 3 Mar 2014 14:59:40 +0000 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: References: <75E71F03-24EE-4122-ACEF-0056E9B8B96B@icann.org> <20140303145201.7E22633C043@merlin.blacknight.ie> Message-ID: <0A32D6F6-E272-4E84-B80E-3EED83ADDAB6@hopcount.ca> On 3 Mar 2014, at 14:52, Michele Neylon - Blacknight wrote: > What? Doesn't ICANN / IANA cover their expenses?? They don't, and they have not ever. Some people have made statements in the past suggesting that this is a strength, since there can be no question that ICANN is buying support from TCRs by covering expenses. Others have suggested that this is nonsense, and that TCRs' instructions from ICANN are clearly to criticise the observed processes, a job which they do very well regardless of who is paying for the hotel and air travel costs. ICANN issued a public comment somewhat recently that seems relevant. http://www.icann.org/en/news/public-comment/tcr-dnssec-key-signing-21jan14-en.htm (in particular, question 5). Joe From ripe-wgs.cs at schiefner.de Mon Mar 3 16:00:01 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Mon, 03 Mar 2014 16:00:01 +0100 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: References: <75E71F03-24EE-4122-ACEF-0056E9B8B96B@icann.org> Message-ID: <531498F1.10904@schiefner.de> Hi Lutz, On 03.03.2014 15:39, Lutz Donnerhacke wrote: > * Kim Davies wrote: >> I actually think the story does a great job of making a deathly >> boring procedure interesting and accessible. > > It's not only boring. It's expensive, too. [...] what less expensive procedure with still the same global scope would you have chosen? Best, -C. From michele at blacknight.com Mon Mar 3 16:04:00 2014 From: michele at blacknight.com (Michele Neylon - Blacknight) Date: Mon, 3 Mar 2014 15:04:00 +0000 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: <20140303145907.B7B7D33C04B@merlin.blacknight.ie> References: <75E71F03-24EE-4122-ACEF-0056E9B8B96B@icann.org> <20140303145201.7E22633C043@merlin.blacknight.ie> <20140303145907.B7B7D33C04B@merlin.blacknight.ie> Message-ID: Jim Yeah - I'm shocked that the expenses aren't covered already. I assumed that they were Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Domains http://www.blacknight.co/ http://blog.blacknight.com/ http://www.technology.ie Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 -----Original Message----- From: Jim Reid [mailto:jim at rfc1035.com] Sent: Monday, March 3, 2014 2:59 PM To: Michele Neylon - Blacknight Cc: RIPE DNS WG Subject: Re: [dns-wg] the seven people who hold the keys to worldwide internet security On 3 Mar 2014, at 14:52, Michele Neylon - Blacknight wrote: > Doesn't ICANN / IANA cover their expenses?? No. The TCRs must pay their own way or get their employer to pick up the travel costs. IMO this should change. From leo.vegoda at icann.org Mon Mar 3 16:36:25 2014 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 3 Mar 2014 07:36:25 -0800 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: References: <75E71F03-24EE-4122-ACEF-0056E9B8B96B@icann.org> <20140303145201.7E22633C043@merlin.blacknight.ie> <20140303145907.B7B7D33C04B@merlin.blacknight.ie> Message-ID: <5648A8908CCB564EBF46E2BC904A75B19685073AE7@EXVPMBX100-1.exc.icann.org> Hi, Michele Neylon - Blacknight wrote: [...] > Yeah - I'm shocked that the expenses aren't covered already. I assumed that they were A public consultation that includes a question about that is still open. It is scheduled to close tomorrow. Please consider providing input on that and the other issues: http://www.icann.org/en/news/public-comment/tcr-dnssec-key-signing-21jan14-e n.htm Kind regards, Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5495 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Tue Mar 4 10:05:43 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 04 Mar 2014 10:05:43 +0100 Subject: [dns-wg] the seven people who hold the keys to worldwide internet security In-Reply-To: <531324D2.6080308@schiefner.de> References: <5311D4C7.4030704@CC.UniVie.ac.at> <4BED697B-7EFF-4AEF-BCF0-549E78B66034@hopcount.ca> <531324D2.6080308@schiefner.de> Message-ID: <53159767.4060708@schiefner.de> As a brief follow-up on this: below's Business Insider article got picked by BILD, Germany's largest tabloid, and used as a blueprint for this: ICANN - Der wahre Herrscher ?ber das Internet - Wirtschaft - Bild.de http://www.bild.de/geld/wirtschaft/internet/icann-der-wahre-herrscher-ueber-das-internet-34915002.bild.html [Insert your preferred Service Provider here] Translate only insufficiently covers the partly horrenduously wrong insinuations conveyed by the article. Best, -C. On 02.03.2014 13:32, Carsten Schiefner wrote: > Folks - > > compared to this piece of [insert your preferred 4-letter-word here]: > > The Internet Is Controlled By 14 People - Business Insider > http://www.businessinsider.com/the-internet-is-controlled-by-14-people-2014-3 > > > the Guardian's article is truly a master piece. > > Ms. Bort would us all have done a favour if she would have restrained > herself to just referencing to James Ball's article - without wrapping > any further wording around it. > > Happy Sunday, all: > > -C. From pk at DENIC.DE Sat Mar 8 17:28:49 2014 From: pk at DENIC.DE (Peter Koch) Date: Sat, 8 Mar 2014 17:28:49 +0100 Subject: [dns-wg] Call for contributions: DNS-WG at RIPE68 Message-ID: <20140308162849.GW21395@x28.adm.denic.de> Dear DNS WG, the RIPE meeting in Warsaw is 10 weeks away and we would like to compile a preliminary agenda soon. The DNS WG has been assigned the usual two slots, this time on Wed, 14 May, around lunch. That's 1100-1230 and 1400-1530 in proper figures. Please submit suggestions for presentations to . There's a lot going on in the DNS world and whatever you or your colleagues have done, please consider sharing. We are definitely interested in operational matters, as well, so do not hesitate to submit the "tiny idea" that's explained in five to ten minutes. We will echange information with the OARC program committee for their (our) workshop taking place the weekend before RIPE68 to mitigate collisions (no pun). -Peter (for the wg co-chairs) From becha at ripe.net Mon Mar 10 17:43:37 2014 From: becha at ripe.net (Vesna Manojlovic) Date: Mon, 10 Mar 2014 17:43:37 +0100 Subject: [dns-wg] Announcing changes to DNSMON Message-ID: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> Dear colleagues, The DNS Monitoring Service (DNSMON) has been providing a comprehensive, objective and up-to-date overview of the quality of various global and regional DNS operators' services since 2003. As announced last year by Kaveh Ranjbar in the RIPE Labs article, "Future of RIPE NCC Technical Services", we are in the process of integrating DNSMON within RIPE Atlas, using RIPE Atlas anchors as vantage points. The beta version of the new DNSMON will be available next week, when we will invite you all to try the new service and provide your feedback. In the meantime, we wanted to let you know about some of the changes in the new DNSMON service: New interactive graphs that will allow you to zoom in on interesting details, such as servers, vantage points, and time intervals. Support of TCP queries. Data delay for non-DNSMON users will not be replicated because the measurements performed by RIPE Atlas anchors for the new DNSMON are public measurements. Therefore, the results will also be publicly available. Server-side generated RRD graphs will not be migrated, as the client-side visualisations provide a comparable replacement. However, the existing service will keep working in parallel and decommissioning plans will be discussed with the community. In the meantime, the graphs and data from the old system will still be available. We will publish a RIPE Labs article with more details when the new service becomes available next week. We?re confident the new DNSMON will continue to meet your needs and hope you'll be pleased with the new features. Please stay tuned for more information. Kind regards, Vesna Manojlovic Senior Community Builder Measurements Community Building RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at anuragbhatia.com Sun Mar 16 10:11:30 2014 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sun, 16 Mar 2014 14:41:30 +0530 Subject: [dns-wg] Global Vs local node data in www.root-servers.org Message-ID: Hello everyone! It seems like http://www.root-servers.org/index.html has been updated after quite sometime. Seems like data about local Vs global for many of root servers nodes is incorrect. E.g for Netnod i root all nodes are marked as Global nodes. As far as I understand it means that routes announced by these nodes are announced to transit links as well to make routes visible globally. Likely that is not case here right? Same seems with L root and few others. Do we have webmaster of the project on mailing list? Thanks. -- Anurag Bhatia anuragbhatia.com Linkedin | Twitter Skype: anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From romeo.zwart at ripe.net Sun Mar 16 11:42:12 2014 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Sun, 16 Mar 2014 11:42:12 +0100 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: References: Message-ID: <46374ACF-B029-4B60-A674-358C01FD362F@ripe.net> Hi Anurag, > On 16 mrt. 2014, at 10:11, Anurag Bhatia wrote: > > Hello everyone! > > > It seems like http://www.root-servers.org/index.html has been updated after quite sometime. The root-servers.org site has indeed been updated recently. We will investigate if the mentioned data errors are related to the change. > Seems like data about local Vs global for many of root servers nodes is incorrect. Details of all instances, incl. global vs. local information, are provided directly by individual root-server operators. I will ask the responsible people to verify their instances' details, and if necessary correct these, asap. Kind regards, Romeo > E.g for Netnod i root all nodes are marked as Global nodes. As far as I understand it means that routes announced by these nodes are announced to transit links as well to make routes visible globally. Likely that is not case here right? > > Same seems with L root and few others. Do we have webmaster of the project on mailing list? > > > Thanks. > > -- > > > Anurag Bhatia > anuragbhatia.com > > Linkedin | Twitter > Skype: anuragbhatia.com > > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Sun Mar 16 18:34:10 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 16 Mar 2014 10:34:10 -0700 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: <46374ACF-B029-4B60-A674-358C01FD362F@ripe.net> References: <46374ACF-B029-4B60-A674-358C01FD362F@ripe.net> Message-ID: <5325E092.7080307@dougbarton.us> On 03/16/2014 03:42 AM, Romeo Zwart wrote: > Hi Anurag, > > On 16 mrt. 2014, at 10:11, Anurag Bhatia > wrote: > >> Hello everyone! >> >> >> It seems like http://www.root-servers.org/index.html has been updated >> after quite sometime. > > The root-servers.org site has indeed been > updated recently. We will investigate if the mentioned data errors are > related to the change. Also FYI, a connection to https://www.root-servers.org/ gives an invalid certificate error (*.ripe.net). It would be nice if that site either got its own cert. Doug From anandb at ripe.net Sun Mar 16 18:48:18 2014 From: anandb at ripe.net (Anand Buddhdev) Date: Sun, 16 Mar 2014 18:48:18 +0100 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: <5325E092.7080307@dougbarton.us> References: <46374ACF-B029-4B60-A674-358C01FD362F@ripe.net> <5325E092.7080307@dougbarton.us> Message-ID: <5325E3E2.7030709@ripe.net> On 16/03/2014 18:34, Doug Barton wrote: > Also FYI, a connection to https://www.root-servers.org/ gives an invalid > certificate error (*.ripe.net). It would be nice if that site either got > its own cert. Hi Doug, We're aware of it, and already working on it. There should be a matching certificate in place soon. Regards, Anand Buddhdev RIPE NCC From dougb at dougbarton.us Sun Mar 16 18:55:43 2014 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 16 Mar 2014 10:55:43 -0700 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: <5325E3E2.7030709@ripe.net> References: <46374ACF-B029-4B60-A674-358C01FD362F@ripe.net> <5325E092.7080307@dougbarton.us> <5325E3E2.7030709@ripe.net> Message-ID: <5325E59F.6040207@dougbarton.us> On 03/16/2014 10:48 AM, Anand Buddhdev wrote: > On 16/03/2014 18:34, Doug Barton wrote: > >> Also FYI, a connection to https://www.root-servers.org/ gives an invalid >> certificate error (*.ripe.net). It would be nice if that site either got >> its own cert. > > Hi Doug, > > We're aware of it, and already working on it. There should be a matching > certificate in place soon. Awesome, thanks! Doug From john.bond at icann.org Mon Mar 17 12:39:02 2014 From: john.bond at icann.org (John Bond) Date: Mon, 17 Mar 2014 04:39:02 -0700 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: References: Message-ID: Hello Anurag, On 16/03/14 10:11, "Anurag Bhatia" wrote: >Hello everyone! > >Same seems with L root and few others. Do we have webmaster of the project >on mailing list? L-Root does not make a distinction between local and global. All of our nodes advertise the service supernets *without* the no-export community. We impose no policy on our hosts so they can choose if they want to announce our supernets to there upstreams and if so how. It is our observation that the vast majority if not all of our hosts do announce our supernets to there upstreams. Global and Local nodes are very loosely defined terms. However general consensus of a local node is one that has a desired routing policy which does not allow the service supernets to propagate globally. As we impose no policy we mark all nodes as global. Thanks John -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5079 bytes Desc: not available URL: From jabley at hopcount.ca Mon Mar 17 15:17:56 2014 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 17 Mar 2014 10:17:56 -0400 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: References: Message-ID: On 17 Mar 2014, at 7:39, John Bond wrote: > Global and Local nodes are very loosely defined terms. However general > consensus of a local node is one that has a desired routing policy which > does not allow the service supernets to propagate globally. As we impose > no policy we mark all nodes as global. I think the taxonomy is probably my fault. At least, I thought I invented it when I wrote http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt the pertinent text of which is this: Two classes of node are described in this document: Global Nodes advertise their service supernets such that they are propagated globally through the routing system (i.e. they advertise them for transit), and hence potentially provide service for the entire Internet. Local Nodes advertise their service supernets such that the radius of propagation in the routing system is limited, and hence provide service for a contained local catchment area. Global Nodes provide a baseline degree of proximity to the entire Internet. Multiple global nodes are deployed to ensure that the general availability of the service does not rely on the availability or reachability of a single global node. Local Nodes provide contained regions of optimisation. Clients within the catchment area of a local node may have their queries serviced by a Local Node, rather than one of the Global Nodes. The operational considerations that you mention would have been great for me to think about when I wrote that text (i.e. it's the intention of the originator of the route that's important, not the practical limit to propagation of the route due to the policies of other networks). We did a slightly better job in RFC 4768 (e.g. "in such a way", "potentially"): Local-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is only visible to a subset of the whole routing system. Local Node: an Anycast Node providing service using a Local-Scope Anycast Address. Global-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is potentially visible to the whole routing system. Global Node: an Anycast Node providing service using a Global-Scope Anycast Address. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bmanning at isi.edu Mon Mar 17 15:27:29 2014 From: bmanning at isi.edu (manning bill) Date: Mon, 17 Mar 2014 07:27:29 -0700 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: References: Message-ID: <04727248-C1B3-4F90-90A5-FB789C90ABF6@isi.edu> alas, our service predates Joe?s marvelous text. ?B? provides its services locally to its upstream ISPs. We don?t play routing tricks, impose routing policy, or attempt to influence prefix announcement. /bill Neca eos omnes. Deus suos agnoscet. On 17March2014Monday, at 7:17, Joe Abley wrote: > > On 17 Mar 2014, at 7:39, John Bond wrote: > >> Global and Local nodes are very loosely defined terms. However general >> consensus of a local node is one that has a desired routing policy which >> does not allow the service supernets to propagate globally. As we impose >> no policy we mark all nodes as global. > > I think the taxonomy is probably my fault. At least, I thought I invented it when I wrote > > http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt > > the pertinent text of which is this: > > Two classes of node are described in this document: > > Global Nodes advertise their service supernets such that they are > propagated globally through the routing system (i.e. they > advertise them for transit), and hence potentially provide service > for the entire Internet. > > Local Nodes advertise their service supernets such that the radius of > propagation in the routing system is limited, and hence provide > service for a contained local catchment area. > > Global Nodes provide a baseline degree of proximity to the entire > Internet. Multiple global nodes are deployed to ensure that the > general availability of the service does not rely on the availability > or reachability of a single global node. > > Local Nodes provide contained regions of optimisation. Clients within > the catchment area of a local node may have their queries serviced by > a Local Node, rather than one of the Global Nodes. > > The operational considerations that you mention would have been great for me to think about when I wrote that text (i.e. it's the intention of the originator of the route that's important, not the practical limit to propagation of the route due to the policies of other networks). > > We did a slightly better job in RFC 4768 (e.g. "in such a way", "potentially"): > > Local-Scope Anycast: reachability information for the anycast > Service Address is propagated through a routing system in such a > way that a particular anycast node is only visible to a subset of > the whole routing system. > > Local Node: an Anycast Node providing service using a Local-Scope > Anycast Address. > > Global-Scope Anycast: reachability information for the anycast > Service Address is propagated through a routing system in such a > way that a particular anycast node is potentially visible to the > whole routing system. > > Global Node: an Anycast Node providing service using a Global-Scope > Anycast Address. > > > Joe From jabley at hopcount.ca Mon Mar 17 15:17:56 2014 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 17 Mar 2014 10:17:56 -0400 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: References: Message-ID: On 17 Mar 2014, at 7:39, John Bond wrote: > Global and Local nodes are very loosely defined terms. However general > consensus of a local node is one that has a desired routing policy which > does not allow the service supernets to propagate globally. As we impose > no policy we mark all nodes as global. I think the taxonomy is probably my fault. At least, I thought I invented it when I wrote http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt the pertinent text of which is this: Two classes of node are described in this document: Global Nodes advertise their service supernets such that they are propagated globally through the routing system (i.e. they advertise them for transit), and hence potentially provide service for the entire Internet. Local Nodes advertise their service supernets such that the radius of propagation in the routing system is limited, and hence provide service for a contained local catchment area. Global Nodes provide a baseline degree of proximity to the entire Internet. Multiple global nodes are deployed to ensure that the general availability of the service does not rely on the availability or reachability of a single global node. Local Nodes provide contained regions of optimisation. Clients within the catchment area of a local node may have their queries serviced by a Local Node, rather than one of the Global Nodes. The operational considerations that you mention would have been great for me to think about when I wrote that text (i.e. it's the intention of the originator of the route that's important, not the practical limit to propagation of the route due to the policies of other networks). We did a slightly better job in RFC 4768 (e.g. "in such a way", "potentially"): Local-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is only visible to a subset of the whole routing system. Local Node: an Anycast Node providing service using a Local-Scope Anycast Address. Global-Scope Anycast: reachability information for the anycast Service Address is propagated through a routing system in such a way that a particular anycast node is potentially visible to the whole routing system. Global Node: an Anycast Node providing service using a Global-Scope Anycast Address. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jabley at hopcount.ca Mon Mar 17 16:11:40 2014 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 17 Mar 2014 11:11:40 -0400 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: <04727248-C1B3-4F90-90A5-FB789C90ABF6@isi.edu> References: <04727248-C1B3-4F90-90A5-FB789C90ABF6@isi.edu> Message-ID: <527E0ACC-B700-456E-A844-BF67F9A334DD@hopcount.ca> On 17 Mar 2014, at 10:27, manning bill wrote: > alas, our service predates Joe?s marvelous text. > > ?B? provides its services locally to its upstream ISPs. > We don?t play routing tricks, impose routing policy, or attempt to > influence prefix announcement. In the taxonomy I just shared, that makes the origin nodes of B all "global nodes". To clarify though, I certainly wasn't trying to suggest that the things I described were new or original when I was writing in 2003. Anycast had already been in use for quite some time by a variety of people at that time. It's specifically the terms "local" and "global" in a DNS anycast context that I was apologising for :-) Joe From bmanning at vacation.karoshi.com Mon Mar 17 16:51:03 2014 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 17 Mar 2014 08:51:03 -0700 Subject: [dns-wg] Global Vs local node data in www.root-servers.org In-Reply-To: <527E0ACC-B700-456E-A844-BF67F9A334DD@hopcount.ca> References: <04727248-C1B3-4F90-90A5-FB789C90ABF6@isi.edu> <527E0ACC-B700-456E-A844-BF67F9A334DD@hopcount.ca> Message-ID: <20140317155103.GA17402@vacation.karoshi.com> On Mon, Mar 17, 2014 at 11:11:40AM -0400, Joe Abley wrote: > > On 17 Mar 2014, at 10:27, manning bill wrote: > > > alas, our service predates Joe?s marvelous text. > > > > ?B? provides its services locally to its upstream ISPs. > > We don?t play routing tricks, impose routing policy, or attempt to > > influence prefix announcement. > > In the taxonomy I just shared, that makes the origin nodes of B all "global nodes". > > To clarify though, I certainly wasn't trying to suggest that the things I described were new or original when I was writing in 2003. Anycast had already been in use for quite some time by a variety of people at that time. > > It's specifically the terms "local" and "global" in a DNS anycast context that I was apologising for :-) > > > Joe No apology needed. I was clarifying why "B" is listed as a local node. That it doesn't fit you taxonomy is fine - but it does need an explaination. /bill From BECHA at ripe.net Tue Mar 18 13:58:03 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 18 Mar 2014 13:58:03 +0100 Subject: [dns-wg] The Beta Version of the New DNSMON is Now Available In-Reply-To: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> Message-ID: <532842DB.7000306@ripe.net> Dear colleagues, The DNS Monitoring Service (DNSMON) has been providing a comprehensive, objective and up-to-date overview of the quality of various global and regional DNS operators' services since 2003. We are in the process of integrating DNSMON within RIPE Atlas and the beta version of the new DNSMON is now publicly available: https://atlas.ripe.net/dnsmon We have also published a RIPE Labs article detailing what?s changed in the new DNSMON: https://labs.ripe.net/Members/fatemah_mafi/an-updated-dns-monitoring-service We invite you all to try the new service and provide your feedback. We?re confident that the new DNSMON will continue to meet your needs and hope that you'll be happy with the new features. Please send your comments and questions to the DNS Working Group Mailing List at dns-wg at ripe.net. Kind regards, Vesna Manojlovic Measurements Community Building RIPE NCC From jaap at NLnetLabs.nl Wed Mar 19 11:49:57 2014 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 19 Mar 2014 11:49:57 +0100 Subject: [dns-wg] [dnsmon-user] The Beta Version of the New DNSMON is Now Available In-Reply-To: <532842DB.7000306@ripe.net> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> Message-ID: <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> We invite you all to try the new service and provide your feedback. We?re confident that the new DNSMON will continue to meet your needs and hope that you'll be happy with the new features. It doesn't come anywhere close to the old service. E.g., the functionality of is missing. The UI page is garbled. All in all this is pretty bad. jaap From Brett.Carr at nominet.org.uk Wed Mar 19 11:57:51 2014 From: Brett.Carr at nominet.org.uk (Brett Carr) Date: Wed, 19 Mar 2014 10:57:51 +0000 Subject: [dns-wg] [dnsmon-contact] [dnsmon-user] The Beta Version of the New DNSMON is Now Available In-Reply-To: <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> Message-ID: <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> Jaap, > -----Original Message----- > From: dnsmon-contact-bounces at ripe.net [mailto:dnsmon-contact- > bounces at ripe.net] On Behalf Of Jaap Akkerhuis > Sent: Wednesday, March 19, 2014 10:50 AM > To: Vesna Manojlovic > Cc: ncc-services-wg at ripe.net; dns-wg at ripe.net; RIPE Atlas People; > dnsmon-contact at ripe.net; dnsmon-user at ripe.net; Measurement Analysis and > Tools Working Group > Subject: Re: [dnsmon-contact] [dnsmon-user] The Beta Version of the New > DNSMON is Now Available > > > > We invite you all to try the new service and provide your feedback. > We're confident that the new DNSMON will continue to meet your > needs and > hope that you'll be happy with the new features. > > It doesn't come anywhere close to the old service. E.g., the > functionality of is > missing. > That's what I thought at first but actually it is there it just takes a little finding. Click on the TLD and you will get a list of servers down the left, if you then click on a server you will get something that looks very similar to the old server view. There are two things that I would really like to see: 1. The ability to pull some data out and pull it in to my own monitoring system for a familiar view for our operations engineers. 2. An ability to provide sms/e-mail alerting depending on certain (user definable) conditions. Brett Nominet UK. From Brett.Carr at nominet.org.uk Wed Mar 19 12:02:03 2014 From: Brett.Carr at nominet.org.uk (Brett Carr) Date: Wed, 19 Mar 2014 11:02:03 +0000 Subject: [dns-wg] [dnsmon-contact] [dnsmon-user] The Beta Version of the New DNSMON is Now Available {Sender Address Possibly Forged} In-Reply-To: <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> Message-ID: <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> > -----Original Message----- > From: dns-wg-bounces at ripe.net [mailto:dns-wg-bounces at ripe.net] On > Behalf Of Brett Carr > Sent: Wednesday, March 19, 2014 10:58 AM > To: Jaap Akkerhuis; Vesna Manojlovic > Cc: ncc-services-wg at ripe.net; dns-wg at ripe.net; RIPE Atlas People; > dnsmon-contact at ripe.net; dnsmon-user at ripe.net; Measurement Analysis and > Tools Working Group > Subject: Re: [dns-wg] [dnsmon-contact] [dnsmon-user] The Beta Version > of the New DNSMON is Now Available {Sender Address Possibly Forged} > 2. An ability to provide sms/e-mail alerting depending on certain (user > definable) conditions. To be slightly more specific, https://labs.ripe.net/Members/suzanne_taylor_muzzin/introducing-ripe-atlas-status-checks Something more DNS specific but similar to the above would be very useful. Brett From BECHA at ripe.net Wed Mar 19 12:05:32 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 19 Mar 2014 12:05:32 +0100 Subject: [dns-wg] The Beta Version of the New DNSMON is Now Available In-Reply-To: <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> Message-ID: <532979FC.5080302@ripe.net> Dear Jaap, Brett, I will restrict the reply to the dns-wg list. On 19-mrt.-14 11:57, Brett Carr wrote: > Jaap, > >> -----Original Message----- >> Sent: Wednesday, March 19, 2014 10:50 AM >> To: Vesna Manojlovic >> Subject: Re: [dnsmon-contact] [dnsmon-user] The Beta Version of the New >> DNSMON is Now Available >> >> We invite you all to try the new service and provide your feedback. >> We're confident that the new DNSMON will continue to meet your >> needs and >> hope that you'll be happy with the new features. >> >> It doesn't come anywhere close to the old service. E.g., the >> functionality of is >> missing. >> > > That's what I thought at first but actually it is there it just takes a little finding. Thank you for your feedback - I will take this as a feature request to improve navigation. > There are two things that I would really like to see: > > 1. The ability to pull some data out and pull it in to my own monitoring system > for a familiar view for our operations engineers. For RIPE Atlas, we have developed "status checks" based on pings: https://labs.ripe.net/Members/suzanne_taylor_muzzin/introducing-ripe-atlas-status-checks I will take your comment as a feature request to develop ""Atlas DNS status checks", and I am inviting you and other DNS experts to tell us the details of how these alters should be generated. > 2. An ability to provide sms/e-mail alerting depending on certain (user definable) conditions. Thanks again, I will add it to the list of feature requests. Regards, Vesna From robert at ripe.net Wed Mar 19 12:11:39 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 19 Mar 2014 12:11:39 +0100 Subject: [dns-wg] [ncc-services-wg] [dnsmon-user] The Beta Version of the New DNSMON is Now Available In-Reply-To: <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> Message-ID: <53297B6B.7010500@ripe.net> Dear Jaap, On 2014.03.19. 11:49, Jaap Akkerhuis wrote: > > We invite you all to try the new service and provide your feedback. > We?re confident that the new DNSMON will continue to meet your needs and > hope that you'll be happy with the new features. > > It doesn't come anywhere close to the old service. E.g., the functionality > of is missing. This server view exists in the new implementation too. One can reach it from the zone view, by clicking on the name on a particular server. We prepared for this use case since people are mostly interested in the servers of a (their) particular zone, not an alphabetical list. That said, we can make such a listing page if there's a need for it. > The UI page is garbled. That was an oops, but it is fixed already. Regards, Robert > All in all this is pretty bad. > > > jaap > > From jaap at NLnetLabs.nl Wed Mar 19 12:29:11 2014 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 19 Mar 2014 12:29:11 +0100 Subject: [dns-wg] The Beta Version of the New DNSMON is Now Available In-Reply-To: <532979FC.5080302@ripe.net> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> <532979FC.5080302@ripe.net> Message-ID: <201403191129.s2JBTB1g038733@bela.nlnetlabs.nl> I will restrict the reply to the dns-wg list. OK. >> It doesn't come anywhere close to the old service. E.g., the >> functionality of is >> missing. >> > > That's what I thought at first but actually it is there it just takes a little finding. Thank you for your feedback - I will take this as a feature request to improve navigation. And document things clearly. I'm tired of second guessing what things are supposed to do. The broken UI page didn't help either (although it currently seems fixed). It would be nice to have "server view" and "zone view" being explicitly explained just like "probe view". It'll help novice users. jaap From robert at ripe.net Thu Mar 20 09:49:18 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 20 Mar 2014 09:49:18 +0100 Subject: [dns-wg] RIPE Atlas DNS status checks (was:Beta Version of the New DNSMON...) In-Reply-To: <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> Message-ID: <532AAB8E.9020104@ripe.net> Brett, On 2014.03.19. 12:02, Brett Carr wrote: > There are two things that I would really like to see: > > 1. The ability to pull some data out and pull it in to my own monitoring system for a familiar view for our operations engineers. All the data for DNSMON are collected by RIPE Atlas as ongoing, public DNS measurements. The measurement IDs are exposed in the DNSMON interface ("Show RIPE Atlas measurements" button). There's a related discussion on the RIPE Atlas users' mailing list about an API to get to the *latest* results per measurement, which will come handy if you don't want to download gigs of results every time. >> 2. An ability to provide sms/e-mail alerting depending on certain (user >> definable) conditions. > > To be slightly more specific, > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/introducing-ripe-atlas-status-checks > > Something more DNS specific but similar to the above would be very useful. This is entirely possible. In order to implement it, we'd like to keep the mechanism described in the article, but extend it to support DNS. Still, because determining success/failure of DNS measurements is a bit more tricky than pings, the details need some discussion. I invite all to have that discussion on the MAT-WG mailing list (also on cc now). Regards, Robert > Brett > > > > From jim at rfc1035.com Thu Mar 20 11:21:05 2014 From: jim at rfc1035.com (Jim Reid) Date: Thu, 20 Mar 2014 10:21:05 +0000 Subject: [dns-wg] APIs for accessing DNSMON data In-Reply-To: <532AAB8E.9020104@ripe.net> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> <532AAB8E.9020104@ripe.net> Message-ID: <48C3E808-1B1F-4B10-A7C6-89A6BE4A9261@rfc1035.com> On 20 Mar 2014, at 08:49, Robert Kisteleki wrote: > There's a related discussion on the RIPE Atlas users' mailing list about an > API to get to the *latest* results per measurement, which will come handy if > you don't want to download gigs of results every time. It's a pity Robert that the discussion appears to be confined to that list. I expect many TLD and root operators would be interested in having some way of using DNSMON data to supplement their existing DNS monitoring arrangements. Not all of these will be paying customers for DNSMON or hosting Atlas probes. There may well be other fora too like CENTR or OARC who could have useful contributions to the development of this API. It would be nice if the DNS business could come up with a standard API/data format for this side of thing. OTOH, I can see why that could be considerably harder to achieve than cat-herding. Perhaps we can have the WG discuss this in Warsaw. From Brett.Carr at nominet.org.uk Thu Mar 20 11:33:03 2014 From: Brett.Carr at nominet.org.uk (Brett Carr) Date: Thu, 20 Mar 2014 10:33:03 +0000 Subject: [dns-wg] APIs for accessing DNSMON data In-Reply-To: <48C3E808-1B1F-4B10-A7C6-89A6BE4A9261@rfc1035.com> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> <532AAB8E.9020104@ripe.net> <48C3E808-1B1F-4B10-A7C6-89A6BE4A9261@rfc1035.com> Message-ID: <58DFDDEA-5FE6-4437-B91F-5264400C9C1D@nominet.org.uk> On 20 Mar 2014, at 10:21, Jim Reid wrote: > On 20 Mar 2014, at 08:49, Robert Kisteleki wrote: > >> There's a related discussion on the RIPE Atlas users' mailing list about an >> API to get to the *latest* results per measurement, which will come handy if >> you don't want to download gigs of results every time. > > It's a pity Robert that the discussion appears to be confined to that list. I expect many TLD and root operators would be interested in having some way of using DNSMON data to supplement their existing DNS monitoring arrangements. Not all of these will be paying customers for DNSMON or hosting Atlas probes. There may well be other fora too like CENTR or OARC who could have useful contributions to the development of this API. > > It would be nice if the DNS business could come up with a standard API/data format for this side of thing. OTOH, I can see why that could be considerably harder to achieve than cat-herding. > > Perhaps we can have the WG discuss this in Warsaw. > I think that this would be an excellent use of some time in Warsaw. Brett From robert at ripe.net Thu Mar 20 11:35:22 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 20 Mar 2014 11:35:22 +0100 Subject: [dns-wg] APIs for accessing DNSMON data In-Reply-To: <48C3E808-1B1F-4B10-A7C6-89A6BE4A9261@rfc1035.com> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> <532AAB8E.9020104@ripe.net> <48C3E808-1B1F-4B10-A7C6-89A6BE4A9261@rfc1035.com> Message-ID: <532AC46A.9040206@ripe.net> On 2014.03.20. 11:21, Jim Reid wrote: > On 20 Mar 2014, at 08:49, Robert Kisteleki wrote: > >> There's a related discussion on the RIPE Atlas users' mailing list about an >> API to get to the *latest* results per measurement, which will come handy if >> you don't want to download gigs of results every time. > > It's a pity Robert that the discussion appears to be confined to that list. I expect many TLD and root operators would be interested in having some way of using DNSMON data to supplement their existing DNS monitoring arrangements. Not all of these will be paying customers for DNSMON or hosting Atlas probes. There may well be other fora too like CENTR or OARC who could have useful contributions to the development of this API. > > It would be nice if the DNS business could come up with a standard API/data format for this side of thing. OTOH, I can see why that could be considerably harder to achieve than cat-herding. > > Perhaps we can have the WG discuss this in Warsaw. Jim, I don't really mind where the discussion happens, I'm more interested in making sure that it does happen, with that the interested parties are involved. And I was trying to avoid having multiple discussions on multiple mailing lists so named one: Atlas, because it will be an Atlas feature at the end of the process. Regards, Robert From Woeber at CC.UniVie.ac.at Thu Mar 20 13:31:25 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Thu, 20 Mar 2014 13:31:25 +0100 Subject: [dns-wg] APIs for accessing DNSMON data In-Reply-To: <532AC46A.9040206@ripe.net> References: <77BC1167-29D6-45C1-B380-7C67A8B49621@ripe.net> <532842DB.7000306@ripe.net> <201403191049.s2JAnv8p001190@bela.nlnetlabs.nl> <2485CD86D7C59E4C99BA16B2B5754E2024E6DF@wds-exc2.okna.nominet.org.uk> <2485CD86D7C59E4C99BA16B2B5754E2024E8FF@wds-exc2.okna.nominet.org.uk> <532AAB8E.9020104@ripe.net> <48C3E808-1B1F-4B10-A7C6-89A6BE4A9261@rfc1035.com> <532AC46A.9040206@ripe.net> Message-ID: <532ADF9D.3040502@CC.UniVie.ac.at> Robert Kisteleki wrote: > On 2014.03.20. 11:21, Jim Reid wrote: > >>On 20 Mar 2014, at 08:49, Robert Kisteleki wrote: >> >> >>>There's a related discussion on the RIPE Atlas users' mailing list about an >>>API to get to the *latest* results per measurement, which will come handy if >>>you don't want to download gigs of results every time. >> >>It's a pity Robert that the discussion appears to be confined to that list. I expect many TLD and root operators would be interested in having some way of using DNSMON data to supplement their existing DNS monitoring arrangements. Not all of these will be paying customers for DNSMON or hosting Atlas probes. There may well be other fora too like CENTR or OARC who could have useful contributions to the development of this API. >> >>It would be nice if the DNS business could come up with a standard API/data format for this side of thing. OTOH, I can see why that could be considerably harder to achieve than cat-herding. >> >>Perhaps we can have the WG discuss this in Warsaw. Perhaps a prep discussion from the DNS pov and then a follow-up in MAT on Thursday? Wilfried > Jim, > > I don't really mind where the discussion happens, I'm more interested in > making sure that it does happen, with that the interested parties are > involved. And I was trying to avoid having multiple discussions on multiple > mailing lists so named one: Atlas, because it will be an Atlas feature at > the end of the process. > > Regards, > Robert > > From ben.choy at hkirc.hk Fri Mar 21 04:14:24 2014 From: ben.choy at hkirc.hk (Ben Choy) Date: Fri, 21 Mar 2014 03:14:24 +0000 Subject: [dns-wg] Relative response time graph Message-ID: Hi all, Since this is beta testing I assume this list is where to report possible bug. Looking at Relative response time graph, the limit time check doesn't seems to work, the lower limit is ok, but the high limit doesn't show the correct colour. [hkirc] Benjamin Choy Project Manager (System & Network) Hong Kong Internet Registration Corporation Limited (HKIRC) http://www.hkirc.hk http://?????.?? Hong Kong Domain Name Registration Company Limited (HKDNR) http://www.hkdnr.hk http://????.?? Tel: +852 2319 1313 / Fax: +852 2319 2626 / Direct: +852 2319 3819 / Email: ben.choy at hkirc.hk [cid:image002.png at 01CEAE2D.C3DA7B80] The information in this email is confidential and may be legally privileged. If you are not the intended recipient, please notify the sender immediately and then delete this e-mail entirely. You must not retain, copy, distribute or use this e-mail for any other purpose not intended by this email or disclose any of its content to others. The recipient should check the email and attachment for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. PROTECT OUR ENVIRONMENT - think before printing! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 8783 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 3903 bytes Desc: image002.png URL: From camin at ripe.net Wed Mar 26 11:00:17 2014 From: camin at ripe.net (Chris Amin) Date: Wed, 26 Mar 2014 11:00:17 +0100 Subject: [dns-wg] DNSMON beta update Message-ID: <5332A531.8060504@ripe.net> Hi all, During the alpha phase of the new DNSMON, we sent periodic updates to the alpha testers about new features and bug fixes. For the public beta, we intend to continue in the same vein by announcing on this list, although hopefully we won't spam you too much now that the product is more mature. Since officially going "public" last week, we have made many changes to the widget. In particular gestures and feedback are drastically improved. Specifics include: * a new feature to group servers/anchors has been introduced. Now all the servers are grouped by hostname and all the anchors by country; * improved the time navigation and perception; Moving in time now provides real time feedback for a faster interaction; * the auto update function has been made more robust; * included instructions on how to include DNSMON in your own page (see "Embedding DNSMON in other pages" in the "About DNSMON menu"). URL reminder, in case you need one: https://atlas.ripe.net/dnsmon/ Regards, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2466 bytes Desc: S/MIME Cryptographic Signature URL: From pk at DENIC.DE Thu Mar 27 09:46:44 2014 From: pk at DENIC.DE (Peter Koch) Date: Thu, 27 Mar 2014 09:46:44 +0100 Subject: [dns-wg] sub-/24 "delegation" [2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)] Message-ID: <20140327084644.GO13377@x28.adm.denic.de> Dear DNS WG, people on this list might be interested in one aspect of the proposed policy , , when it comes to (sub-)allocations smaller than /24. Note that BCP10/RFC 2317 is not necessarily the or the only solution to the problem. Also, in the interest of keeping the policy discussion focused, we might want to strictly focus on the reverse mapping on this list and make sure some "sense of the room" as well as all other aspects get discussed on address-policy. -Peter (DNS WG co-chair) ----- Forwarded message from Tore Anderson ----- From: Tore Anderson To: Carsten Schiefner , Rob Evans Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) Date: Thu, 27 Mar 2014 09:34:20 +0100 In-Reply-To: <5333CABF.1070609 at schiefner.de> * Carsten Schiefner > No, not really. I feel this being only loosely coupled at best. My > proposal enables the transfer of allocations of *all* sizes and the > conversion of PI assignments of *all* sizes into allocations. > > Whether sub-allocations can be made from *all* these (new) > allocations or "just" from those being at least a /24 appears as a > separate question to me. Even more so, as the the sub-allocation > mechanism has been applied or used very rarely only so far. > > And having the "one thing at a time" principle in mind: if this > impossibility is of concern to the community, then this should maybe > be handled by a separate policy (modification) proposal. Hi Carsten, I'm just of the opinion that removing one without the other leaves the policy in a counter-intuitive state. To me it would appear appropriate for a proposal titled ?Abandoning the Minimum Allocation Size for IPv4? to remove all flavours of the minimum allocation size, including the one specific for sub-allocations. Besides, one of the two stated reasons for having the minimum sub-allocation size (?[/24] is the smallest prefix length that can be reverse delegated?) is quite simply false, given RFC 2317, and if we also accept the rationale for 2014-01, then we've essentially rejected the other reason too (?allows for a reasonable number of small assignments to be made?). So I'd ask you to consider removing that paragraph as well before going to review phase. Note that since we're still in the discussion phase, doing so doesn't have to slow down the progress of the proposal, you can go straight to review with updated proposal (modifications at a later stage are much more cumbersome). Just my ?.02...your proposal, your call. ;) Tore ----- End forwarded message ----- From zsako at iszt.hu Thu Mar 27 10:58:18 2014 From: zsako at iszt.hu (Janos Zsako) Date: Thu, 27 Mar 2014 10:58:18 +0100 Subject: [dns-wg] sub-/24 "delegation" [2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)] In-Reply-To: <20140327084644.GO13377@x28.adm.denic.de> References: <20140327084644.GO13377@x28.adm.denic.de> Message-ID: <5333F63A.40203@iszt.hu> Dear all, > people on this list might be interested in one aspect of the > proposed policy , > , > when it comes to (sub-)allocations smaller than /24. > Note that BCP10/RFC 2317 is not necessarily the or the only solution to the problem. _Technically_ speaking, in my opinion BCP20/RFC2317 is an acceptable solution. It is a trade off: it increases the number of DNS queries, but it gives a large freedom and independence in managing the reverse address space. As I see it, in fact we are talking about three different cases: 1. allocations made by the NCC (5.1) 2. transfers (5.5) 3. possibly sub-allocations (5.4, still under consideration by Carsten, the author of the proposal) In accordance with BCP20, the "maintainer" of the /24 has to set up and _continue_to_provide_ DNS service in accordance with the RFC for an indefinite period of time to the "user" of the smaller address block. In case 1 above, the NCC can do it without any problems. In case 3, the sub-allocating LIR has strong ties to the other LIR, as it is responsible for the address space anyway. However, in case 2, i.e. in case of transfers, I see a possible problem, as otherwise a business relationship does not necessarily exist between the "seller" and the "buyer" of the address space, once the transfer is approved by the NCC and registered in the database. I think it would be a good idea to include this obligation to provide appropriate DNS services for an indefinite time (possibly for a fee) in the transfer contract itself. Anyway, if someone is asking for a fee for such a service, this will most probably be a further very good deterrent to asking for the transfer of such a small address space. :) Anyway, I think this obligation to provide appropriate DNS services for an indefinite time is not necessarily specific to address space smaller than a /24, as any transfer smaller than a /16 out of an allocation of at least a /16 has a somewhat similar problem. Best regards, Janos > Also, in the interest of keeping the policy discussion focused, > we might want to strictly focus on the reverse mapping on this list and > make sure some "sense of the room" as well as all other aspects > get discussed on address-policy. > > -Peter (DNS WG co-chair) > > ----- Forwarded message from Tore Anderson ----- > > From: Tore Anderson > To: Carsten Schiefner , Rob Evans > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the > Minimum Allocation Size for IPv4) > Date: Thu, 27 Mar 2014 09:34:20 +0100 > In-Reply-To: <5333CABF.1070609 at schiefner.de> > > * Carsten Schiefner > >> No, not really. I feel this being only loosely coupled at best. My >> proposal enables the transfer of allocations of *all* sizes and the >> conversion of PI assignments of *all* sizes into allocations. >> >> Whether sub-allocations can be made from *all* these (new) >> allocations or "just" from those being at least a /24 appears as a >> separate question to me. Even more so, as the the sub-allocation >> mechanism has been applied or used very rarely only so far. >> >> And having the "one thing at a time" principle in mind: if this >> impossibility is of concern to the community, then this should maybe >> be handled by a separate policy (modification) proposal. > > Hi Carsten, > > I'm just of the opinion that removing one without the other leaves the > policy in a counter-intuitive state. To me it would appear appropriate > for a proposal titled ?Abandoning the Minimum Allocation Size for IPv4? > to remove all flavours of the minimum allocation size, including the one > specific for sub-allocations. > > Besides, one of the two stated reasons for having the minimum > sub-allocation size (?[/24] is the smallest prefix length that can be > reverse delegated?) is quite simply false, given RFC 2317, and if we > also accept the rationale for 2014-01, then we've essentially rejected > the other reason too (?allows for a reasonable number of small > assignments to be made?). > > So I'd ask you to consider removing that paragraph as well before going > to review phase. Note that since we're still in the discussion phase, > doing so doesn't have to slow down the progress of the proposal, you can > go straight to review with updated proposal (modifications at a later > stage are much more cumbersome). > > Just my ?.02...your proposal, your call. ;) > > Tore > > > ----- End forwarded message ----- > > From dougb at dougbarton.us Thu Mar 27 17:39:13 2014 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 27 Mar 2014 09:39:13 -0700 Subject: [dns-wg] sub-/24 "delegation" [2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)] In-Reply-To: <5333F63A.40203@iszt.hu> References: <20140327084644.GO13377@x28.adm.denic.de> <5333F63A.40203@iszt.hu> Message-ID: <53345431.5050307@dougbarton.us> On 03/27/2014 02:58 AM, Janos Zsako wrote: > Dear all, > >> people on this list might be interested in one aspect of the >> proposed policy , >> , >> >> when it comes to (sub-)allocations smaller than /24. >> Note that BCP10/RFC 2317 is not necessarily the or the only solution >> to the problem. > > _Technically_ speaking, in my opinion BCP20/RFC2317 is an > acceptable solution. It is a trade off: it increases the number of > DNS queries, It doesn't have to increase the number of DNS queries if the parent slaves the child's zone(s). The parent will have the answer for the first query that arrives from a given resolver, and the child will receive subsequent queries directly. Also see https://dougbarton.us/DNS/2317.html for more thoughts. :) hth, Doug From eosterweil at verisign.com Thu Mar 27 18:00:22 2014 From: eosterweil at verisign.com (Osterweil, Eric) Date: Thu, 27 Mar 2014 17:00:22 +0000 Subject: [dns-wg] sub-/24 "delegation" [2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)] In-Reply-To: <53345431.5050307@dougbarton.us> References: <20140327084644.GO13377@x28.adm.denic.de> <5333F63A.40203@iszt.hu> <53345431.5050307@dougbarton.us> Message-ID: On Mar 27, 2014, at 12:39 PM, Doug Barton wrote: > On 03/27/2014 02:58 AM, Janos Zsako wrote: >> Dear all, >> >>> people on this list might be interested in one aspect of the >>> proposed policy , >>> , >>> >>> when it comes to (sub-)allocations smaller than /24. >>> Note that BCP10/RFC 2317 is not necessarily the or the only solution >>> to the problem. >> >> _Technically_ speaking, in my opinion BCP20/RFC2317 is an >> acceptable solution. It is a trade off: it increases the number of >> DNS queries, > > It doesn't have to increase the number of DNS queries if the parent slaves the child's zone(s). The parent will have the answer for the first query that arrives from a given resolver, and the child will receive subsequent queries directly. Also see > https://dougbarton.us/DNS/2317.html for more thoughts. :) OOC, was any thought given to this approach? http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-01 IIRC, there is a treatise in that draft that relates its proposal to RFC 2317. Eric From zsako at iszt.hu Fri Mar 28 10:30:15 2014 From: zsako at iszt.hu (Janos Zsako) Date: Fri, 28 Mar 2014 10:30:15 +0100 Subject: [dns-wg] sub-/24 "delegation" [2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)] In-Reply-To: References: <20140327084644.GO13377@x28.adm.denic.de> <5333F63A.40203@iszt.hu> <53345431.5050307@dougbarton.us> Message-ID: <53354127.9000509@iszt.hu> Dear Eric, > OOC, was any thought given to this approach? > http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-01 I may be wrong, but my understanding is that this I-D focuses on storing and retrieving information associated with a given (known) IP address range. Such information could be related to BGP routing, IRT and abuse, secure mail servers, etc. The problem I see here if you want to use this naming convention for "traditional" reverse queries is that you have to _know_ the address block you are trying to find information about, before starting the query. In case of a "traditional" reverse query for 192.168.1.1 for example, in order to use the above approach one would have to first query the RIR database (or perhaps some other place?) to find out the assignment the given IP address belongs to (e.g. 192.168.1.0/25) and _then_ we could query something like 1.0.m.1.168.192.in-addr.arpa. Did I misunderstand the I-D? Best regards, Janos > IIRC, there is a treatise in that draft that relates its proposal to RFC 2317. > > Eric