- NZNOG - lists.nznog.org

Bruce Schneier Event Invitation
by NZITF Info 11 Apr '12

11 Apr '12

Good Afternoon, The New Zealand Internet Task Force, NZITF, would like to invite NZNOG members to attend a public lecture by Bruce Schneier. Bruce will be talking about the topic of his latest book Liars and Outliers. For those of you unable to attend this event in person, it will be streamed live at www.nzitf.org.nz. This event will be held from 10:00am – 12:00pm on Tuesday 1 May 2012 at the St James Theatre, 63-95 Courtenay Place, Wellington. Doors will open at 9:30am and following the lecture there will be a book signing by Bruce, and Capital books will be onsite with copies of his books available for purchase as well. There will also be tea and coffee and a chance to network with others from the industry. Thanks to the sponsorship by InternetNZ and Telecom New Zealand this event is free to attend, however due to the expected interest RSVP’s are essential. Please email rsvp(a)nzitf.org.nz no later than 12pm Thursday 26 April 2012. Registration will be confirmed by email. Please include the names of attendees, a contact email, and their organisation. Please find the event flyer attached. Regards, NZITF. New Zealand Internet Task Force PO Box 11-881 Manners Street Wellington 6142 New Zealand Fax: +64 4 495 2115 Web: www.nzitf.org.nz

1 0

Conference wifi usage?
by Richard Hector 11 Apr '12

11 Apr '12

Hi all, Hopefully this isn't too off-topic, or too vague ... If one was running wifi for a conference - not for IT types - does anyone have an idea what the likely usage of wifi by participants would be, on a per-user per-day basis? There will probably be beer, but unfortunately I can't invite you all. Is mentioning that necessary to get past the filter? Thanks, Richard

1 1

Re: [nznog] CAIDA's 2012 IPv6 survey -- need network operators to fill out
by Nevil Brownlee 09 Apr '12

09 Apr '12

