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
Dear NZNOG community,
A couple of weeks ago I posted ICANNs’ KSK rollover timelines in here.
It was announced today that the plan to change the cryptographic key that helps protect the Domain Name System (DNS) is being postponed.
The changing or "rolling" of the KSK Key was originally scheduled to occur on 11 October, but it is being delayed because some recently obtained data shows that a significant number of resolvers used by Internet Service Providers (ISPs) and Network Operators are not yet ready for the Key Rollover. The availability of this new data is due to a very recent DNS protocol feature that adds the ability for a resolver to report back to the root servers which keys it has configured.
Full announcement is here: https://www.icann.org/news/announcement-2017-09-27-en
Regards,
Save Vocea
ICANN staff in the region
From: Save Vocea <save.vocea(a)icann.org>
Date: Tuesday, September 12, 2017 at 4:53 PM
To: NZNOG <nznog(a)list.waikato.ac.nz>
Subject: KSK rollover timeline and how to check if your systems are ready
Dear NZNOG list members,
I’d appreciate if this is shared through your network /organizations and to check if your systems won’t be affected by the following change.
The Internet Corporation for Assigned Names and Numbers (ICANN) is planning to roll, or change, the “top” pair of cryptographic keys used in the Domain Name System Security Extensions (DNSSEC) protocol, commonly known as the Root Zone KSK. This will be the first time the KSK has been changed since it was initially generated in 2010, and is considered an important security step, in much the same way that regularly changing passwords is considered a prudent practice by any Internet user.
What does that mean?
Rolling the KSK means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers, including: Internet Service Providers; enterprise network administrators and other Domain Name System (DNS) resolver operators; DNS resolver software developers; system integrators; and hardware and software distributors who install or ship the root's "trust anchor." The KSK is used to cryptographically sign the Zone Signing Key (ZSK), which is used by the Root Zone Maintainer to DNSSEC-sign the root zone of the Internet's DNS.
Why do you need to prepare?
Currently, 25% of global Internet users, or 750 million people, use DNSSEC-validating resolvers that could be affected by the KSK rollover. If these validating resolvers do not have the new key when the KSK is rolled, end users relying on those resolvers will encounter errors and be unable to access the Internet.
How to know if your systems are up-to-date?
ICANN is offering a test bed for operators or any interested parties to confirm that their systems handle the automated update process correctly. Check to make sure your systems are ready by visiting: http://go.icann.org/KSKtest.
What is the timeline for this process?
October 27, 2016: KSK rollover process begins as the new KSK is generated.
July 11, 2017: Publication of new KSK in DNS.
September 19, 2017: Size increase for DNSKEY response from root name servers.
October 11, 2017: New KSK begins to sign the root zone key set (the actual rollover event).
January 11, 2018: Revocation of old KSK.
March 22, 2018: Last day the old KSK appears in the root zone.
August 2018: Old key is deleted from equipment in both ICANN Key Management Facilities.
More information about the root zone KSK rollover is available here: https://www.icann.org/resources/pages/ksk-rollover.
Thank you,
Save vocea
VP, Global Stakeholder Engagement, Oceania
ICANN
Hi all
As promised here is the list of workshops/tutorials that we have organised
so far. These aren't definite yet but are very likely to happen.
*Wednesday tutorials:*
-Network Security Tutorial (run by APNIC)
-Facebook Network Automation Hack event (run by Facebook, will be similar
to https://netengcodehack2017.splashthat.com/%29 )
*Workshop (roughly Monday 9am to Wednesday 12pm):*
-Mikrotik MTCINE training - Outline here
https://mikrotik.com/download/pdf/MTCINE_Outline.pdf
Our CFP is still open. Details here -
http://www.nznog.org/nznog18/call-for-papers-2018 .
If anyone else wants to help Richard Nelson and myself put together the
programme for Thur/Fri please get in contact. So far we've received details
on some really interesting talks.
If you want to sponsor NZNOG please reach out also.
Cheers
Dave
Does anyone have a network contact at Datacom please?
I can't get to datacom.co.nz (direct) from my NZ connection, and can't get to Geekzone via Cloudflare either (CF returns a timeout trying to reach origin).
However if I fire a VPN to Sydney both datacom.co.nz and Geekzone work fine.
Called datacentre and ops guys have no idea what's going on. Seems that traffic to NZ is being impacted but not to overseas.
Cheers
Mauricio Freitas
https://about.me/freitasm
Hi all
I wanted to give some more details on our plans for the conference next
year.
On Wednesday Facebook are looking at holding a Network Automation Hack
event as part of NZNOG. This should be a really awesome session.
It will be similar to this - https://netengcodehack2017.splashthat.com/%29 .
Whilst this isn't completely locked in yet it has approval internally at
Facebook and looks set to happen. I'd suggest if this interests you then
plan to be at NZNOG from Wed - Fri. Be warned, seats will be limited.
The other event I wanted to announce I unfortunately still can't. I've been
chasing people pretty hard on it and I still don't know that it will
definitely happen :(
I will update when I know more.
Cheers
Dave
A client had a (business) customer switch over to UFB and needed
assistance reconfiguring the (Mikrotik) router being attached to the ONT
-- it turned out whoever first set up the Mikrotik (sensibly) assumed
it'd be seeing IP packets over VLAN 10, but actually the ISP required IP
packets over PPPoE over VLAN 10 in order for it to work.
Looking around it appears this client's customer's ISP isn't the only
one that is requiring PPPoE over VLAN tagging over Ethernet for their
UFB connections. Is there a reason other than "let's make everything
look like 1990s dialup so it works with our legacy equipment" for the
bit/CPE CPU overhead of PPPoE on UFB, including imposing the lowered
usable MTU and PMTU discovery headaches on the end user?
The only one that really comes to mind is "user/password authentication"
(rather than needing to collect CPE MAC addresses which seems to happen
with, eg, Vodafone cable/FibreX). But it's not clear to me why, eg,
802.1X isn't used for the user/password authentication in that case; or
DHCP with some extension to pass a "secret" identifier.
20-bytes-per-packet-forever seems a large overhead to pay for
user/password authentication at CPE power on.... (Maybe in the beginning
there's "lack of CPE support" -- but we're a few years into the UFB
rollout, and lots of ISPs seem to be supplying their own ISP-badged CPEs
anyway, which could presumably implement whatever was needed.)
Ewen
Hey NZNOG’rs,
I know that this is not “nice to do” but I have tried the contact centre - the issue is logged but I doubt it will get to the right people ?
AirNZ currently has 2 SPF entries and this is causing emails to fail:
dig TXT airnz.co.nz | grep spf1
airnz.co.nz. 21301 IN TXT "v=spf1 a ..."
airnz.co.nz. 21301 IN TXT "v=spf1 …"
Please fix :) I have error logs going back to the 8th of Aug, if that helps ?
I don’t know what other domains this was done on.
Cheers,
Pieter
Dear NZNOG list members,
I’d appreciate if this is shared through your network /organizations and to check if your systems won’t be affected by the following change.
The Internet Corporation for Assigned Names and Numbers (ICANN) is planning to roll, or change, the “top” pair of cryptographic keys used in the Domain Name System Security Extensions (DNSSEC) protocol, commonly known as the Root Zone KSK. This will be the first time the KSK has been changed since it was initially generated in 2010, and is considered an important security step, in much the same way that regularly changing passwords is considered a prudent practice by any Internet user.
What does that mean?
Rolling the KSK means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers, including: Internet Service Providers; enterprise network administrators and other Domain Name System (DNS) resolver operators; DNS resolver software developers; system integrators; and hardware and software distributors who install or ship the root's "trust anchor." The KSK is used to cryptographically sign the Zone Signing Key (ZSK), which is used by the Root Zone Maintainer to DNSSEC-sign the root zone of the Internet's DNS.
Why do you need to prepare?
Currently, 25% of global Internet users, or 750 million people, use DNSSEC-validating resolvers that could be affected by the KSK rollover. If these validating resolvers do not have the new key when the KSK is rolled, end users relying on those resolvers will encounter errors and be unable to access the Internet.
How to know if your systems are up-to-date?
ICANN is offering a test bed for operators or any interested parties to confirm that their systems handle the automated update process correctly. Check to make sure your systems are ready by visiting: http://go.icann.org/KSKtest.
What is the timeline for this process?
October 27, 2016: KSK rollover process begins as the new KSK is generated.
July 11, 2017: Publication of new KSK in DNS.
September 19, 2017: Size increase for DNSKEY response from root name servers.
October 11, 2017: New KSK begins to sign the root zone key set (the actual rollover event).
January 11, 2018: Revocation of old KSK.
March 22, 2018: Last day the old KSK appears in the root zone.
August 2018: Old key is deleted from equipment in both ICANN Key Management Facilities.
More information about the root zone KSK rollover is available here: https://www.icann.org/resources/pages/ksk-rollover.
Thank you,
Save vocea
VP, Global Stakeholder Engagement, Oceania
ICANN
Kia ora,
Registrations for this year's New Zealand Internet Research Forum are open.
The Forum will be held on 8 November, the day before NetHui 2017
<https://2017.nethui.nz/> - as part of the NetHui umbrella. *You can
register for free by selecting the first event
here: https://nethui-2017.lilregie.com/step1
<https://nethui-2017.lilregie.com/step1>* you can also register there for
NetHui 2017 should you want to come along!
The programme for this year will be finalised soon, and in the meantime you
can check out last year's programme
<https://internetnz.nz/internet-research-forum-2016-programme> for an idea
of what goes on at the NZIRF.
Please consider sharing this with your networks.
I look forward to seeing you there!
*Ngā mihi nui,*
*Nicole Skews-Poole*
NZIRF Organiser
InternetNZ
Mobile: +64 27 323 8914
Email: nicole(a)internetnz.net.nz
A better world through a better Internet
Hi all
So, probably a bit a touchy subject this one but here goes..
If you are a network operator and you have more than 4000 customers in my
understanding you need to have full interceptions capabilities. (I'm not a
lawyer, etc, etc) This is more than just being 'interception ready'.
http://www.police.govt.nz/advice/businesses-and-organisations/ticsa/interce…
This will mean having a mediation system and being able to produce
intercept data in the ETSI standard - again, as far as I know.
What are companies/organisations out there doing about this?
Is there a nice open source solution out there for this? (I haven't found
one yet) Are people putting their heads in the sand and praying they never
get served a warrant? Is everyone just shelling out hundreds of thousands
of dollars on a vendor LI solutions?
What network kit are people integrating with LI in NZ?
And note, the last paragraph on the URL I linked above reads:
"Can I share interception capability resources?
Network operators may co-ordinate, share or contract for services
(equipment or staff) in order to meet the interception capability
requirements in the Act. However, it remains the responsibility of the
network operator to ensure that any such arrangement does not affect any
obligations that apply under the Act. Before entering into any such
arrangement a network operator must notify the Director of the GCSB."
Replies on or off list welcomed.
Cheers
Dave
(AS17705)