NZNOG February 2018

nznog@list.waikato.ac.nz

9 participants
6 discussions

Anyone interested in donating space / connectivity / kit for a proper NZ Debian mirror?

by Michael Fincham

Hi everyone, Citylink's official Debian mirror (ftp.nz.debian.org) is apparently again broken (not even listening on port 80 from where I'm sitting). Would anyone be seriously interested in donating rack space, national transit, or hardware to the cause of another official Debian mirror for NZ? Having reliable and cheap access to free software projects like Debian is critically important, and having a second official mirror seems like a no-brainer to me. I am very happy to donate my time to admin and monitor any equipment provided for this, and to liase with the Debian project as required. Perhaps Citylink could give us some insight in to the traffic levels their existing mirrors see? -- Michael Fincham

2 years, 9 months

Removing the four stale TAL from the APNIC RPKI validation set.

by George Michaelson

Updating RPKI trust anchor configuration ------------------------------------------------------- APNIC has completed the process of transitioning from its previous Resource Public Key Infrastructure (RPKI) trust anchor arrangement to a new single trust anchor configuration. Each RIR will publish an 'all resources' global trust anchor, under which its own regional resources (IP addresses and ASNs) will be certified. APNICs trust anchor is one of the previous five, which has been retained as the sole trust anchor over all APNIC resource certificate products. If you are using relying-party software, such as the Dragon Research Labs RPKI Toolkit, RPSTIR or the RIPE NCC’s RPKI Validator, you are advised to update your software’s configuration to use only the current APNIC trust anchor, rather than the set of five APNIC trust anchors that were previously in use. The update is to remove four of the five: One has been retained as the current live Trust Anchor. Note: this update is not critical. However, if it is not done, the software will log or report warnings about being unable to retrieve the trust anchors that are no longer being used. All resources now validate under the single active trust anchor and no orphan products are valid under the other prior trust anchors. The current APNIC TAL is as follows: ------ rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9RWSL61YAAYumEiU8z8 qH2ETVIL01ilxZlzIL9JYSORMN5Cmtf8V2JblIealSqgOTGjvSjEsiV73s67zYQI 7C/iSOb96uf3/s86NqbxDiFQGN8qG7RNcdgVuUlAidl8WxvLNI8VhqbAB5uSg/Mr LeSOvXRja041VptAxIhcGzDMvlAJRwkrYK/Mo8P4E2rSQgwqCgae0ebY1CsJ3Cjf i67C1nw7oXqJJovvXJ4apGmEv8az23OLC6Ki54Ul/E6xk227BFttqFV3YMtKx42H cCcDVZZy01n7JjzvO8ccaXmHIgR7utnqhBRNNq5Xc5ZhbkrUsNtiJmrZzVlgU6Ou 0wIDAQAB ------ Configuring Relying Party Software ----------------------------------------------- RIPE NCC RPKI Validator: If you upgrade to RIPE validator rpki-validator-app-2.24 the correct Trust Anchor is configured. No further work is required. Dragon Research Labs Rcynic Validator: If you run rcynic, you need to remove all the TAL, TA or CER entries in rcynic.conf except ones which point to apnic-rpki-root-iana-origin.cer or the related TAL. If you use the trusted-certs/ directory, simply remove the four files which are named for the non-APNIC RIR as follows: cd /etc/trust-anchors # or wherever you place the TAL files rm apnic-rpki-root-ripe-origin.tal rm apnic-rpki-root-arin-origin.tal rm apnic-rpki-root-lacnic-origin.tal rm apnic-rpki-root-afrinic-origin.tal RPSTIR To modify an installed RPSTIR system, locate the /usr/local/etc/rpstir directory and remove all but the current live APNIC TAL. More information is in the attached PDF describing how to update the trust anchor configuration in these three popular relying-partner software systems. -George

3 years, 1 month

Survey

by Richard Nelson

