- NZNOG - lists.nznog.org

Validating resolvers for DNS and DNSSEC
by Andy Linton 10 Feb '14

10 Feb '14

At the recent NZNOG meeting in Nelson, Geoff Huston from APNIC gave a talk on DNSSEC and had some interesting statistics about the use of validating resolvers for DNS and DNSSEC. For DNSSEC to work there are two parts of the equation that need to happen: 1) People need to sign their zones 2) People need to ask the question "is this zone signed" etc. I want to talk about 2) Geoff noted that a number of countries that we might not expect to be high on the list of those validating the responses using the DNSSEC technology were way ahead of the rest of the world. I haven't got the exact numbers here - I expect his presentation will appear shortly and there's likely to be a video of it at some stage at http://www.r2.co.nz/20140130/ - but from memory the global average is about 7% usage of validating resolvers. New Zealand is a dismal <2% and I'd like to challenge you all to do something about that. And we're way behind the Australians.... Geoff pointed out that the high rate elsewhere is due to a large degree to the number of people using Google's Public DNS servers and while that looks attractive and an easy way to improve those numbers I'd ask you not to go down that path. You need to do this yourself (or at least as close as possible to the end user). If you use someone else's resolver then your traffic can be intercepted en route to the validating resolver => man in the middle attack => game over. And of course, handing this data over to a centralised collection agent makes the work of anyone who wants to snoop on you much, much easier. It's not about Google's servers - this applies equally to public servers run by anyone. DNSSEC validation is not real validation unless it's performed end to end or at least as close as possible to that. A number of NZ ISPs provide this service to their customers with their in house resolvers and those of you who don't should really be looking at when you will do this. Those people who have signed their zones are making assertions about how they want their DNS data to be interpreted. They're saying that unless you validate their DNS data they really don't want you to connect to them. You should be taking notice of this. But then maybe you just ignore broken certs on websites etc. So what should you do? End user ======= Check here - http://dnssec.vs.uni-due.de/ Or use - https://www.dnssec-validator.cz/ Ask your ISP/admins to fix this. ISPs/Enterprise ============ If you're running a resolver for customers do the work to get it validating, please.... Plenty of info out there on how to do this for Bind and Unbound and I'm no Windows expert but this looks straightforward: Windows: http://info.menandmice.com/blog/bid/88297/Windows-2012-Server-Enabling-DNSS…

11 17

NZNOG 2014 Videos
by Richard Naylor 10 Feb '14

10 Feb '14

Before I get spammed to death about the videos.... We got back to base on Wednesday night, late. We got the tapes on friday and have been processing over the week end. Its pretty well all edited. One node ran out of disk last night and so is repeating today. Uploading is a slow process as the addition of HD footage added at least 200% more data. Thats why I asked if HD was of interest. (Its distribution grade HD rather than the higher bit-rate contribution HD) As we do the upload, we're also doing an idiot check on files, web pages etc, so there may be some reruns. But I expect that we should have it all available by the end of this week. We have another job starting tomorrow, which also consumes our evenings, so theres a bit of a time squeeze going on. I'll update the list when the files are available. rich

1 0

Re: [nznog] Validating resolvers for DNS and DNSSEC
by Richard Naylor 10 Feb '14

10 Feb '14

At 11:35 a.m. 11/02/2014, Andy Linton wrote: >At the recent NZNOG meeting in Nelson, Geoff Huston from APNIC gave >a talk on DNSSEC and had some interesting statistics about the use >of validating resolvers for DNS and DNSSEC. <snip> >and there's likely to be a video of it at some stage at ><http://www.r2.co.nz/20140130/>http://www.r2.co.nz/20140130/ - but >from memory the global average is about 7% usage of validating resolvers. The video is available at http://www.r2.co.nz/20140130/geoff-h.htm The others are rendering and uploading. The recording is large and currently filling the CDN cache, so if it doesn't play well - wait - its a large file. As an option there is an HD version. Its a large file also (>1GB) so takes even longer to load and requires a decent CPU to play back. Dual-core or better. Feedback on the value of HD footage would be interesting. Its slowing down the render and upload process, so if its not of much value, we can speed things up. The other videos should be available in a day or so. Richard

1 0

Reviews of Conference bridges that work well over multiple varied speeds
by Alexander Neilson 09 Feb '14

09 Feb '14

Little bit off topic so Beer However we have been asked to deliver a Video Teleconference Bridge in our system for customers whose speeds and connectivity vary (ADSL1, ADSL2, VDSL, Radio, Fibre, UFB) and so I am looking for anyones experiences with conference bridge hardware that can take connections from customers who may be using any of these connections into our network and that is smart enough to remux the video / audio streams out to cater to the connection speeds available. If anyone has any history with such a device I would love to hear about it off list. Preferring devices that will have a master bridge inside our core with good monitoring and management and easy to use remote units that are also reliable (remote customers make for hard trips to work on) however any relevant information would be appreciated. (I am arguing for on topic ish due to the handling of different grade customer connections across the network) Regards Alexander Alexander Neilson Neilson Productions Limited alexander(a)neilson.net.nz 021 329 681 022 456 2326

