swinog February 2018

swinog@lists.swinog.ch

21 participants
9 discussions

by Michael Hausding

Dear all SWITCH is organising a one day DNSSEC training together with PowerDNS The training will be given at the following dates: 9.4. Zurich, SWITCH 10.4. Bern, Uni 11.4. Carouge HESGE The one day training will give you an introduction into DNSSEC and show you how to sign DNS zones on an autoritative DNS server. We will use PowerDNS for the practical and hands on part. PowerDNS contains support for DNSSEC, enabling the easy serving of DNSSEC secured data, with minimal administrative overhead. Agenda: • Short introduction to DNSSEC • how DNSSEC works • keys / signatures / NSEC / NSEC3 • Working with DNSSEC and the PowerDNS Authoritative server • Short overview over PowerDNS Authoritative server backends (MySQL, PostgreSQL, BIND, pipe, ...) • DNSSEC signing • Pre-signed zones • Zone transfers • Utilities (pdnsutil) • The PowerDNS ALIAS record (and its future) Required skills: Unix system administrator skills and DNS server know how. The training will be delivered in english. More information and registration here: Zurich: https://www.eventbrite.com/e/dnssec-training-zurich-tickets-43350331007 Bern: https://www.eventbrite.com/e/dnssec-training-bern-tickets-43592055010 Carouge: https://www.eventbrite.com/e/dnssec-training-carouge-tickets-43592840359 Best regards Michael ------------------------------------ Michael Hausding, Competence Lead DNS & Domain Abuse SWITCH-CERT Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 77, incident phone +41 44 268 15 40 michael.hausding(a)switch.ch http://securityblog.switch.ch

5 years, 1 month

Mail to CNAME a thing?

by Markus Wild

Hi there, I've just come across a weird mail reception problem of some mails from Microsoft. Our servers insist that a specified MAIL FROM address can be resolved correctly, and this usually boils down to the following checks on the domain-part of the email-address specified: - is there an MX? Does the target resolve using an A record (not a CNAME), and does it resolve to a publically reachable address (not RFC1918 or localhost etc) - if there is no MX, is there an A record that fulfils the same criteria as the MX target above? - if none of these are true, the address is considered to be invalid and mail is rejected Since about Feb 15, I've now come across mails from account-security-noreply(a)accountprotection.microsoft.com that get rejected. When I manually perform the above steps, I can see why, and I also see a first: the domain part is actually a CNAME, something I've not encountered mentioned in standards as being a legal way to perform address resolution when delivering email. But, I also don't recall reading about rules that explicitly deny this, contrary to the very explicit rules that for example deny having MX point to CNAME. The domain setup here is borked in multiple ways however: $ host -t mx accountprotection.microsoft.com Host accountprotection.microsoft.com not found: 3(NXDOMAIN) $ host -t a accountprotection.microsoft.com Host accountprotection.microsoft.com not found: 3(NXDOMAIN) BUT: $ host -t cname accountprotection.microsoft.com accountprotection.microsoft.com is an alias for mail.msa.msidentity.com. and even if we should allow use of a CNAME here, we'd have to apply the same rules as stated initially on the CNAME target, and these fail as well: $ host -t mx mail.msa.msidentity.com. Host mail.msa.msidentity.com not found: 3(NXDOMAIN) $ host -t a mail.msa.msidentity.com. Host mail.msa.msidentity.com not found: 3(NXDOMAIN) So, what's your take on this? Does someone see a legal way to resolv this sender, that I've missed? Am I right in considering these addresses to be unresolvable and thus reject these mails? Who would I have to report this to at Microsoft to have any chance of a human person looking at the issue? Cheers, Markus

5 years, 1 month

Call for presentations RIPE 76

by Franziska Lichtblau

