From brettcarr at ripe.net Mon Jun 4 15:13:30 2007 From: brettcarr at ripe.net (Brett Carr) Date: Mon, 4 Jun 2007 15:13:30 +0200 Subject: [dns-wg] Secondary service on ns.ripe.net for reverse delegations. In-Reply-To: References: <4A6256C3-97B5-4415-BC93-9A2978A01A20@ripe.net> <1673AD5871BB47CF86F3424D389C2F9F@tungemaskin> Message-ID: <604A2A5A-E821-48D7-A7AF-DE6FBD871472@ripe.net> As there was very little response to Jim's posting I am replying (hoping to stimulate further discussion) to his post as an individual interested in DNS and it's stability and after having removed my RIPE NCC hat. On May 14, 2007, at 12:25 PM, Jim Reid wrote: > On May 14, 2007, at 10:20, J?rgen Hovland wrote: > >> I hope this does not become mandatory, only optionally or >> discontinue it. >> A very few amount of LIRs would have to send a zonefile in the >> size of (2^96 ) * 32 * 4 * 20 bytes to ns.ripe.net if it becomes >> mandatory. > > Let's step back. Slave service for reverse zones was something the > NCC has been doing since the dawn of time. In the early days, > connectivity was sometimes erratic, bandwidth was limited, lame > delegations were common and DNS skills were worse than they are > today. It made sense to have a robust and stable DNS platform and > the NCC was in the position to provide that service. That was then. > But this is now. The environment has changed. And there's less > reliance on reverse DNS lookups these days too, even more so in an > IPv6 world. > > So the questions for the WG should be IMO: > > * Is there value in having the NCC provide DNS service for big/ > important reverse zones? > Yes I think that this adds stability to the reverse dns, although I would say it is not as critical as it once was. > * If the answer to the above question is yes, under what > conditions? ie What do we mean by big or important? I would class them as those allocations which encompass large amounts of address space (relatively within ipv4 and ipv6 respectivley) probably taking the largest normal allocation sizes and hitting the nearest bit boundary for reverse delegation would be sufficient. > * If the answer is still yes, should this service be compulsory or > optional? And under what conditions would optional use become > compulsory and vice versa? > I think it should be optional under all circumstances. The knowledge of DNS and it's stability has been greatly improved in the past decade so I don't see any issues with moving to an optional model as opposed to the current mandatory in some cases model. > * If the answer to the orginal question is no, what, if anything, > does the NCC do about things like lame delegations for reverse > zones and the operational problems these cause the NCC? > Well of course the NCC have a seperate project to notify and report on lame delegations expect more news, statistics and notifications (if you have lame servers) within the next six months. -- Brett Carr From markguz at ripe.net Mon Jun 4 16:18:12 2007 From: markguz at ripe.net (Mark Guz) Date: Mon, 04 Jun 2007 16:18:12 +0200 Subject: [dns-wg] RIPE NCC Network Maintenance Thursday 07 June 1700-1900 UTC Message-ID: <46641F24.9090300@ripe.net> [apologies for duplicates] Dear Colleagues, Between 17:00 and 19:00 (UTC/GMT) on Thursday, 07 June 2007, the RIPE NCC will carry out planned maintenance work on our network infrastructure. During this period, www.ripe.net and associated sites, ftp.ripe.net, whois.ripe.net and Authorative DNS services as provided by the RIPE NCC may be interupted. We apologise for any inconvenience that this may cause. If you have any questions about this, please e-mail ops at ripe.net Regards Mark Guz Senior Engineer Operations Department RIPE NCC From Ed.Lewis at neustar.biz Tue Jun 5 17:24:18 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 5 Jun 2007 08:24:18 -0700 Subject: [dns-wg] Secondary service on ns.ripe.net for reverse delegations. In-Reply-To: <604A2A5A-E821-48D7-A7AF-DE6FBD871472@ripe.net> References: <4A6256C3-97B5-4415-BC93-9A2978A01A20@ripe.net> <1673AD5871BB47CF86F3424D389C2F9F@tungemaskin> <604A2A5A-E821-48D7-A7AF-DE6FBD871472@ripe.net> Message-ID: At 3:13 PM +0200 6/4/07, Brett Carr wrote: >As there was very little response to Jim's posting I am replying (hoping to Okay, so if it's discussion you want... >On May 14, 2007, at 12:25 PM, Jim Reid wrote: >> * Is there value in having the NCC provide DNS service for big/important >> reverse zones? This isn't the question I would ask. It's not a matter if yet-another-well-managed slave is a good thing or not (obviously yes), it's a matter if the expense incurred to do this worth it. There's the basic cost benefit question, to which I suspect the answer would be "it's worth it." Then there's the opportunity question of whether the budget of the RIPE NCC is better spent elsewhere. And then there's the question if whether not doing so permits miscreant children for doing bad things. >> * If the answer to the above question is yes, under what conditions? ie What >> do we mean by big or important? I think the answer is yes, so long as Brett Carr hasn't gone insane and moved all of the servers to an X.25 network. Big or important - big is anything over 12 units of any measure and important is "if I use it." >> * If the answer is still yes, should this service be compulsory or >> optional? And under what conditions would optional use become compulsory >> and vice versa? This comes down to the question of how much responsibility does a registry/parent zone assume for its child delegations. In the domain name world, there is little need for the parent to enforce proper operation by the child (in terms of preventing protocol failures, I'm not including "fast flux" issues). However in the reverse map world, I'm not as sure of an answer. What is the experience of having an ISP that fails to maintain their reverse map delegation by customers that want to have their reverse map data available? I.e., once I wanted to have the reverse map for my new v6 (PA) subnet running, but our provider didn't have reverse map service for v6. >> * If the answer to the orginal question is no, what, if anything, does the >> NCC do about things like lame delegations for reverse zones and the >> operational problems these cause the NCC? There are two questions here. Do lame delegations cause problems and what should the RIPE NCC do about it? 5 years ago, there was software that behaved badly in a big way when there was a lame delegation. I don't know if that software is still a problem. Given the experience of lame delegation work I have done, it seems like the problem has mostly "just gone away." Do lame delegations cause operational problems for the RIPE NCC? The only thing I would suspect is an elevated query rate for stuff that belongs to lame servers. I suspect that that could be measured if we wanted. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From dougb at dougbarton.us Tue Jun 5 19:17:17 2007 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 05 Jun 2007 10:17:17 -0700 Subject: [dns-wg] Secondary service on ns.ripe.net for reverse delegations. In-Reply-To: References: <4A6256C3-97B5-4415-BC93-9A2978A01A20@ripe.net> <1673AD5871BB47CF86F3424D389C2F9F@tungemaskin> Message-ID: <46659A9D.1010907@dougbarton.us> Jim Reid wrote: > On May 14, 2007, at 10:20, J?rgen Hovland wrote: > >> I hope this does not become mandatory, only optionally or >> discontinue it. A very few amount of LIRs would have to send a >> zonefile in the size of (2^96 ) * 32 * 4 * 20 bytes to >> ns.ripe.net if it becomes mandatory. Pardon my ignorance, but even if that were the case, what's the issue? I would assume that by the time you become an LIR you should have the bandwidth to do this, and the requisite DNS experience to make it as painless as possible. But is there some hidden cost or problem that I'm missing? > Let's step back. Slave service for reverse zones was something the > NCC has been doing since the dawn of time. In the early days, > connectivity was sometimes erratic, bandwidth was limited, lame > delegations were common and DNS skills were worse than they are > today. That's a scary thought. :) > It made sense to have a robust and stable DNS platform and the NCC > was in the position to provide that service. That was then. But > this is now. The environment has changed. And there's less reliance > on reverse DNS lookups these days too, Less in some areas, but more in others (like mail, for better or worse). I would argue that we're in a weird world where if it doesn't matter, it doesn't matter at all, but if it matters it matters a lot. > even more so in an IPv6 world. I would argue here that this is yet to be seen, given the (sadly) low rate of current IPv6 deployment. > So the questions for the WG should be IMO: > > * Is there value in having the NCC provide DNS service for > big/important reverse zones? I think you're asking the wrong question (although I like Ed's definitions of "big" and "important." :) I would ask, "Is there value in the NCC making slave service for reverse zones available to those who receive allocations from us?" Which sort of sets the stage for the rest of the answers. > * If the answer to the above question is yes, under what conditions? > ie What do we mean by big or important? I think the answer to your first question is no, it should be available to everyone. > * If the answer is still yes, should this service be > compulsory or optional? Optional, always. > And under what conditions would optional > use become compulsory and vice versa? To get closer to answering the spirit of your original question, I don't think there is any value in requiring reverse zones from anyone. If a network operator wants to do a good job of providing reverse DNS, they will. If they don't, they won't, and short of pulling their allocation you can't enforce a mandatory policy anyway. > * If the answer to the orginal question is no, what, if anything, > does the NCC do about things like lame delegations for reverse zones > and the operational problems these cause the NCC? Here's the tricky part. I think it would be a nice service for the NCC to offer, _if_ there are some rudimentary checks in place to make sure that the information is still up to date, and if the zones are dropped when it isn't. My opinion is that providing stale data is worse than providing no data at all, but I know reasonable minds can differ on this point. I'd like to add one more issue indirectly raised by Ed's post. I think he was right to bring up cost in regards to this discussion, more so if you agree with my perspective that this should be an optional service supplied to allocees. But if you assume that the NCC is going to be providing DNS services for something anyway (which of course they are) the marginal cost of adding reverse service for allocations is not zero, but I don't think it's overwhelming either. hth, Doug -- If you're never wrong, you're not trying hard enough From ncc at ripe.net Thu Jun 14 10:30:29 2007 From: ncc at ripe.net (Axel Pawlik) Date: Thu, 14 Jun 2007 10:30:29 +0200 Subject: [dns-wg] RIPE Community Requests that ICANN Signs DNS Root Message-ID: <4670FCA5.6070505@ripe.net> [Apologies for duplicates.] Dear Colleagues, During the RIPE 54 Meeting in Tallinn, Estonia on 7 -11 October, the RIPE DNS Working Group agreed that a formal request should be made to the Internet Corporation for Assigned Names and Numbers (ICANN) for it to sign the DNS root as soon as possible. The working group formulated a statement and asked the RIPE community for endorsement during the closing plenary. The RIPE community unanimously supported this statement and, as a result, a formal letter of request was sent to ICANN. This letter, which includes the statement, can be viewed at: http://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf Regards, Axel Pawlik Managing Director RIPE NCC From Ed.Lewis at neustar.biz Thu Jun 14 14:41:15 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 14 Jun 2007 08:41:15 -0400 Subject: [dns-wg] Archive problems? In-Reply-To: <4670FCA5.6070505@ripe.net> References: <4670FCA5.6070505@ripe.net> Message-ID: Howdy y'all, I was hoping to reference this message from the archives and see that the web page (https://www.ripe.net/ripe/maillists/archives/dns-wg/2007/index.html) stopped on May 24. I count Axel's as the 5th message in my dns-wg mail box that is not in the archives - or at least as reported by the web page. At 10:30 +0200 6/14/07, Axel Pawlik wrote: ... >The working group formulated a statement and asked the RIPE community for >endorsement during the closing plenary. ... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From Ed.Lewis at neustar.biz Thu Jun 14 15:50:52 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 14 Jun 2007 09:50:52 -0400 Subject: [dns-wg] Archive problems? In-Reply-To: References: <4670FCA5.6070505@ripe.net> Message-ID: The "problem" has gone away... At 8:41 -0400 6/14/07, Edward Lewis wrote: >Howdy y'all, > >I was hoping to reference this message from the archives and see >that the web page >(https://www.ripe.net/ripe/maillists/archives/dns-wg/2007/index.html) >stopped on May 24. I count Axel's as the 5th message in my dns-wg >mail box that is not in the archives - or at least as reported by >the web page. > > >At 10:30 +0200 6/14/07, Axel Pawlik wrote: >... >>The working group formulated a statement and asked the RIPE community for >>endorsement during the closing plenary. >... >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-571-434-5468 >NeuStar > >Sarcasm doesn't scale. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale. From markguz at ripe.net Mon Jun 18 14:54:53 2007 From: markguz at ripe.net (Mark Guz) Date: Mon, 18 Jun 2007 14:54:53 +0200 Subject: [dns-wg] RIPE NCC Network Maintenance Wednesday 20 June 17:00 to 19:00 UTC/GMT Message-ID: <4676809D.8050105@ripe.net> [apologies for duplicates] Dear Colleagues, On Wednesday 20/06/2007, between 17:00 and 19:00 (UTC), the RIPE NCC will carry out planned maintenance work on our network infrastructure. This may result in brief interruptions to RIPE NCC services during the posted maintenance window. We apologise for any inconvenience that this may cause. This work is due to planned resilience testing of our network. If you have any questions about this, please send an e-mail to: ops at ripe.net . Regards Mark Guz Senior Engineer RIPE NCC