- NZNOG - lists.nznog.org

NZRR Route Registry Update
by NZRR Database Notifications 18 Apr '10

18 Apr '10

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: AS9281:RS-ROUTES:AS9503 descr: advertised to AS9281 by FX Networks - AS9503 members: 130.123.0.0/16^16-29, 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.14.32.0/19^19-29, 112.109.64.0/20^20-29, 114.134.160.0/20^20-29, 119.47.112.0/20^20-29, 124.248.128.0/20^20-29, 202.53.176.0/20^20-29, 202.86.96.0/20^20-29, 202.160.48.0/20^20-29, 210.48.160.0/20^20-29, 112.109.80.0/21^21-29, 117.18.80.0/21^21-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.37.32.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 202.160.112.0/21^21-29, 203.190.208.0/21^21-29, 110.232.144.0/22^22-29, 113.197.64.0/22^22-29, 175.111.100.0/22^22-29, 192.206.152.0/22^22-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 203.99.132.0/22^22-29, 192.206.156.0/23^23-29, 202.36.218.0/23^23-29, 202.46.190.0/23^23-29, 202.49.164.0/23^23-29, 203.84.134.0/23^23-29, 203.217.142.0/23^23-29, 116.90.129.0/24^24-29, 116.90.138.0/24^24-29, 116.90.140.0/24^24-29, 192.88.85.0/24^24-29, 192.88.99.0/24^24-29, 192.105.10.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.8.13.0/24^24-29, 202.12.0.0/24^24-29, 202.12.91.0/24^24-29, 202.20.97.0/24^24-29, 202.27.83.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.221.0/24^24-29, 202.37.93.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.46.188.0/24^24-29, 202.49.106.0/24^24-29, 202.49.168.0/24^24-29, 202.50.247.0/24^24-29, 202.55.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.0/24^24-29, 202.65.161.0/24^24-29, 202.89.57.0/24^24-29, 203.89.178.0/24^24-29, 203.89.181.0/24^24-29, 203.89.187.0/24^24-29, 202.89.43.0/25^25-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: raymond.sayo(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20100306 source: NZRR REPLACED BY: route-set: AS9281:RS-ROUTES:AS9503 descr: advertised to AS9281 by FX Networks - AS9503 members: 130.123.0.0/16^16-29, 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 203.114.128.0/18^18-29, 119.15.0.0/19^19-29, 121.79.192.0/19^19-29, 202.14.32.0/19^19-29, 112.109.64.0/20^20-29, 114.134.160.0/20^20-29, 119.47.112.0/20^20-29, 124.248.128.0/20^20-29, 202.53.176.0/20^20-29, 202.86.96.0/20^20-29, 202.160.48.0/20^20-29, 202.174.160.0/20^20-29, 210.48.160.0/20^20-29, 112.109.80.0/21^21-29, 117.18.80.0/21^21-29, 120.89.80.0/21^21-29, 121.79.224.0/21^21-29, 192.173.16.0/21^21-29, 202.37.32.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 202.160.112.0/21^21-29, 203.190.208.0/21^21-29, 110.232.144.0/22^22-29, 113.197.64.0/22^22-29, 140.200.248.0/22^22-29, 175.111.100.0/22^22-29, 192.206.152.0/22^22-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 203.99.132.0/22^22-29, 192.206.156.0/23^23-29, 202.36.214.0/23^23-29, 202.36.218.0/23^23-29, 202.46.190.0/23^23-29, 202.49.164.0/23^23-29, 202.65.160.0/23^23-29, 203.84.134.0/23^23-29, 203.217.142.0/23^23-29, 116.90.129.0/24^24-29, 116.90.138.0/24^24-29, 116.90.140.0/24^24-29, 192.88.85.0/24^24-29, 192.88.99.0/24^24-29, 192.105.10.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.138.251.0/24^24-29, 192.195.219.0/24^24-29, 202.8.13.0/24^24-29, 202.12.0.0/24^24-29, 202.12.91.0/24^24-29, 202.20.97.0/24^24-29, 202.27.83.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.221.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.46.188.0/24^24-29, 202.49.106.0/24^24-29, 202.49.168.0/24^24-29, 202.50.247.0/24^24-29, 202.55.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.0/24^24-29, 202.89.57.0/24^24-29, 203.89.178.0/24^24-29, 203.89.181.0/24^24-29, 203.89.187.0/24^24-29, 203.92.25.0/24^24-29, 210.7.46.0/24^24-29, 202.89.43.0/25^25-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig.wallace(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20100419 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 18 Apr '10

18 Apr '10

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: AS9560:RS-ROUTES:AS17492 descr: advertised to AS9560 by Vector Communications - AS17492 members: 202.126.192.0/20^20-29, 115.126.128.0/21^21-29, 123.108.144.0/21^21-29, 202.162.176.0/21^21-29, 202.0.151.0/24^24-29, 202.62.245.0/24^24-29, 203.30.174.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: tony.wicks(a)vector.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20100112 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17492 descr: advertised to AS9560 by Vector Commuications Limited - AS17492 members: 202.126.192.0/20^20-29, 115.126.128.0/21^21-29, 123.108.144.0/21^21-29, 202.162.176.0/21^21-29, 182.16.152.0/22^22-29, 202.0.151.0/24^24-29, 202.62.245.0/24^24-29, 203.30.174.0/24^24-29, 203.99.68.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: Tim.Harman(a)vector.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20100419 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] Fwd: Notification of web harvest & consultation report
by Scott Weeks 15 Apr '10

15 Apr '10

--- Gordon.Paynter(a)natlib.govt.nz wrote: From: "Gordon Paynter" <Gordon.Paynter(a)natlib.govt.nz> Information abut the user agent is available from http://bit.ly/nlnzwebharvest and we don't yet know what IP addresses will be used. We have no plans to use the If-Modified-Since (or Etag, or similar approaches) for comparison with the 2008 harvest. If you have concerns about how the crawler may behave on specific websites, feel free to email us directly at web-harvest-2010(a)natlib.govt.nz or get in touch via our feedback form. ------------------------------------------------- Does it honor the robots.txt file? scott ---------------- ----------------- -----------------

3 2

Re: [nznog] Fwd: Notification of web harvest & consultation report
by Scott Weeks 15 Apr '10

15 Apr '10

--- regan.murphy(a)oasystems.co.nz wrote: From: Regan Murphy <regan.murphy(a)oasystems.co.nz> ***** Information abut the user agent is available from http://bit.ly/nlnzwebharvest and we don't yet know what IP addresses will be used. ***** Fairly sure the robots.txt was mentioned in the URL provided..... ! --------------------------------------------------------- Yep, apologies. Didn't read enough. I blame it on the pain medication I'm currently taking... :-) scott --------------- ---------- ---------------

1 0

Leakage to 1.0.0.0/8 - comment on known source
by Timothy Goddard 14 Apr '10

14 Apr '10

Hello, I just joined this group today so wasn't part of the earlier discussion, but saw the mention of leakage in to 1.0.0.0/8 earlier. I thought I'd bring up a particular issue I've seen in the past involving the address 1.0.0.0 . The issue is that the DLink DSL-502T router as shipped in large numbers by Xtra has a flaw in the DNS resolver. If a DNS request for an AAAA record is sent to the router, I've observed it sending back a malformed response packed. This would only be a minor irritation, except that it seems to corrupt the DNS cache such that subsequent requests for A records return the address 1.0.0.0 . I have observed this occurring at two different premises, both with this same router and both having received it as part of Xtra subscription packages. The issue was reported through the standard service desk, but I was unsure of where else it could be reported to. Of course, even if fixed it is unlikely that many shipped units would be updated. Just thought I'd let people know that we have a possibly significant national source of this traffic. While probably fairly low in volume at the moment, it would be entirely possible for example that an update to Windows could trigger a sudden increase. Cheers, Tim

6 8

Fwd: Notification of web harvest & consultation report
by Gordon Paynter 14 Apr '10

14 Apr '10

Hi all: Many of you were affected by the 2008 web harvest or have expressed an interest in the 2010 harvest so I am sending you the message below about the outcome of our recent consultation on the Options paper on the 2010 whole of domain web harvest. The decisions on the key issues raised are: Notification - The harvest is scheduled to begin on 12 May 2010. There will be a five-week notification period - The Library will use several channels to communicate about the harvest, including its corporate website, the LibraryTechNZ blog, a Twitter account, various mailing lists and forums, and media releases. Robots.txt - In 2008 the Library made the decision to ignore the robots.txt convention. - For the 2010 harvest, where a robots.txt file exists the harvester will honour robots.txt except when downloading images and other elements that are embedded in other web pages. - Website owners can set specific rules for the Library’s harvester, which will have the user agent string: NLNZHarvester2010 - If you have a very restrictive robots.txt file in place already, we would appreciate it if you could provide a more permissive rule for NLNZHarvester2010 to help us capture a complete copy of your website Location of harvester - After consultation with New Zealand telecom vendors we have decided to run the harvest from the United States using the Internet Archive’s hardware and network infrastructure, as we did in 2008. More information about these decisions is available from our website: http://www.natlib.govt.nz/about-us/current-initiatives/web-harvest-2010 http://www.natlib.govt.nz/catalogues/library-documents/web-harvest-consulta… Thanks to all of you have offered us advice in various fora over the last few months (and years). Gordon ...................... New Zealand web harvest 2010 More information at http://www.natlib.govt.nz/about-us/current-initiatives/web-harvest-2010 This account is run by Courtney Johnston (Web Manager) and Gordon Paynter (Programme Manager Digitisation)

5 7

Root Zone DNSSEC Deployment Technical Status Update
by Joe Abley 14 Apr '10

14 Apr '10

This is the fourth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. RESOURCES Details of the project, including documentation published to date, can be found at http://www.root-dnssec.org/. We'd like to hear from you. If you have feedback for us, please send it to rootsign(a)icann.org. DOCUMENTATION The following draft document was recently published: - Resolver Testing with a DURZ - TCR - Proposed Approach to Root Key Management ICANN has begun the process of formally soliciting expressions of interest for volunteers from the technical community to act as Trusted Community Representatives. These volunteers will witness cryptographic key ceremonies and also carry out various important roles relating to KSK key management. For more information, see: http://www.icann.org/en/announcements/announcement-12apr10-en.htm Expressions of interest can be submitted here: http://www.root-dnssec.org/tcr/ DEPLOYMENT STATUS KSR exchanges continue between production platforms at VeriSign and ICANN. Build-out of KSK Key Ceremony facilities at ICANN continues, and both facilities (east- and west-coast USA) are expected to be ready on schedule. The incremental deployment of DNSSEC in the Root Zone is being carried out first by serving a Deliberately Unvalidatable Root Zone (DURZ), and subsequently by a conventionally signed root zone. Discussion of the approach can be found in the document "DNSSEC Deployment for the Root Zone", as well as in the technical presentations delivered at RIPE, NANOG, IETF and ICANN meetings. Twelve of the thirteen root servers have now made the transition to the DURZ. No harmful effects have been identified. Some early analysis of packet captures from many root servers surrounding each event was recently presented at the IETF meeting in Anaheim, CA, USA and can be found with other presentation materials at <http://www.root-dnssec.org/presentations/>. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ To come: 2010-05-05: J starts to serve DURZ 2010-07-01: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.) A more detailed DURZ transition timetable with maintenance windows can be found in the document "DNSSEC Deployment for the Root Zone", the most recent draft of which can be found on the project web page at <http://www.root-dnssec.org/>.

1 0

advertisements of 14/8 and 223/8
by Geoff Huston 13 Apr '10

13 Apr '10

Hi, APNIC and NTT are cooperating in a project to investigate the properties of unwanted traffic that is being sent to specific destinations in the address blocks of 14.0.0.0/8 and 223.0.0.0/8. These address blocks have been recently allocated to APNIC from the IANA, and APNIC and NTT are wanting to undertake this investigation prior to the commencement of ordinary allocations. Accordingly, APNIC has authorized AS38639 to advertise routes for 14.0.0.0/8 and 223.0.0.0/8 from now until 26 April 2010, and requests that AS38639's peers and upstreams accept this as a legitimate routing advertisement. thanks, Geoff Huston APNIC

1 0

APNIC Allocated 14/8, 223/8 today
by Skeeve Stevens 13 Apr '10

13 Apr '10

Hey all, As the subject says, APNIC was allocated 14/8 and 223/8 today... which does seems a little close after 1/8 and 27/8 in January 2010 - since 1/8 hasn't started, I'm surprised about the new ones. Not sure why I haven't seen any announcements about it... just thought I'd break the news... ...Skeeve -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve(a)eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced.

1 0

14/8 and 223/8 allocated to APNIC
by Leo Vegoda 13 Apr '10

13 Apr '10

Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in April 2010: 14/8 and 223/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. The IANA free pool contains 20 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN

1 0