3 2

IPv6 address allocation questions
by Qinwen Hu 06 Feb '14

06 Feb '14

Hi All, My name is Qinwen(Steven) Hu from the University of Auckland. I am working on my PhD thesis in which I am trying to observe potential new security issues in IPv6 networks. I have two questions I would like to ask network operators: 1) Recently, we did a survey to investigate how network administrators are actually allocating IPv6 Interface IDs around the world. Our results show that 82% of domains use sequential small integer values in the interface ID field for their IPv6 addresses. - What IPv6 address allocation mechanisms do you (or will you) use in your IPv6 network/services? could you please give us your reasons for using these mechanisms? 2) What new security issues, i.e. issues that don't exist in IPv4, do you think are likely to arise? Any replies would be very helpful, please send them to me off-list.Many thanks for your kind consideration. Have a nice day. Regards, Steven 胡勤文／Qinwen Hu Ph.D. Candidate, Computer Science, University of Auckland 奥克兰大学计算机科学博士研究生

1 0

FW: Trusted Community Representation for Root KSK
by Leo Vegoda 06 Feb '14

06 Feb '14

Hi, People on this list might also want to submit responses. Regards, Leo From: dns-operations-bounces(a)mail.dns-oarc.net [mailto:dns-operations-bounces(a)mail.dns-oarc.net] On Behalf Of Kim Davies Sent: Thursday, February 06, 2014 12:38 PM To: DNS Operations Subject: [dns-operations] Trusted Community Representation for Root KSK Hi folks, ICANN is currently performing a consultation on how to evolve the participation of Trusted Community Representatives in the management of the root key signing key. I think this consultation is of particular interest to this group as ultimately these TCRs are there to instill trust in the DNS operations community that the KSK is being managed in a proper fashion. I'd encourage you to provide feedback to this consultation - available at http://www.icann.org/en/news/public-comment/tcr-dnssec-key-signing-21jan 14-en.htm - by 11th February. It is important we have a model of TCR participation that is satisfactory to the community. For convenience, here are the terms of reference replicated: Background Since July 2010, the DNS Root Zone has been secured using DNSSEC[1]. The model of using DNSSEC in the DNS Root Zone revolves around a "key signing key" (KSK) that is managed by ICANN in two secure facilities. Four times a year, a ceremony is conducted at these facilities to perform operations involving the KSK. As a key part of this process, a minimum of three from a pool of 21 trusted community representatives (TCRs) attend each ceremony to enable access to the secure materials, to witness the procedure, and to attest that the ceremony was conducted properly[2]. Each ceremony is attended by ICANN staff, the TCRs, representatives of the Root Zone Maintainer (Verisign), representatives of an independent audit firm retained by ICANN to monitor the process, and often additional external witnesses. Ceremonies are recorded by three audit cameras and webcast online. A typical ceremony lasts approximately four hours, and involves a process of temporarily removing the key signing key from a safe and performing key-signing operations in a secure manner following a formal script. The script is designed to perform each operation in a transparent manner to ensure the key signing key is only used for its proper purpose, and there is no ability for its contents to be disclosed for other purposes. Materials from each ceremony - such as the scripts, video recordings, and system output - are posted online[3]. De-briefings and discussions are conducted post-ceremony, where participants discuss how to improve future ceremonies. This feedback helps inform the evolution of the KSK ceremony to be both efficient and effective, while ensuring maximum trust in how ceremonies are performed. The TCRs were selected[4] from the global community based on a number of criteria[5]. These selection criteria relate to the volunteers ability to travel to ceremonies, conscientiously oversee the process, ensure transparency in its operation, and ultimately contribute to the broader community's trust that the private component of the key signing key has not been compromised. The TCRs are privately funded volunteers who are not reimbursed or compensated by ICANN for their participation nor their expenses. The original TCR proposal was silent on the length of service of individual TCRs. Of the 21 TCRs, seven are credentialed as "crypto officers" (COs) for each of the two facilities, and the remaining seven act as "recovery key shareholders" who only participate in ceremonies in the event the requisite number of COs are unable to participate or there is a need to rebuild the KSK following an unforeseen event. Of the seven COs for each facility, ICANN aims to have four attend each ceremony, with an absolute minimum of three required to successfully perform a ceremony. Each facility hosts two ceremonies per year, approximately once every six months. In practice, a TCR will attend at minimum one ceremony per year, and some will attend two in order to ensure sufficient attendance. Of the initial pool of 21 TCRs, one has resigned and been replaced from the pool of recovery key shareholders. No TCR has been removed owing to the other three criteria for replacement in the TCR selection document, relating to lack of integrity or trustworthiness; assumption of a conflicting role within a root management organization; or being unable to serve in their position. Based on feedback from the current TCRs and our experience from the first 14 ceremonies, we are reviewing what changes, if any, should be made to the current model of TCR participation. Comments Comments are welcome on any aspect of the consultation, and specifically on the following questions: 1. Is the current TCR model effectively performing its function of ensuring trust in the KSK management process? 2. Is the current size of the TCR pool appropriate to ensure sufficient participation in the ceremonies, while not overburdening the availability of specific volunteers? 3. Should there be a minimum level of participation required of a TCR in order to be considered to be successfully discharging their duties? 4. There is no standard provision to refresh the list of TCRs except when they are replaced due to inability to effectively perform their function. Should there be a process to renew the pool of TCRs, such as using term limits or another rotation mechanism? 5. The current model does not compensate TCRs for their services in order to ensure their independence from ICANN. a. Should the model of TCRs paying the costs of their participation be retained? b. Would some form of compensation to offset the expenses incurred by the TCRs detract from their independence in performing the role? c. If you support compensating TCRs for their expenses, are there requirements or limitations on whom the funding organization should be? Please send your comments to comments-tcr-dnssec-key-signing-21jan14(a)icann.org <mailto:comments-tcr-dnssec-key-signing-21jan14(a)icann.org> References [1] http://www.root-dnssec.org [2] https://www.iana.org/dnssec/icann-dps.txt [3] http://data.iana.org/ksk-ceremony/ [4] http://www.root-dnssec.org/tcr/selection-2010/ [5] http://www.root-dnssec.org/wp-content/uploads/2010/04/ICANN-TCR-Proposal -20100408.pdf kim

