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>
--------
hello all,
hopefully I do not break here a subscription-Law, so simply:
We have some Cisco parts / devices on Stock, which where nearly never
used:
2x Firewall Cisco ASA5520-AIP20-K9
(ASA 5520 Appl w/ AIP-SSM-20, SW,300 VPN, Prs,4GE+1FE,3DES/AES)
1x Switch Cisco WS-C4507R + some modules
(2x 24 port 10/100/1000 GBE / 2x V Console / 2x power supply etc
They where bought for a project, which was frozen, and there was no
fit in other needs / projects.
If you see need, please contact me directly in english or german.
mailto:swinog-ch@hightowernet.de
Detailed product list & photos available on request.
Condition of devices: nearly new
ASA's where tested only some hours
4507er was in use for about 2-3 months
Bougt end 2006. Used in Summer 2007
Will be sold on highest bid.
Test before possible, sold without warranty.
Device location: near to Zurich
Alternatively:
do you know company near Zurich, which makes business with
buying/selling used hardware in this class ?
We simply want to cleanup our stock ASAP.
--
Mit freundlichen Grüßen
Stephan Wolf
mailto:swinog-ch@hightowernet.de
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
ich habe seit einiger Zeit auf allen meinen Nameservern Probleme, die
komplette Zone nic.ch zu resolven. Diese Probleme beschränken sich
ausschließlich auf nic.ch, mir ist keine andere Zone aufgefallen, die
Probleme macht. Vermutlich treten die Probleme seit September 2009, also
mit Umstellung auf DNSSec, auf. (Ich kann es leider nicht hundertprozent
genau datieren.)
Nach einigen Debuggingschritten bin ich etwas ratlos. Meine Firewall
läßt in beiden Fällen (bei jeweils auch einem komplett anderen Provider)
alles durch, was Port 53 anbelangt. Auch ein Ausschalten der Firewall
bringt die selben ergebnisse. Auch ein Test mit verschiedenen anderen
DNSSec-Domainen, auch solchen, die groß sind und somit fragmentiert
werden (sollten, meine MTU ist 1500), stellen keine Probleme dar. Ein
tcpdump zeigt aber recht schnell, daß von den UDP-Paketen von nic.ch
immer nur das erste ankommt und alle weiteren nicht auf meinem
Netzwerkinterface aufschlagen.
Nun meine Frage: Hat oder hatte jemand von euch schon ähnliche Probleme
und wie wurden sie behoben? Wenn es sich bei nic.ch um eine unwichtige
Domain handeln würde, wäre es mir ja egal, aber sie ist ja doch nicht
ganz so unwichtig.
Gruß
Klaus Ethgen
- --
Klaus Ethgen http://www.ethgen.de/
pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <Klaus(a)Ethgen.de>
Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEVAwUBTBiJ0Z+OKpjRpO3lAQKt6gf/W9+ftdXlrmK8jaW1zgGEhZvu0oOm/tpl
Wq+7u3GhlA08lIFSNeZxYQrs2Fea4rDVHQkxQvAHZogwvmIqNm7DemgnB1REKUD+
gUI4OPtE29npnUdKEUUSLm/XsL8bSpbKX1ESTAx44uWegVS5LDHy+1lnjOfF29In
L91VUroTvfbu5Odm5/82sR7UrYMbJeR2X/3oEtONbFR8xXOW4Eguxx1eOszUS7DQ
BFN+AT6+A3g+ECn1WDCvrposYIC3YLu3V1qLSY5RzoDmuGxonbJv6zRCrTODp/9i
KATfUPQvvVdh6FFwc4WA7pSYZHmTnl6+YFWk7lIhU5F1pGBHbSiYtA==
=DVDj
-----END PGP SIGNATURE-----
Dear SWINOG Users,
I need a SMSC Gateway provider which can communicate with SMPP
protocol for example.
Thanks
Best regards
Niklas
Le mer 30/06/10 08:39, "Kummer, Thomas" THOMAS.KUMMER(a)T-SYSTEMS.CH a
écrit:
Hi Niklas
What exactly do you want to have? What sort of service do you want
to run on the SMSC? I might be of help, depending on what you are
looking for.
Best regards
Thomas
Thomas Kummer
T-Systems Schweiz AG
International Carrier Sales
">http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog [8]
Links:
------
[1] mailto:thomas.kummer@t-systems.ch
[2] http://www.deutschetelekom.com%2Ficss%2Fswitzerland
[3] mailto:swinog-bounces@lists.swinog.ch
[4] mailto:swinog-bounces@lists.swinog.ch
[5] mailto:lists@rebert.name
[6] mailto:swinog@lists.swinog.ch
[7] mailto:swinog@lists.swinog.ch
[8] http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Hi out there
The last few days I noticed quite a large delay when I first dial a number
from my asterisk server.
I found that the problem is that the 1.4.e164.arpa lookup takes enormous time
to return a NXDOMAIN
== ast_get_enum(num='+41618269309', tech='sip', suffix='e164.arpa',
options='', record=1
== ast_get_enum() profiling: FAIL, 9.0.3.9.6.2.8.1.6.1.4.e164.arpa, 5148 ms
compared to the e164.org or e164.info lookups:
== ast_get_enum(num='+41618269309', tech='sip', suffix='e164.org',
options='', record=1
== ast_get_enum() profiling: FAIL, 9.0.3.9.6.2.8.1.6.1.4.e164.org, 141 ms
== ast_get_enum(num='+41618269309', tech='sip', suffix='e164.info',
options='', record=1
== ast_get_enum() profiling: FAIL, 9.0.3.9.6.2.8.1.6.1.4.e164.info, 167 ms
Of course, as soon as the NXDOMAIN is in the local DNS cache, dialing the same
number is fast again.
Also the previously working ETHZ e164.arpa test-tone number cannot be resolved
anymore:
== ast_get_enum(num='+41446580004', tech='sip', suffix='e164.arpa',
options='', record=1
== ast_get_enum() profiling: FAIL, 4.0.0.0.8.5.6.4.4.1.4.e164.arpa, 5150 ms
Has switch ceased to offer e164.arpa entries? 1.4.e164.arpa does not seem to
be delegated anymore:
; <<>> DiG 9.6-ESV-R1 <<>> NS 1.4.e164.arpa.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49396
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;1.4.e164.arpa. IN NS
;; AUTHORITY SECTION:
e164.arpa. 10784 IN SOA ns-pri.ripe.net.
e164-contacts.ripe.net. 2010062458 14400 3600 2419200 14400
Deleagions found by dnsbajaj:
Subdomains: 0.1.8.7.8.e164.arpa , 0.2.4.e164.arpa , 0.3.e164.arpa ,
0.4.e164.arpa , 0.6.e164.arpa , 0.7.3.e164.arpa , 0.8.3.e164.arpa ,
0.9.2.e164.arpa , 0.9.5.e164.arpa , 1.2.4.e164.arpa , 1.3.e164.arpa ,
1.6.e164.arpa , 1.7.9.e164.arpa , 1.8.e164.arpa , 2.6.2.e164.arpa ,
2.6.9.e164.arpa , 2.6.e164.arpa , 2.8.e164.arpa , 3.2.4.e164.arpa ,
3.3.e164.arpa , 3.4.e164.arpa , 3.5.3.e164.arpa , 3.6.e164.arpa ,
4.3.2.8.8.e164.arpa , 4.4.e164.arpa , 4.5.3.e164.arpa , 4.7.3.e164.arpa ,
4.8.e164.arpa , 4.9.5.e164.arpa , 5.5.2.e164.arpa , 5.5.e164.arpa ,
5.6.e164.arpa , 6.3.e164.arpa , 6.4.2.e164.arpa , 6.4.e164.arpa ,
6.6.e164.arpa , 6.8.3.e164.arpa , 6.8.8.e164.arpa , 6.8.e164.arpa ,
6.9.5.e164.arpa , 7.4.2.e164.arpa , 7.4.e164.arpa , 8.0.5.e164.arpa ,
8.4.e164.arpa , 8.5.3.e164.arpa , 9.3.e164.arpa , 9.4.e164.arpa ,
9.5.3.e164.arpa
-Benoît-
hi everybody
here's the announcement for the next beer event.
i hope weather will be good, if not we have to go to the outback lodge.
please check the WEBSITE until 12:00 on the event-day to be sure about
the place.
the facts for the next event:
-----------------------------
Date: 12th of July 2010
Time: starting around 18.30 o'clock
Location: @lake in restaurant "Pumpstation" (see image;
www.pumpstation.ch)
backup location if bad weather: Outback Lodge.
Registration deadline: 10.07.2010 12:00:00
-----------------------------
Please register here: http://swinog.mrmouse.ch/ since we have to make
reservations, i need to know who's coming and who not. If you cannot
attend and you're registered please inform me asap (+41 79 277 92 35).
-steven
Hi
Some day ago, a account of our mail server has been misused
to sent out some thousand of spam mails.
This could happen, because the spammer which misused the account
logged in from different IPs (botnet?) over the whole world. Every time, he
successfully (smtp) authenticated, he sent out a couple of mails
(about 20-30). Then he disconnected and reconnected after 1-2 minutes
from an other IP and sent again some 20-30 mails. This has been done
for some hours, which generated some thousand of SPAM mails.
Since this started Friday night and was just discovered yesterday, we
was listed on one blacklist. We changed the password of the misused account
and removed our server from this blacklist.
We already was happy, that it's just was that simple, but we was
to fast.
We got then complains, that some mail system still block our mail server. After
some investigation, we found out, that this mail system or mail gateways are
base on Cisco IronPort. First at all, this system didn't response with a
clear response (Something like 5.7.1 Your access to submit messages to this
e-mail system has been rejected, isn't really helpful for an mail admin to
find out why his email get blocked.)
After we found out, that all this boxes are Ironport Boxes, we was pointed
to the www.senderbase.org. But this site isn't very helpful. You can find
out that your mail server has a bad email reputation, but that's it. A
link to SpamCop on the webpage isn't helpful either, since we aren’t listed
in their blacklist.
The only e-mail address on the webpage seem not to be the contact for
when you have a bad e-mail reputation.
We thought, perhaps the Score will fall down over 24 hours, but that's
not the case.
So, we tried to get some help from the cisco ironport support. There
answer wasn't very helpful either. They told us, that senderbase.org
is a complete other company and they don't have any contact and
we should try their website www.senderbase.org. Otherwise, if we don't
have a IronPort box, they will not help us.
Now, the question is, what can we do, do get our mails delivered to
this ironport boxes?
We really take care, to do all against be used for spamming or to
be known as a good source for mails (spf, dkim, smtp-auth,
tarpiting, etc.etc.).
We think, that this reputation system isn't that great. We have one
issue and get blocked for several days (or weeks) without an option
to take care about the situation.
Any help or suggestion would be appreciated!
Kind Regards
Patrick Studer
******************************************************************************
X-NetConsulting GmbH Internet http://www.x-netconsulting.ch
Grosspeterstrasse 21 E-Mail p.studer(a)x-netconsulting.ch
CH-4052 Basel Telefon +41 61 315 85 55
Schweiz Fax +41 61 315 85 59
******************************************************************************
Root Zone DNSSEC Deployment
Technical Status Update 2010-06-18
This is the ninth of a series of technical status updates intended
to inform a technical audience on progress in signing the root zone
of the DNS.
RESOURCES
Details of the project, including documentation published to date,
can be found at <http://www.root-dnssec.org/>.
We'd like to hear from you. If you have feedback for us, please
send it to rootsign(a)icann.org.
KSK CEREMONY 1 COMPLETE
The first KSK ceremony for the root zone was completed this week
in Culpeper, VA, USA. The Ceremony Administrator was Mehmet Akcin.
The first production KSK has now been generated. This is the key
that is scheduled to be put into service on 2010-07-15.
The first production Key Signing Request (KSR) generated by VeriSign
has now been processed by ICANN using the root zone KSK, and the
resulting Signed Key Response (KSR) has been accepted by VeriSign.
This SKR contains signatures for Q3 2010, for use between 2010-07-01
and 2010-09-30.
Audit materials relating to the first ceremony will be published
as soon as is practical, and in particular before 2010-07-15.
The KSK and SKR generated during this ceremony will not be approved
for production until the KSK key pair has been successfully transported
to ICANN's west-coast ceremony facility in El Segundo, CA, USA, and
placed in secure storage.
KSK CEREMONY 2 SCHEDULED
The second KSK ceremony for the root zone is scheduled to take place
in El Segundo, CA, USA on 2010-07-12. Replication of key materials
onto west-coast HSMs, enrolment of west-coast crypto officers and
processing of the Q4 2010 KSR (for production use between 2010-10-01
and 2010-12-31) will take place during this ceremony.
PLANNED DEPLOYMENT SCHEDULE
Already completed:
2010-01-27: L starts to serve DURZ
2010-02-10: A starts to serve DURZ
2010-03-03: M, I start to serve DURZ
2010-03-24: D, K, E start to serve DURZ
2010-04-14: B, H, C, G, F start to serve DURZ
2010-05-05: J starts to serve DURZ
2010-06-16: First Key Signing Key (KSK) Ceremony
To come:
2010-07-12: Second Key Signing Key (KSK) Ceremony
2010-07-15: Distribution of validatable, production, signed root
zone; publication of root zone trust anchor
(Please note that this schedule is tentative and subject to change
based on testing results or other unforeseen factors.)