Dear all, Please find the CFP for RIPE 76 below or at: https://ripe76.ripe.net/submit-topic/cfp/. The deadline for submissions is *11 March 2018*. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings, see the "Speakers" paragraph in CFP for more information. Kind regards, Franziska Lichtblau RIPE PC Member https://ripe76.ripe.net/ripe-pc/ -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 76 will take place from 14-18 May in Marseille, France. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 76. See the full descriptions of the different presentation formats, https://ripe76.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than *11 March 2018*. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Connected Things (aka. Internet of Things - IoT) Speakers Presenters, RIPE Working Group Chairs and the RIPE Programme Committee are required to cover their own costs to attend a RIPE Meeting (meeting ticket, travel and accommodation). We have various ticket options available depending on your needs. In extraordinary circumstances, the RIPE Chair can waive the meeting fee for presenters. These requests are dealt with on a case-by-case basis via pc(a)ripe.net. Also note that, on an individual basis, participants can apply for a RIPE Fellowship to develop their professional or academic career. For more information, please visit: https://www.ripe.net/participate/ripe/ripe-fellowship Submissions Presenters should be clear on whether they wish to submit a presentation for a plenary or working group (WG) session. At present, most working groups will solicit policy proposals, discussion points or other content directly via their mailing lists. If you’re not sure what kind of session you should be presenting at, please visit: https://ripe76.ripe.net/plenary-or-wg/ RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour (during evening sessions) - Lightning talks: 10 minutes total for both presentation and any discussion The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe76.ripe.net/submit-topic/ - Lightning talks should also be submitted using the meeting submission system (https://ripe76.ripe.net/submit-topic/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice, in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. If you have any questions or requests concerning content submissions, please email pc(a)ripe.net. -- Franziska Lichtblau, M.A. building MAR, 4th floor, room 4.004 Fachgebiet INET - Sekr. MAR 4-4 phone: +49 30 314 757 33 Technische Universität Berlin gpg-fp: 4FA0 F1BC 8B9A 7F64 797C Marchstrasse 23 - 10587 Berlin 221C C6C6 2786 91EC 5CD5

5 years, 1 month

What email headers need to be understood by a PGP/MIME enabled email client?

by Benoit Panizzon

Hello fellow Swinogers To exchange emails containing potentially sensitive customer information with swisscom, we agreed to use PGP encrytped emails. Now when swisscom is sending an encrypted attachment to us, we get those MIME Headers: ------=_Part_5064522_1012233884.1518535424993 Content-Type: application/octet-stream; name=Attachment1.asc Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: application/pdf; name=Attachment1.asc X-Content-PGP-Universal-Saved-Content-Description: Example_Filename.pdf X-Content-PGP-Universal-Saved-Content-Disposition: attachment; filename=Attachment1.asc; size=143718; creation-date="Tue, 13 Feb 2018 14:56:05 GMT"; modification-date="Tue, 13 Feb 2018 14:56:05 GMT" X-Content-PGP-Universal-Saved-Content-ID: <F73FD4960576014A98D75D430AABA49B(a)swisscom.com> X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=Attachment1.asc -----BEGIN PGP MESSAGE----- Version: OpenPGP totemomail Comment: totemomail OpenPGP - http://www.totemo.com [encrypted content] Well, Neither Claws-Mail nor Firefox with Enigma Plugin do understand those X-Content-PGP Emails which would specify the correct content type and file name and just merely show a binary "Attachment1.asc" attachement. Of course, as experienced user reading the email source, you can save this to disk and then open it with a PDF reader, but using encrypted email should be easier than that :-) So I contacted the totemo support and they told me, that every PGP enabled email client should be able to correctly extract mime-type and filename from the X-Content-PGP Headers. Well I have found: https://www.ietf.org/rfc/rfc4880.txt https://binblog.info/2008/03/12/know-your-pgp-implementation/ Well, I know no clients which support RFC4880 when generating or decoding PGP encrypted emails. How about the SWINOG Community? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

5 years, 1 month

Cloudmark and Bluewin

by Alex Faes

Hi @ll, We have some issue with sending email to @bluewin.ch. Since a few months, all Emails sent to bluewin.ch recipients are marked as junk. L That what we can see: X-Bluewin-Spam-Analysis: v=2.1 cv=eusSttdX c=1 sm=1 tr=0 p=9iobZdBrAAAA:8 a=UyOLZL4rDy101xZCZBNcuQ==:117 a=UyOLZL4rDy101xZCZBNcuQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=Op4juWPpsa0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=tmi9kOqBNXXKSUpxMQ4A:9 a=CjuIK1q_8ugA:10 a=ZsvHfuFSAAAA:8 a=DGG8EIu7HUducKyVYroA:9 a=IzkmhS4iMz_GUfKi:21 a=QEXdDO2ut3YA:10 a=SJFCsYi-t6UA:10 a=iZBDQVmU8otq4hDR5MHx:22 a=Ryc2fXeAP51dHFQ1qRxw:22 X-Bluewin-Spam-Score: 100.00 X-FXIT-IP: IPv4[94.100.136.225] Epoch[1518688233] X-Bluewin-Spam: Cloudmark If anybody from bluewin/Swisscom, please contact me off list Greetings alex

5 years, 1 month

RIPE NCC Global IPv6 Deployment Survey

by Massimiliano Stucchi