1 0

Re: [nznog] NZNOG Digest, Vol 134, Issue 2
by Jonathan Spence 04 Feb '14

04 Feb '14

Hi Trent, You may want to try geekzone.co.nz as there are a few good Telecom contacts on there. Thanks, Jonathan ---------------------------------------- From: nznog-request(a)list.waikato.ac.nz Sent: Wednesday, February 5, 2014 12:01 PM To: nznog(a)list.waikato.ac.nz Subject: NZNOG Digest, Vol 134, Issue 2 Send NZNOG mailing list submissions to nznog(a)list.waikato.ac.nz To subscribe or unsubscribe via the World Wide Web, visit http://list.waikato.ac.nz/mailman/listinfo/nznog or, via email, send a message with subject or body 'help' to nznog-request(a)list.waikato.ac.nz You can reach the person managing the list at nznog-owner(a)list.waikato.ac.nz When replying, please edit your Subject line so it is more specific than "Re: Contents of NZNOG digest..." Today's Topics: 1. Telecom NZ Contact (Trent Farrell) ---------------------------------------------------------------------- Message: 1 Date: Tue, 4 Feb 2014 12:19:25 +0000 From: Trent Farrell <tfarrell(a)riotgames.com> To: "nznog(a)list.waikato.ac.nz" <nznog(a)list.waikato.ac.nz> Subject: [nznog] Telecom NZ Contact Message-ID: <80289F43-A47C-4290-ABFC-5728C91EB5BA(a)riotgames.com> Content-Type: text/plain; charset="us-ascii" Hi all, Looking for someone from Telecom NZ to reach out off list, your customers are having issues with parts of our service. Cheers. - Trent ------------------------------ _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog End of NZNOG Digest, Vol 134, Issue 2 *************************************

1 0

Telecom NZ Contact
by Trent Farrell 03 Feb '14

03 Feb '14

Hi all, Looking for someone from Telecom NZ to reach out off list, your customers are having issues with parts of our service. Cheers. - Trent

1 0

Fwd: BCP 38
by Andy Linton 31 Jan '14

31 Jan '14

At NZNOG, Jamie Baddeley mention the spoofer tool at http://spoofer.cmand.org/ I ran it on the net I run at VUW and here are the traces from a couple of runs. I ran it once, realised I was being slack and turned on the 'rfp-check' feature on the edge Juniper and then ran the test again. A nice tool to demonstrate why we should do BCP 38.

1 0

Re: [nznog] Do you stream video?
by Richard Naylor 29 Jan '14

29 Jan '14

At 05:15 p.m. 15/01/2014, Dean Pemberton wrote: >Due to unforeseen circumstances our usual video streaming company of >choice (R2) is unable to stream NZNOG live this year. We're in AKL on another job. The plan is to send a camera operator to Nelson with a small portable encoder. The encoder planned is still in USA and won't be back in time. It died just after New Years day. I think we can free up one from the AKL job on wednesday, but need it back on the Saturday or Sunday after NZNOG, and are not confident couriers can do it. We also have very limited transport and time in AKL as we are parked up on a job. But if anyone can collect the unit from us on the Wednesday and take it to Nelson, then bring it back to AKL on the Saturday (we may have wheels on Saturday) that would solve the issue. I can probably meet someone at the airport and provide a ride home on the Saturday. The encoder is in a small plastic case about 200mmx150x100. Richard 021 897 089

9 10