Thankyou to everybody who responded to the NZNOG survey, the results are in and are very useful to us. Geoff Huston was considered a top three speaker most often followed by Francesco Alberti of Eolo. Hamid Maani of Hawaiki and Kraig Winters representing the Red Cross were third equal with a large group just behind them. More importantly almost all the speakers were considered interesting by someone attending the conference so we are pleased with the programme reception. Respondents liked Queenstown but didn't like the venue. They wanted desks in the conference and aircon in the rooms. The most popular destination choices for next years conference were Napier, Wellington and New Plymouth. This fairly closely corresponds with the trustees' thinking so we will check them out for venues and accommodation with air conditioned rooms. It will, however, be difficult to top jet boating as a social activity. Just over 90% of people are open to us changing the conference dates. We will investigate this. There were almost no other conferences identified to avoid clashes with but public holidays are clearly sancrosanct. There was also a suggestion that we avoid school holdiays which we currently don't do. People are happy for us to make the conference a bit bigger to make sure people don't miss out. There were also a lot of individual comments and suggestions that we will try to take on board. Richard Nelson

3 years, 2 months

Re: [nznog] Survey

by Ewen McNeill

On 9/02/18 13:11, Barry Murphy wrote: > May be quite beneficial to have NZNog the week after, so those that have travelled > from AU the week before can stick around for another week and attend NZNog Could definitely work out. I can think of at least a half dozen Australia-nbased Linux.Conf.au regulars, who would probably come to LCA2019 in Christchurch too, working in networks/network operations as their day job. There's probably more who would find it relevant if it was easy to get to after Linux.Conf.au (Christchurch/Wellington is an easy regular flight; not sure about Christchurch/New Plymouth or Christchurch/Napier -- those might be two flights). (The week before might work too, but some of the people I'm thinking of usually help with LCA conference setup, which obviously is the end of the week before the conference...) Ewen

3 years, 2 months

Looking for DNS resolver addresses in NZ for research project

by Sebastian Castro

Hi everyone: In case you haven't seen a message from me before, I'm Sebastian Castro, Technical Research Manager for NZRS, part of the InternetNZ team. Our Research Team has been conducting some research work on passive DNS analysis in order to identify real DNS resolvers in the wild, as authoritative DNS servers like the .nz nameservers get a lot of rubbish traffic. In order to advance the work, we are looking for some ground truth about real DNS resolvers in NZ. We have a list of known resolvers from organizatons like Spark, Vodafone, some ISPs, but we are looking to extend and refresh that list. If you operate a network that has a resolver, would you be so kind to share with us the IP addresses (both v4 and v6 if available) the resolver uses to send traffic? Depending on your architecture, it could be the address your users setup in their configuration, or a different address based on location where there is a load balancing architecture. There is no restriction: we want big and small resolvers, ISPs, Wireless ISPS, educational organizations, big and small companies, everything helps. The list won't be made public, it will be used for our research purposes. Thanks in advance and enjoy your Waitangi weekend. -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535

3 years, 2 months

TICSA – Security contacts

by TICSA

Hi folks, In keeping with Tarus’s comments, I too would like to thank you all for your time at the NZNOG. It was great to catch up with old friends and make some new ones. We can be reached at TICSA(a)NCSC.govt.nz for anything relating to the Network Security section (part 3) of the TICSA How to submit a notification is covered in the Guidelines document which can be found at https://www.ncsc[dot]govt.nz/ticsa Regards Steve Martin On behalf of The TICSA Team National Cyber Security Centre Government Communications Security Bureau This electronic message, together with any attachments, contains information that is provided in confidence and may be subject to legal privilege. Any classification markings must be adhered to. If you are not the intended recipient, you must not peruse, disclose, disseminate, copy or use the message in any way. If you have received this message in error, please notify us immediately by return email and then destroy the original message. The New Zealand Intelligence Community (NZIC) and the departments comprising the NZIC accepts no responsibility for changes to this e-mail, or to any attachments, after its transmission from NZIC. This communication may be accessed or retained for information assurance purposes. Thank you. ______________________________________________________________________________ This email has been filtered by SMX. For more information visit http://smxemail.com ______________________________________________________________________________

3 years, 2 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

NZNOG February 2018