Dear colleagues, The RIPE NCC would like to invite you to participate in its Global IPv6 Survey 2018. The goal of the survey is to get an overview IPv6 deployment across the world, and to assess how this is seen from the perspective of ISPs and Enterprise users. The 2018 survey is a follow up to similar surveys run between 2008 and 2013, and will serve as a comparison with the data acquired back then. You can find the survey at the following address: https://www.surveymonkey.com/r/GlobalIPv6survey2018 Responses can be submitted until 31 March 2018. We will then collect the data with the aim of presenting the preliminary results during the upcoming RIPE 76 meeting in Marseille. If you have any question about the survey, please feel free to email us at: ipv6survey2018(a)ripe.net. Thank you very much in advance for your participation! -- Massimiliano Stucchi IPv6 Programme Manager RIPE NCC mstucchi(a)ripe.net Follow us on Twitter for the fastest and latest RIPE NCC Training news! @TrainingRIPENCC

5 years, 1 month

ALLOCATED UNSPECIFIED ranges [RIPE/alloc-unspecified]

by Paolo Moroni

Good afternoon from AS3303 (Swisscom/IP-Plus). This e-mail is intended as help information for those of you who operate IPv4 PI addresses within the following ranges: 193.5.0.0/16 193.134.0.0/15 193.246.0.0/15 for historical reasons, these ranges used to have a status of ALLOCATED UNSPECIFIED in the RIPE data base and were managed by the ch.unisource LIR (ourselves). In 2016 the RIPE-NCC has received a mandate from the RIPE Address Policy working group to transfer these addresses into standard ALLOCATED PA and ALLOCATED PI addresses, managed by the RIPE-NCC; if interested in the details, please see https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-October/0118… The transfer of these three ranges has been completed recently. This includes the management responsibility of the related PI assignments, although, for practical reasons, the Swisscom maintainer CH-UNISOURCE-MNT has not been removed from some objects yet. Please find enclosed below the guidelines we received from the RIPE-NCC with respect to the administration of the related RIPE data base objects. Thanks for your attention and understanding, Paolo Moroni IP-Plus Engineering ch.unisource ----------------------------------------------------------------------- Following the re-organisation of ALLOCATED UNSPECIFIED addresses blocks formerly managed by CH-UNISOURCE-MNT, the management of the PI assignments has been transferred to the RIPE-NCC. Each PI assignment will need to have a "Sponsoring LIR" (a RIPE NCC member responsible for maintenance, accuracy and communication with regards to a specific assignment). Please see http://www.ripe.net/ripe/docs/ripe-637#20 for details. Please contact your Sponsoring LIR if you have one. If not, please contact RIPE NCC, <ncc(a)ripe.net>

5 years, 1 month

IPv6 Run Event

by Nico Schottelius

Good morning Swinog, we are planning our first IPv6 focused event this year. The main topic of the event is, how well the IPv6 deployment of Switzerland has come and to discuss the action points to reach 100% IPv6 coverage. Thus I would like to invite you to join and... ... showcase how and where you enabled sites with IPv6 ... show difficulties and solutions for IPv6 only networks ... meet players from industry to discuss your needs with others ... get a tasty Adler Bräu beer We are at an early planning stage, but wanted to begin to spread the word already (i.e. date to be defined, Website & CfP coming in the next weeks). The format will likely be a 1-2 day event, with talks during the day, discussion in the late afternoon and a networking event in the evening. To decide on the exact format, I would like to ask you to give me a heads up, if you are interested in this event and if you are interested in showcasing something. A simple "+1" or "+1 +talk_about_x" suffices. Depending on the feedback, we will plan for either a 1 or 2 day event. Thanks a lot and have a great snowy Sunday, Nico -- Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

5 years, 1 month

datacomm/vtxnet and quicknet/kfsb are missing TLS on their mailservers

by Peter Keel

Hi I get these errors: | TLS is required, but was not offered by host mx1.datacomm.ch[212.40.2.32] and | TLS is required, but was not offered by host relay.kfsb.ch[213.202.32.8] Since I've made TLS for SMTP mandatory. The respective admins of these servers might want finally at least enable voluntary TLS; some of their customers apparently would like to receive mails from my server. And by the way, RFC 2487 that is referred to for instance in the postfix manpage and stated that one must not make TLS mandatory has been obsoleted by RFC 3207. Cheers Seegras -- "Those who give up essential liberties for temporary safety deserve neither liberty nor safety." -- Benjamin Franklin "It's also true that those who would give up privacy for security are likely to end up with neither." -- Bruce Schneier

5 years, 1 month

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog February 2018