Hey all
A friend just told me that Cybernet told him there is a Switzerlandwide Internet Problem.
Does anybody know something?
Cheers
Michele
--------
Online Consulting AG, Michele Capobianco, System Administrator, Weststrasse 38, CH-9500 Wil
Phone +41 (0)71 913 31 31, Fax +41 (0)71 913 31 32
http://www.online.ch, michele.capobianco(a)online.ch<mailto:michele.capobianco@online.ch>
--------
PLANNED IP6.ARPA NAMESERVER CHANGE
This is a courtesy notification of an upcoming change to the
nameserver set for the IP6.ARPA zone.
There is no expected impact on the functional operation of the DNS
due to this change.
There are no actions required by DNS server operators or end users.
DETAIL
The IP6.ARPA zone is used to provide reverse mapping (number to
name) for IPv6, as described in RFC 3152. The servers which currently
provide authoritative DNS service for the IP6.ARPA zone are as
follows:
TINNIE.ARIN.NETNS-SEC.RIPE.NETNS2.LACNIC.NETSEC1.APNIC.NETNS.ICANN.ORG
On Wednesday 2010-12-01 processing will begin to change the nameserver
set to the following, as described in RFC 5855:
A.IP6-SERVERS.ARPA (operated by ARIN)
B.IP6-SERVERS.ARPA (operated by ICANN)
C.IP6-SERVERS.ARPA (operated by AfriNIC)
D.IP6-SERVERS.ARPA (operated by LACNIC)
E.IP6-SERVERS.ARPA (operated by APNIC)
F.IP6-SERVERS.ARPA (operated by RIPE NCC)
The usual IANA process for a change in the ARPA zone involves a
series of technical checks and the gathering of various authorisations,
and may take several days to complete. Courtesy notification will
be sent to this list once this change has been fully implemented.
Regards,
Joe Abley
Director DNS Operations
ICANN
Hi folks!
It started about 2 weeks ago with one of our clients affected. In the meantime, the cases pile up here more and more. Some mails are completly lost after we deliver them to the bluewin MX, others 'only' loose their attachments. According to swisscom support, none of our mailservers are blocked / blacklisted there.
Is anyone else seeing such things?
Best wishes,
Matthias
Just a quick note regarding the mailinglist of swinog(a)swinog.ch:
There is _no_ moderation. Any message which is stuck in the queue is going
straight to /dev/null. Reason: too much spam arriving in the queue, and no
time to fish for any legitimate message.
If you happen that your message to the list is not distributed (i.e. showing
up in the archive http://lists.swinog.ch/public/swinog/), it is discarded.
Ensure that your sending parameters are correct and resend.
F.
Hiya,
Last week I sent below message, with an attachment which apparently was
too big for the list and it got stuck in the moderation queue, where it
still is I can only assume, thus this time without the attachement, but
simply shoving the files in my archive:
http://unfix.org/~jeroen/archive/swinog-keyring.txthttp://unfix.org/~jeroen/archive/swinog-keyring.txt.md5http://unfix.org/~jeroen/archive/swinog-keyring.txt.sha512
See below for the rest of the message...
-------- Original Message --------
Subject: SwiNOG #21 PGP keys
Date: Fri, 12 Nov 2010 01:11:45 +0100
From: Jeroen Massar <jeroen(a)unfix.org>
Organization: Unfix
To: swinog(a)swinog.ch
See below the list of folks who where checked along with the keys that
where verified. Find attached the the full keylist as taken from
biglumber (which includes people who where not there, thus filter with
the list below ;)
MD5:
b3651c3a0d23fb6c8669b4b8aeed2031
SHA512:
75f11d176dd664a36f9c505ca503924caadf0fd6b5744cde04b17f3821d9c80e01aa5f022acd8bfc6100a85758291a7d5180b90ec469df45f79b77a799cc89b7
Greets,
Jeroen
--
Francois Deppierraz
B0C55F5B45AB7E9A1B897C228776D2DC9D283BC9
Jean-Pierre Schwickerath
1C1721BDCF3ADF155520EAC1092A5B956BFF4228
Hendrik Jaeger
50F8BC65295CF4368BC9A3BAE4F3BFCA9914042F
D01C4E73DE235844254071954F0203EBB00BF84E
Jeroen Massar
48E82BD43B4A622E405C3A3529AA2852333E7C23
Markus Wellauer
ED1D3C7AC61B932E07E808D8D418D46C24F4A6D6
Martin Ebnoether
A74F74D5E51B4B13D66E653DC932807B37901254
3BBB809434810F9061CF5DE5DDF1B4D92FB4BE6B
Andre Keller
4A576ED69F2081DBE582B70F1D31AFE9C00CA768
Alain Pellmont
698735BD82624FF967D761ECF11F6368170C9878
Steven Glogger
AE60DD1B926CFAFA5A62A154AF8C5451377BBFE7
B2ED00471821C1035D9FC6A2FAF196C6FF469AF6
Hello
ImproWare AG ist operating the free of charge SWINOG rbl DNS Servers for those
zones:
dnsrbl.swinog.ch
dnswl.swinog.ch
uribl.swinog.ch
uriwl.swinog.ch
Some of the secondary servers offered in the past have stopped operation.
I'm looking for one or two new secondary DNS Servers for the zones above to
spread the load and provide higher reliability.
If we could also put our own specialized rbl zones there, that would be great.
spamrbl.imp.ch
wormrbl.imp.ch
The actual query rate can be seen under:
http://rblns.imp.ch/cgi-bin/bindgraph.cgi
The server should be able to handle frequent ixfr updates. The zonefiles are
not too large (<50MB at the moment).
We use bind 9.6.ESV.R1.
Please contact me off-list if interrested.
Benoit Panizzon
--
I m p r o W a r e A G -
______________________________________________________
Zurlindenstrasse 29 Tel +41 61 826 93 07
CH-4133 Pratteln Fax +41 61 826 93 02
Schweiz Web http://www.imp.ch
______________________________________________________
Dear SwiNOG Community,
I'm just out of a very interesting meeting with a representative of SIMSA (Swiss Internet Industry Association). SIMSA is mainly representing hosting companies but also have a few ISP members. I proposed to them the creation of an ISP-WG within SIMSA which he would welcome. Maybe that's the better solution instead of creating a complete new structure.
SIMSA is organising an event with two relevant parts for ISPs. First is a workshop about ÜPF (without ÜPF indeed, nothing changed). And the second interesting part is a presentation of Oliver Süme (vice-president of EuroISPA) who will also talk about LI.
I hope to see you there!
Registration: http://www.simsa.ch/events/events_view.cfm?id=153
Pascal
Hello Swinogers,
On 25 November 2010 SWITCH will launch an new initiative to maintain the high
security standards of Swiss websites.
Let me briefly explain what we will do, as it is relevant to the SWINOG community:
>From different third parties we receive a fairly large number of URLs in
.ch/.li ccTLDs which distribute malware. We're talking a few hundred URLs per
week. In a first step SWITCH verifies that this claim is true.
If the site is indeed distributing malware we will contact the
domain holder and technical contact by e-mail and ask them to remove the
problem within one working day.
If the they fail to do so, we will delete the name server delegation from the
zone-file [1]. We report this to MELANI, as required by law [2]. The domain
holder will be informed about this.
Removing the name server delegation is not really efficient as long as DNS
caches, containing entries of that domain are not flushed.
SWITCH plans to make the list of blocked domains available to relevant parties,
i.e. ISPs operating name servers for their customers.
If you want to receive this info send us an e-mail message to cert(a)switch.ch
and we will get in touch with you.
Since we don't want any finger pointing or bashing of affected sites, we want
you to keep this info confidential. To join, we therefore ask you to sign a non
disclosure agreement (NDA).
Please get in touch with if you have any question.
Best regards
Serge
Notes:
[1] Details see Bakom
http://www.bakom.admin.ch/themen/internet/03470/index.html?lang=de
[2] The law [1] talks about a "anerkannte Stelle zur Bekämpfung von
Cyberkriminalität", a recognized organisation fighting cyber-crime. So far
MELANI (http://www.melani.admin.ch/) is the only recognized organisation.
--
SWITCH
Serving Swiss Universities
--------------------------
Serge Droz, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 63, fax +41 44 268 15 78
serge.droz(a)switch.ch, http://www.switch.ch
Hi all,
About the talk "BGP Origin ASN Validation" from Roque Gagliano at SwiNOG
#21 I talked afterwards with him with the following remark:
Roque showed a route-map like this one:
route-map foo seq 10
match invalid
set local-preference 50
!
route-map foo seq 20
match incomplete
set local-preference 100
!
route-map foo seq 30
match valid
set local-preference 200
!
This will not fix the "youtube vs. Pakistan"-problem.
For example, youtube announces a /22, signed, gets local-pref 200.
"Bad ISP" announces a /24 out of the /22, unsigned, gets local-pref 50,
BUT gets into my routing table!
I think it whould by cool to have a system to prevent an *unsigned*
prefix, which is more specific than a *signed* prefix, to be accepted.
Maybe this could be done in IOS Code, for example with the configuration
option "do not allow an unsigned more specific prefix within a signed
prefix".
This will allow us to configure the route-map as shown above and accept
invalid/incomplete prefixes. But the accepted invalid/incomplete
prefixes are not more specific than a signed prefix.
If someone does know more, please comment.
Cheers,
Tim