Dear community,
something important for us happened today that may have some impact on our daily business.
Our Federal Court just decided that IP addresses are personal data and the federal law about data protection must also be followed also for IP addresses. Collecting IP adresses for private (corporate) investigation is not legal. Companies like Logistep have to stop their activities immédiately!
As ISP be carefull not to publish traffic information containing IP addresses.
see you,
Pascal
-----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-----
Hi all
I seam to quite often stumble over this bug and wonder if the router is buggy
or the client is buggy.
Most Motorola ADSL/VDSL Routers which Swisscom sent to their customers for
about the last two years or so, have a DNS proxy enabled by default. The dhcp
clients get the IP address of the router as DNS.
Now some resolvers (the linux glibc resolver at least), when resolving a
hostname first ask for AAAA and when no RR and no error is returned, they ask
for the A record.
Now when a host is resolved that way via a Motorola DNS Proxy, the AAAA query
does not result in:
- No Error, no RR returned.
But in
- Error 0011 => No such Name.
If the linux glibc receives Error 0011 it does not continue looking for an A
record, but return 'Hostname not found' or similar immediately. Thus making
hosts which have a valid IPv4 but first were asked for their AAAA address not
reachable from linux.
The workaround is to not use the DNS proxy on those routers.
Windowses do not seam to have this problem, even with ipv6 enabled.
So who is wrong? The linux glibc or the router?
-Benoit-
hi everybody
here's the announcement for the next beer event. (and yes, sorry I'm late
,-))
let's try a new location ,-)
the facts for the next event:
-----------------------------
Date: 6th September 2010
Time: starting around 18.30 o'clock
Location: @ the "Papa Joe's" near Bellevue ZH
http://http//www.papajoes.ch/zuerich/deutsch/
Registration deadline: 06.09.2010 10:00:00 (Monday)
Registration: http://swinog.mrmouse.ch
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