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
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
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
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
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
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
______________________________________________________________________________