Hi all: CAIDA have a project that needs some real data on IPv6 deployment, and are running a survey to gather it. Operators, when you have a spare moment (!), it would help CAIDA a lot if you'd fill in the survey, as described below ... Thanks, Nevil (U Auckland | CAIDA) ----- Forwarded message from Amogh Dhamdhere <amogh(a)cc.gatech.edu> ----- Subject: Re: CAIDA's 2012 IPv6 survey -- need network operators to fill out From: Amogh Dhamdhere <amogh(a)cc.gatech.edu> Date: Wed, 4 Apr 2012 15:41:19 -0700 Cc: nanog(a)nanog.org To: k claffy <kc(a)caida.org> X-Mailer: Apple Mail (2.1251.1) Hello folks, Thanks much to those of you who already completed our IPv6 deployment survey. We forgot to mention in the first email (though it's on the survey URL) that we are offering a free iPad to a randomly chosen survey respondent. Hopefully this is an additional incentive for more of you to fill out the survey :) The survey URL once again: http://www.surveygizmo.com/s3/749797/ipv6survey We will keep the survey open until April 20, 2012. Please let us know if you have questions/comments, or if you can chat with us for follow-up questions outside the survey. Thanks, Amogh, kc, Emile On Mar 13, 2012, at 2:56 PM, k claffy wrote: > > > [direct link to IPv6 operational deployment [plans] survey > if you don't need background: > http://www.surveygizmo.com/s3/749797/ipv6survey > ] > > hello folks, > > we're trying to do some quantitative modeling of > the IPv4->IPv6 transition, including the impact of > IPv4 markets on likely future trajectories, but > really need some empirical data to parametrize our model. > with much help from many patient reviewers of the questions, > we finally have a survey ready for operators to fill out. > > below i'll give an extremely terse description of the model > just to give you an idea of why we need this granularity. > there are another 10 dense pages describing the model pending > peer review at NSF, which i can send to anyone interested in > giving us feedback on it. but it's not necessary for > responding to the survey. also note the checkbox to > indicate you're amenable to further followup questions. > survey will be available till 12 april 2012. > (or tell us if you want to fill it out but need more time.) > > survey link, again: > http://www.surveygizmo.com/s3/749797/ipv6survey > > thanks much, > k, amogh, emile > > ------------------------------ > > Most prior work on modeling the adoption of new technologies assumed a > binary decision at the organization level -- in the context of > IPv6, this decision means switching completely to IPv6 or not at > all. We propose to account for the fact that an organization may > deploy IPv6 incrementally in its network, meaning that it will > continue to have both IPv4 and IPv6 space. A key aspect of our model > is that instead of a binary state per organization, we work at the > granularity of devices, which are entities that need to be > assigned IP addresses. We consider a device to correspond to a single > instance of an IP addressing need, which typically corresponds to an > interface. Though there can be multiple interfaces (``devices'') on > the same computer/router, and multiple addresses (``virtual > interfaces'') on a single interface, we will model each need for an > independent IP address as an independent device. We define device > classes based on the nature of addresses used to number those devices, > e.g., public IPv4, IPv6, dual-stack-NATv4, dual-stack-public-IPv4, etc. > We model the network growth requirements of each network in terms > of the number of additional devices in that network that need to > be configured in one of these device classes. > > ... (then we catalog a list of costs and incentives associated with the > decision to adopt IPv6 or satisfy one's addressing needs with IPv4-based > technologies. costs parameters include the costs of IPv4 addresses, NAT > deployment, renumbering, and translation between IPv4 and IPv6. we will > also try to model incentives such as policies and regulations.) > > We will then model two separate decision processes for a network, based > on whether it seeks to add new devices (to expand its network, provision > for new customers, deploy new services, etc.), or whether it seeks to > optimize the numbering of its existing devices from among the five > device classes defined previously. The latter operation may be necessary > if external factors and costs have changed such that the network could > substantially lower its costs by numbering its devices differently. We > want to structure the model (based on feedback from opsfolk like you) > to capture both initial costs as well as ongoing operational costs of > supporting a given configuration of devices for a specified window > following the decision. Iteration of the decision process continues > for each network until we reach a state where no network has the incentive > to change the numbering of its devices, which represents the equilibrium. > .... > ----- End forwarded message ----- -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand

1 0

AusNOG 2012 Call For Presentations
by Matthew Moyle-Croft 08 Apr '12

08 Apr '12

Call for presentations for AusNOG 2012 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Langham Hotel **Melbourne** 6 & 7 September, 2012 Notes =-=-=- The AusNOG organisers have decided to change the name of the conference to reflect the year instead of the number of the event. So this year's conference is going to be known as AusNOG 2012. It's hoped this will remove some confusion. AusNOG 2012 is being held in Melbourne for the first time. The organisers encourage Melbourne based network operators, especially those that have not previously attended an AusNOG, will take advantage of this opportunity to not only attend the meeting but also present! Topics =-=-=-= Internet operations can be a broad topic and the presentation selection committee will be short-listing presentations in the following focus areas: * Improving the redundancy/resiliency/sustainability of your network * Making leaps in service or network availability * Taking the network operations BCP to the next level * Using 'offline' communications tools to keep the network working * How technology is changing network architectures * Evolution in network architectures and scaling issues Other topics which are of interest to the network operator community are also welcome at AusNOG 2012. Naturally, presentations of a marketing nature are not welcome at this technical event. Notes to presenters =-=-=-=-=-=-=-=-=-= Preference will be given to presentations that result in actual operational outcomes. Session speakers should be prepared to present for 30 minutes. Keynote speakers will be expected to present for 45 minutes to 1 hour. Short presentations of strong operational content are also acceptable. Once the final slides are submitted, changes will only be permitted where the presentation requires the most up to date information or data. By submitting a presentation for consideration in the AusNOG 2012 programme, and if selected the presenter will allow AusNOG to: * Take photographs of the presentation and presenter. * Record and rebroadcast video and audio of the presentation and presenter. * Redistribute, the presentation slides, audio, video, and photographs electronically, on the AusNOG website, or otherwise but leaving all intellectual property in the hands of presenter or rightful property holder where possible[1]. Deadlines =-=-=-=-=- 01 June: Submission of presentation title, presentation description (300 words), and presenter biography (200-400 words) 15 July: Presenters notified of their acceptance status as an AusNOG 2012 presentation. August 29: Submission of final presentation slides as Portable Document Format (pdf), PowerPoint, or Keynote. Provision of a recent digital photograph (<500k) of the presenter. All submissions must be sent to organisers at ausnog.net. A separate call for lightning talks will be made closer to the AusNOG 2012 event [1]: AusNOG accepts that some speakers are unable to allow us to archive their presentation due to company or corporate policy, and if the situation arises AusNOG will delete all copies in its possession after the presentation.

1 0

NZRR Route Registry Update
by NZRR Database Notifications 03 Apr '12

03 Apr '12

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES6:AS42 descr: Route set advertised to AS9439 by PCH - AS42 mp-members: 2001:478:9200:0:0:0:0:0/48 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: indiver(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120404 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES6:AS42 descr: Route set advertised to AS9439 by Citylink on behalf of PCH - AS42 mp-members: 2001:478:9200:0:0:0:0:0/48^48-64, 2001:500:14:0:0:0:0:0/48^48-64, 2001:500:15:0:0:0:0:0/48^48-64, 2001:500:40:0:0:0:0:0/48^48-64, 2001:500:40:0:0:0:0:0/48^48-64, 2001:500:41:0:0:0:0:0/48^48-64, 2001:500:41:0:0:0:0:0/48^48-64, 2001:500:42:0:0:0:0:0/48^48-64, 2001:500:42:0:0:0:0:0/48^48-64, 2001:500:43:0:0:0:0:0/48^48-64, 2001:500:43:0:0:0:0:0/48^48-64, 2001:500:44:0:0:0:0:0/48^48-64, 2001:500:44:0:0:0:0:0/48^48-64, 2001:500:45:0:0:0:0:0/48^48-64, 2001:500:45:0:0:0:0:0/48^48-64, 2001:500:46:0:0:0:0:0/48^48-64, 2001:500:46:0:0:0:0:0/48^48-64, 2001:500:47:0:0:0:0:0/48^48-64, 2001:500:47:0:0:0:0:0/48^48-64, 2001:500:48:0:0:0:0:0/48^48-64, 2001:500:48:0:0:0:0:0/48^48-64, 2001:500:49:0:0:0:0:0/48^48-64, 2001:500:49:0:0:0:0:0/48^48-64, 2001:500:4A:0:0:0:0:0/48^48-64, 2001:500:4B:0:0:0:0:0/48^48-64, 2001:500:4C:0:0:0:0:0/48^48-64, 2001:500:4D:0:0:0:0:0/48^48-64, 2001:500:4E:0:0:0:0:0/48^48-64, 2001:500:4F:0:0:0:0:0/48^48-64, 2001:500:4A:0:0:0:0:0/48^48-64, 2001:500:4B:0:0:0:0:0/48^48-64, 2001:500:4C:0:0:0:0:0/48^48-64, 2001:500:4D:0:0:0:0:0/48^48-64, 2001:500:4E:0:0:0:0:0/48^48-64, 2001:500:4F:0:0:0:0:0/48^48-64, 2001:500:50:0:0:0:0:0/48^48-64, 2001:500:51:0:0:0:0:0/48^48-64, 2001:500:52:0:0:0:0:0/48^48-64, 2001:500:53:0:0:0:0:0/48^48-64, 2001:500:54:0:0:0:0:0/48^48-64, 2001:500:55:0:0:0:0:0/48^48-64, 2001:500:56:0:0:0:0:0/48^48-64, 2001:500:7D:0:0:0:0:0/48^48-64, 2001:500:83:0:0:0:0:0/48^48-64, 2001:500:8C:0:0:0:0:0/48^48-64, 2001:500:A4:0:0:0:0:0/48^48-64, 2001:500:A5:0:0:0:0:0/48^48-64, 2001:503:7BBB:0:0:0:0:0/48^48-64, 2001:503:8028:0:0:0:0:0/48^48-64, 2001:503:A124:0:0:0:0:0/48^48-64, 2001:503:D1AE:0:0:0:0:0/48^48-64, 2001:678:28:0:0:0:0:0/48^48-64, 2001:678:3:0:0:0:0:0/48^48-64, 2001:678:4C:0:0:0:0:0/48^48-64, 2001:678:60:0:0:0:0:0/48^48-64 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dylan(a)citylink.c.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120404 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 03 Apr '12

03 Apr '12

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES6:AS3856 descr: Route set advertised to AS9439 by PCH - AS3856 mp-members: 2001:478:9200:0:0:0:0:0/48 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: indiver(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120404 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES6:AS3856 descr: Route set advertised to AS9439 by Citylink on behalf of PCH - AS3856 mp-members: 2001:478:9200:0:0:0:0:0/48^48-64, 2001:500:14:0:0:0:0:0/48^48-64, 2001:500:15:0:0:0:0:0/48^48-64, 2001:500:40:0:0:0:0:0/48^48-64, 2001:500:40:0:0:0:0:0/48^48-64, 2001:500:41:0:0:0:0:0/48^48-64, 2001:500:41:0:0:0:0:0/48^48-64, 2001:500:42:0:0:0:0:0/48^48-64, 2001:500:42:0:0:0:0:0/48^48-64, 2001:500:43:0:0:0:0:0/48^48-64, 2001:500:43:0:0:0:0:0/48^48-64, 2001:500:44:0:0:0:0:0/48^48-64, 2001:500:44:0:0:0:0:0/48^48-64, 2001:500:45:0:0:0:0:0/48^48-64, 2001:500:45:0:0:0:0:0/48^48-64, 2001:500:46:0:0:0:0:0/48^48-64, 2001:500:46:0:0:0:0:0/48^48-64, 2001:500:47:0:0:0:0:0/48^48-64, 2001:500:47:0:0:0:0:0/48^48-64, 2001:500:48:0:0:0:0:0/48^48-64, 2001:500:48:0:0:0:0:0/48^48-64, 2001:500:49:0:0:0:0:0/48^48-64, 2001:500:49:0:0:0:0:0/48^48-64, 2001:500:4A:0:0:0:0:0/48^48-64, 2001:500:4B:0:0:0:0:0/48^48-64, 2001:500:4C:0:0:0:0:0/48^48-64, 2001:500:4D:0:0:0:0:0/48^48-64, 2001:500:4E:0:0:0:0:0/48^48-64, 2001:500:4F:0:0:0:0:0/48^48-64, 2001:500:4A:0:0:0:0:0/48^48-64, 2001:500:4B:0:0:0:0:0/48^48-64, 2001:500:4C:0:0:0:0:0/48^48-64, 2001:500:4D:0:0:0:0:0/48^48-64, 2001:500:4E:0:0:0:0:0/48^48-64, 2001:500:4F:0:0:0:0:0/48^48-64, 2001:500:50:0:0:0:0:0/48^48-64, 2001:500:51:0:0:0:0:0/48^48-64, 2001:500:52:0:0:0:0:0/48^48-64, 2001:500:53:0:0:0:0:0/48^48-64, 2001:500:54:0:0:0:0:0/48^48-64, 2001:500:55:0:0:0:0:0/48^48-64, 2001:500:56:0:0:0:0:0/48^48-64, 2001:500:7D:0:0:0:0:0/48^48-64, 2001:500:83:0:0:0:0:0/48^48-64, 2001:500:8C:0:0:0:0:0/48^48-64, 2001:500:A4:0:0:0:0:0/48^48-64, 2001:500:A5:0:0:0:0:0/48^48-64, 2001:503:7BBB:0:0:0:0:0/48^48-64, 2001:503:8028:0:0:0:0:0/48^48-64, 2001:503:A124:0:0:0:0:0/48^48-64, 2001:503:D1AE:0:0:0:0:0/48^48-64, 2001:678:28:0:0:0:0:0/48^48-64, 2001:678:3:0:0:0:0:0/48^48-64, 2001:678:4C:0:0:0:0:0/48^48-64, 2001:678:60:0:0:0:0:0/48^48-64 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dylan(a)citylink.c.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120404 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 03 Apr '12

03 Apr '12

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS3856 descr: advertised to AS9439 by Packet Clearing House - AS3856 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.0/23^23-29, 206.220.228.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050219 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS3856 descr: advertised to AS9439 by Citylink on behalf of PCH - AS3856 members: 74.80.64.0/18^18-29, 131.161.128.0/18^18-29, 63.246.32.0/20^20-29, 64.185.240.0/20^20-29, 66.96.112.0/20^20-29, 66.102.32.0/20^20-29, 66.185.112.0/20^20-29, 67.158.48.0/20^20-29, 69.10.176.0/20^20-29, 70.40.0.0/20^20-29, 72.0.48.0/20^20-29, 72.42.112.0/20^20-29, 74.63.16.0/20^20-29, 75.127.16.0/20^20-29, 76.191.16.0/20^20-29, 199.249.112.0/20^20-29, 64.78.200.0/21^21-29, 67.22.112.0/21^21-29, 68.65.112.0/21^21-29, 204.14.112.0/21^21-29, 204.61.208.0/21^21-29, 69.166.12.0/22^22-29, 202.7.4.0/22^22-29, 206.220.228.0/22^22-29, 208.67.88.0/22^22-29, 68.65.126.0/23^23-29, 189.201.244.0/23^23-29, 199.115.156.0/23^23-29, 199.120.142.0/23^23-29, 199.184.182.0/23^23-29, 203.119.88.0/23^23-29, 204.61.216.0/23^23-29, 205.132.46.0/23^23-29, 206.51.254.0/23^23-29, 207.34.6.0/23^23-29, 216.21.2.0/23^23-29, 67.21.37.0/24^24-29, 114.69.222.0/24^24-29, 194.0.17.0/24^24-29, 194.0.27.0/24^24-29, 194.0.36.0/24^24-29, 194.0.42.0/24^24-29, 198.49.1.0/24^24-29, 198.182.167.0/24^24-29, 199.4.137.0/24^24-29, 199.43.132.0/24^24-29, 199.120.141.0/24^24-29, 199.120.144.0/24^24-29, 199.184.181.0/24^24-29, 199.184.184.0/24^24-29, 199.254.171.0/24^24-29, 200.16.98.0/24^24-29, 204.19.119.0/24^24-29, 204.26.57.0/24^24-29, 205.207.155.0/24^24-29, 206.108.113.0/24^24-29, 206.223.122.0/24^24-29, 207.34.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dylan(a)citylink.c.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120404 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 03 Apr '12

03 Apr '12

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS42 descr: advertised to AS9439 by PCH - AS42 members: 74.80.64.0/18^18-29, 199.249.112.0/20^20-29, 203.119.88.0/23^23-29, 204.61.216.0/23^23-29, 198.49.1.0/24^24-29, 198.182.167.0/24^24-29, 199.4.137.0/24^24-29, 199.7.64.0/24^24-29, 199.7.77.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jonny(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20100715 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS42 descr: advertised to AS9439 by Citylink on behalf of PCH - AS42 members: 74.80.64.0/18^18-29, 131.161.128.0/18^18-29, 63.246.32.0/20^20-29, 64.185.240.0/20^20-29, 66.96.112.0/20^20-29, 66.102.32.0/20^20-29, 66.185.112.0/20^20-29, 67.158.48.0/20^20-29, 69.10.176.0/20^20-29, 70.40.0.0/20^20-29, 72.0.48.0/20^20-29, 72.42.112.0/20^20-29, 74.63.16.0/20^20-29, 75.127.16.0/20^20-29, 76.191.16.0/20^20-29, 199.249.112.0/20^20-29, 64.78.200.0/21^21-29, 67.22.112.0/21^21-29, 68.65.112.0/21^21-29, 204.14.112.0/21^21-29, 204.61.208.0/21^21-29, 69.166.12.0/22^22-29, 202.7.4.0/22^22-29, 206.220.228.0/22^22-29, 208.67.88.0/22^22-29, 68.65.126.0/23^23-29, 189.201.244.0/23^23-29, 199.115.156.0/23^23-29, 199.120.142.0/23^23-29, 199.184.182.0/23^23-29, 203.119.88.0/23^23-29, 204.61.216.0/23^23-29, 205.132.46.0/23^23-29, 206.51.254.0/23^23-29, 207.34.6.0/23^23-29, 216.21.2.0/23^23-29, 67.21.37.0/24^24-29, 114.69.222.0/24^24-29, 194.0.17.0/24^24-29, 194.0.27.0/24^24-29, 194.0.36.0/24^24-29, 194.0.42.0/24^24-29, 198.49.1.0/24^24-29, 198.182.167.0/24^24-29, 199.4.137.0/24^24-29, 199.43.132.0/24^24-29, 199.120.141.0/24^24-29, 199.120.144.0/24^24-29, 199.184.181.0/24^24-29, 199.184.184.0/24^24-29, 199.254.171.0/24^24-29, 200.16.98.0/24^24-29, 204.19.119.0/24^24-29, 204.26.57.0/24^24-29, 205.207.155.0/24^24-29, 206.108.113.0/24^24-29, 206.223.122.0/24^24-29, 207.34.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dylan(a)citylink.c.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120404 source: NZRR ------------------------------------------------------------

1 0

PCH & ISC, defenders of the DNS.
by Jonathan Brewer 31 Mar '12

31 Mar '12

For your reading (and viewing) pleasure. http://www.nytimes.com/2012/03/31/technology/with-advance-warning-bracing-f…

7 12

DNS TTL Mangling
by Cameron Bradley 30 Mar '12

30 Mar '12

Hi All, It has come to my attention in the course of moving the DNS for a number of domains that several of the ISPs in this country are mangling the TTLs on records queried by their recursive DNS servers. This behaviour seems to me to be undesirable in situations where someone may have set a record to a shorter TTL to facilitate smoother movement between hosting providers. In the cases I'm seeing, records with TTLs of 14400 are being handed out with TTLs of 86400 by the service provider's servers. How common is this practice, and what are the benefits to the SP from doing it? From my perspective there is also the concern that this, for all intents and purposes appears to be bad practice, and serves to 'break' DNS in itself. Regards, Cameron Bradley

14 29