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.
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
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.
Director DNS Operations
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?
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.
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:
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>
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 ;)
ImproWare AG ist operating the free of charge SWINOG rbl DNS Servers for those
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.
The actual query rate can be seen under:
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.
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!
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 . We report this to MELANI, as required by law . 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.
 Details see Bakom
 The law  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.
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
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
set local-preference 50
route-map foo seq 20
set local-preference 100
route-map foo seq 30
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
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.